AWS Step-by-Step
Curb VM Sprawl by Putting AWS Tags to Work
One of the most effective ways to prevent sprawl is to keep track of who created each VM, when and why. In AWS, you can apply this information to each VM instance using tags.
Server virtualization solved many problems associated with the limitations of physical hardware, but it also created some new problems.
One of the most pervasive of these problems was virtual machine (VM) sprawl. It became so easy to deploy new servers that many organizations soon found that their VMs far outnumbered the physical servers that they had previously supported.
The issue of VM sprawl is often discussed with regard to hypervisors such as VMware's ESXi or Microsoft's Hyper-V. However, VM sprawl can also occur in the cloud.
Unfortunately, there is no such thing as an absolutely perfect solution that makes VM sprawl go away. In my experience, one of the most effective things that an administrator can do to prevent sprawl is to keep track of who created each VM, when and why. Having such information on hand won't do anything to stop sprawl from happening, but it will make it easier to clean things up when the time comes.
Amazon Web Services (AWS) allows its customers to apply this type of data to VM instances through the use of tags. You can see the Tags tab in Figure 1.
[Click on image for larger view.] Figure 1: AWS lets you use tags to keep track of your VMs.
In Amazon EC2, a tag is nothing more than a key/value pair that you can use to keep track of VM instances. You can give a tag almost any name that you want, and you can also assign values to tags. By strategically creating tags, it becomes possible to better identify and categorize VM instances.
For instance, if you look at Figure 2, you can see that I have created three tags -- Owner, Purpose and Created. The Owner tag is used to document the person who created the instance. The Purpose tag is used to explain why the instance was created. The Created tag is used to document when the instance was created. Keep in mind that Owner, Purpose and Created are just names that I have used. You can call your tags anything that you want.
[Click on image for larger view.] Figure 2: You can create tags to help you to document your VM instances.
Tags are applied directly to VM instances, either as the instance is created or later on. Figure 3 shows the Tags tab for the selected VM instance. You will notice that the console gives you the ability to add or edit tags.
[Click on image for larger view.] Figure 3: Tags can be assigned to VM instances.
As you can see, creating and using tags couldn't be easier. However, there are a few gotchas that must be considered before using tags.
First, and most importantly, tag usage should be planned in advance. There are at least two very good reasons for this. First, unplanned tagging can be confusing. To show you why, let's pretend that an organization's IT staff agrees to use tags to identify the person who created an instance. Let's suppose that one staff member calls the identification tag Owner, while another member of the IT staff decides to call the tag Creator. Maybe a third staff member calls their tags Name. Now, let's suppose that the person who called their tag Owner decides to query the Owner tag for each VM instance. It will appear that many of the instances are untagged, simply because the IT staff members did not use consistent naming conventions.
A second reason why it is so important to pre-plan tags is that there is a limit to the number of tags that can be applied to an object. According to the AWS documentation, a maximum of 10 tags can be applied to an object. However, the EC2 interface seems to suggest that this limit may have been changed to 50. In either case, there is a limit to the number of tags that can be applied to an object, so it is important to decide upfront which tags will be the most useful.
There are also some basic tagging rules that you will have to adhere to. EC2 allows you to enter a maximum of 127 characters for the tag name and up to 255 characters for the value. Tags are case-sensitive, and can consist of letters, numbers, spaces and a few symbols (e.g., + - = . _ : / @).
AWS also forbids using the aws: prefix for tags. The aws: prefix is reserved for AWS tags, which cannot be edited or deleted. AWS tags do not count against your tag usage limit.
Ultimately, tags can be very helpful for helping to keep your VM instances organized. Even so, it is extremely important to plan your tag usage, and to remember that tags and values are case-sensitive.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.