Tagging EC2 EBS Volumes in Auto Scaling Groups

Tagging becomes a huge part of your life when in the public cloud. Metadata is thrown around like hotcakes, and why not. At cloudstep.io we preach the ways of the DevOps gods and especially infrastructure as code for repeatable and standardised deployments. This way everything is uniform and everything gets a TAG!

I ran into an issue recently where I would build an EC2 instance and capture the operating system into an AMI as part of a CloudFormation stack. This AMI would then be used as part of a launch configuration and subsequent auto scaling group. The original EC2 instance had every tag needed across all parts that make up the virtual machine including:

  • EBS root volume
  • EBS data volumes
  • Elastic Network Interfaces (ENI)
  • EC2 Instance itself

When deploying my auto scaling group all the user level tags I’d applied had been removed from the volumes and ENI. This caused a few issues:

  1. EBS volumes couldn’t be tagged for billing.
  2. EBS volumes couldn’t be snapped based on tag level policies in Lifecycle Manager.
  3. Objects didn’t have a ‘Name’ tag which made it hard in the console to understand which virtual machine instance the object belonged too.

There are two methods I derived to add my tags back that I’ll share with you. The tags needed to be added upon launch of the instance when the auto scaling group added a server. The methods I used were:

  1. The auto scaling group has a Launch Configuration where the ‘User data’ field runs a script block at startup.
  2. Initiate a Lambda whenever CloudTrail logged an API reference of a launch event of an instance using CloudWatch.

Tagging with the User Data property and PowerShell

User data is simply:

When you launch an instance in Amazon EC2, you have the option of passing user data to the instance that can be used to perform common automated configuration tasks and even run scripts after the instance starts. You can pass two types of user data to Amazon EC2: shell scripts and cloud-init directives.


