Day 49: Using Tags to Manage AWS Instances

Welcome to Day 49 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC.

One of the great features of AWS is the use of tags which is supported by most objects (a list of supported objects can be found here).  Tags allow you to categorize and manage your instances and associated objects by assigning a key / value pair so you can describe it with rich metadata as opposed to organizing your resources with a single name and then into some form of containers that you may have traditionally done.  Essentially what this means is that rather than using a database or a single repository, like Active Directory for example, information about your resources is distributed across each object and also allows you to put whatever information you like in the tags.  In this post we’re going to look at applying these tags via PowerShell and  examples of what type of information you may want to store in the tag and finally how this can be used to manage your resources more effectively.

Each object can have up to 10 tags and the key field can contain up to 127 characters and the value tag can contain up to 255 characters.  Also it’s important to note that tags are case sensitive, so bear that in mind when you trying to retrieve a list of instances and you are not getting the results you are expecting.

Applying a single tag with PowerShell

As a best practice you should apply your tags as your instances are being deployed.  That way the same information that is being used to provision the instances can be the same information applied in the tags.  To apply a tag we first need to create a .Net object because there’s no cmdlet to create a tag.  Once we’ve created the object we use the New-EC2Tag cmdlet to apply it to a resource.  The example below gives a simple snippet of deploying a new instance, creating the tag object and then applying a single tag with the key defined as “Name” and the value of the key “SRV01”:

If you have been following some of the previous articles (Day34, Day 39), you may notice I’ve adopted a slightly different method to retrieving the instance ID of the instance.  With this method we allow time for the instance to be created and then retrieve the instanceID.  I have found occasionally the instanceID is blank if you attempt to retrieve it too soon after deployment, so with the Start-Sleep we allow time for the instance to be provisioned.

Applying a single tag to multiple objects

Once you start using tags you quickly realize that you want to create more you perhaps also realize that perhaps you want to tag the disk and network interfaces too.  This is particularly important if you are using tags to help track costs for billing purposes.  AWS do provide itemized billing  to include the cost of each object and its associated tag.  These reports are known as the AWS cost allocation reports.  So assuming we want to also tag the instance, disk and network interface, the sample below shows how that can be done:

In the example above it’s very similar to the first example but this time we need retrieve volumeID of the disk and then pass both the instanceId and resourceId to the New-EC2Tag cmdlet.

Applying multiple tags to multiple instances

In then next example we’re going to deploy multiple instances and use a csv file containing the tag information to apply the tags to the instances.  The CSV file looks like this:

Name,Role,Owner,Expiry,BillingCode,DSCGuid
Web01,WebServer,Walter White,2014-10-31,PRJ-001,eacb98af-051d-4041-8a14-71686ddf8378 
App01,AppServer,Jesse Pinkman,2014-10-31,PRJ-001,3ed20264-dcfb-41db-bf70-dedb16030877

In the example above we’ve taken things a little further.  Firstly the creation of the tag and applying it to an instance has been wrapped up into a single function.  The next thing we do is to get the name of the image we want to deploy, but instead of just deploying one instance, the –MinCount and –MaxCount parameters allow us to deploy multiple images with one command.  Next, we import the csv file containing the tag information we wish to apply and then iterate through applying the tags.  Notice that the information on each of the provisioned instances is contained in the $reservation variable and using $i = 0 we retrieve the first instance from $reservation and then at the end of the foreach loop we increment $i and then retrieve the next instance provisioned. i.e.:

As mentioned earlier tags can help with billing purposes, so a billing code is applied is applied to each instance.  Finally the DSCGuid tag provides a perfect place to hold the DSC guid so that it may be retrieved later when configuring the server with a DSC pull server (more on that in a future article!).

We can verify the tags applied within the console

ViewTags

Querying instances using tags

We’ve seen how we can view the tag information in the console, so lets take a look at how can we view it via PowerShell.  One tag we created but have not mentioned yet is the Expiry tag.  Using a tag like this provides a great of way of managing costs and resources in the cloud.  I’ve seen plenty of examples of where test and development instances being provisioned, but once they were finished they weren’t turned off and kept accumulating costs.  Below is a simple example of how you may have a scheduled task running once a day that looks for instances that may have exceeded their expiry date.  If we find a matching expiry date, we shutdown the instance:

Conclusion

We’ve seen how easily instances and whole environments can be provisioned in the cloud.  It therefore follows that if something is easily provisioned the rate of consumption is likely to significantly rise, this after all the ultimate goal of any cloud provider.  With this in mind it’s imperative that that instances and resources are managed effectively and by using tags similar to those used here, the management of the cloud environment should be significantly easier.

 

Previous Installments

To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.