Try {
 # Use the metadata service to discover which instance the script is running on
 $InstanceId = (Invoke-WebRequest '').Content
 $AvailabilityZone = (Invoke-WebRequest '').Content
 $Region = $AvailabilityZone.Substring(0, $AvailabilityZone.Length -1)
 $mac = (Invoke-WebRequest '').content
 $URL = ""+$mac+"/interface-id"
 $eni = (Invoke-WebRequest $URL).content
# Get the list of volumes attached to this instance
 $BlockDeviceMappings = (Get-EC2Instance -Region $Region -Instance $InstanceId).Instances.BlockDeviceMappings
 $Tags = (Get-EC2Instance -Region $Region -Instance $InstanceId).Instances.tag

Catch{Write-Host "Could not access the AWS API, are your credentials loaded?" -ForegroundColor Yellow}
$BlockDeviceMappings | ForEach-Object -Process {
        $volumeid = $_.ebs.volumeid # Retrieve current volume id for this BDM in the current instance
        # Set the current volume's tags
        $Tags | ForEach-Object -Process {
        If($_.Key -notlike "aws:*"){
        New-EC2Tag -Resources $volumeid -Tags @{ Key = $_.Key ; Value = $_.Value } # Add tag to volume
# Set the current nics tag
$Tags | ForEach-Object -Process {
  If($_.Key -notlike "aws:*"){
        New-EC2Tag -Resources $eni -Tags @{ Key = $_.Key ; Value = $_.Value } # Add tag to eni

This script block is great and works a treat with newly created instances from an Amazon Marketplace AMI’s e.g. a vanilla Windows Server 2019 template. The launch configuration would apply the script as a part of the cfn-init function at startup. Unfortunately I’d already used the cfn-init function as part of the original image customisation and capture, the cfn-init would not re-run and didn’t execute this script block. So back to the drawing board in my scenario.

Tagging with CloudWatch and Lambda Function

The second solution was to create a Lambda function and trigger it using an Amazon CloudWatch Events rule. The Instance ID is parsed from the CloudWatch event in JSON to the Lambda function.

Here is the Lambda function that is written in python2.7 and leverages the boto3 and JSON modules.

from __future__ import print_function
import json
import boto3
def lambda_handler(event, context):
  print('Received event: ' + json.dumps(event, indent=2))
  ids = []
      ec2 = boto3.resource('ec2')
      items = event['detail']['responseElements']['instancesSet']['items']
      for item in items:
      base = ec2.instances.filter(InstanceIds=ids)
      for instance in base:
        ec2tags = instance.tags
        tags = [n for n in ec2tags if not n["Key"].startswith("aws:") ]
        print('   original tags:', ec2tags)
        print('   applying tags:', tags)
        for volume in instance.volumes.all():
          print('    volume:', volume)
          if volume.tags != ec2tags:
            volume.create_tags(DryRun=False, Tags=tags)
        for eni in instance.network_interfaces:
          print('    eni:', eni)
          eni.create_tags(DryRun=False, Tags=tags)
      return True
  except Exception as e:
    print('Something went wrong: ' + str(e))
    return False   

Warm AWS WorkSpaces On a Schedule

AWS WorkSpaces VDI solution has two pricing options that you need to choose between for your implementation.

  1. Monthly
  2. Hourly (On demand)

In my opinion it is always worth attempting to run your WorkSpaces VDI deployment in on-demand where there is chance of cost savings when the virtual desktops can be turned off and you will not be charged.

With hourly billing you pay a small fixed monthly fee per WorkSpace to cover infrastructure costs and storage, and a low hourly rate for each hour the WorkSpace is used during the month. Hourly billing works best when Amazon WorkSpaces are used, on average, for less than a full working day or for just a few days a month, making it ideal for part-time workers, job sharing, road warriors, short-term projects, corporate training, and education.


Turning off the VDI is done by AWS using a setting called Running Mode per VDI:

Always on – Billed monthly. Instant access to an always running WorkSpaces

AutoStop – Billed by the hour. WorkSpaces start automatically when you login, and stop when no longer being used (1-48hrs).

In my opinion a turn off period of 1 hour is too short, it doesn’t cover a user who has a long lunch or meeting that runs slightly over. 2 hours cool down period seems to be perfect for cost optimisation. With this in mind, all your VDI’s will be off at the beginning of your working day. To eliminate the need for the 60-90 second boot up time imposed by AWS for cold starts we can pre-warm the VDI’s using Lambda function on a schedule. The process will be as follows:

  1. CloudWatch Event that runs based on a CRON schedule.
  2. Event triggers the execution of a Lambda function
  3. The Lambda function runs python that starts WorkSpaces based on a set of conditions using the boto3 library to interact with the service.

The python code block below wakes all VDI’s in a region that are in a ‘STOPPED’ state but there is no reason why you couldn’t be more granular with tagging per VDI.

import boto3

def lambda_handler(event, context):
    directory_id= ''
    region = 'ap-southeast-2'
    running_mode = 'AVAILABLE'
    # Event
    session = boto3.session.Session(
    ws = session.client('workspaces')
    workspaces = []
    resp = ws.describe_workspaces(DirectoryId=directory_id)
    while resp:
      workspaces += resp['Workspaces']
      resp = ws.describe_workspaces(DirectoryId=directory_id, NextToken=resp['NextToken']) if 'NextToken' in resp else None
    for workspace in workspaces:
      if workspace['State'] == running_mode:
      if workspace['State'] in ['STOPPED']:
                'WorkspaceId': workspace['WorkspaceId'],
        print 'Starting WorkSpace for user: ' + workspace['UserName']
        print 'Could not start workspace for user: ' + workspace['UserName']

To start the Workspaces on a schedule, Lambda can invoke using a CRON expression:

cron(0 22 ? * SUN-THU *)

The cron schedule runs in GMT, so in this case 10:00 PM in GMT is 8:00 AM in AEST for following day (GMT +10:00).

The end result is the WorkSpaces you have chosen to wake up would start at 8am and shutdown again at 10am if not used. If you had departments or user groups that are heavy users versus sometimes users this might be where your code looks at some tags you’ve set per VDI.