AWS Step-by-Step

Best Practices for Creating and Managing AWS Tags

As useful as tags are for tracking down specific AWS resources, they can easily get out of hand. To avoid future headaches, develop a carefully controlled tagging structure early.

• By Brien Posey
• 10/09/2017

A little over a year ago, I wrote an installment of this column called "Curb VM Sprawl by Putting AWS Tags to Work" in which I introduced the concept of tagging an Elastic Compute Cloud (EC2) instance.

However, EC2 isn't the only resource for which Amazon Web Services (AWS) supports tagging. You can create tags for a wide variety of resource types. That being the case, I wanted to revisit the topic of tagging and talk about some tagging best practices.

For those who might not have experience with tagging, a tag is essentially just an identifying label that you can apply to an AWS resource. Tags generally include a key and a value. If you were tagging AWS virtual machine instances, for example, an example of a key might be Role, and some examples of values for the Role key might be Web Server or Mail Server. AWS provides instructions and lists the limitations associated with key creation here.

The No. 1 thing that I have learned about tagging AWS resources (or anything else, for that matter) is that tagging seems unimportant at first, but becomes far more important as the number of objects increases. To show you what I mean, let's forget about AWS for a moment and talk about something that we are all familiar with: photos.

Let's suppose that I have a folder on my hard drive containing two photos. Because there are only two photos, tagging those photos would probably be overkill. After all, it should be pretty easy to tell the photos apart from one another, especially if you give each photo a descriptive name.

But what happens if that folder suddenly contains 20,000 photos instead of just two? Worse yet, what if all of those photos have names like DSC0001234? It would be almost impossible to find a specific photo unless you had some way of identifying it.

That's where tags come into play. Tags let you search for specific attributes. In the case of my earlier example in which EC2 instances are equipped with a Role tag, the tag would make it easy to locate Web servers.

As useful as tags may be, however, they can easily get out of hand. As such, it is extremely important to create a plan upfront that will govern your tag use. There is no such thing as a tagging taxonomy that works for every situation. Even so, there are some best practices that you should keep in mind.

First, think about what it is that you hope to accomplish and how those tags will realistically be used. While it may be tempting to apply a zillion different tags to each object, I have found that when it comes to tags, a few well thought-out tags usually work out better than a large number of semi-random tags. Let me give you an example.

Last week I was in Colorado for space medicine and wilderness survival training. I will spare you most of the details, but the class involved numerous simulations in which a spacecraft had crashed in a remote area, and the crew had to care for one another's injuries and survive in the wilderness until help arrived. As you would probably expect, those of us who were in the class took quite a few pictures. So imagine how some of those pictures might be tagged.

I could conceivably tag the pictures based on who is in each picture, whether the picture was taken during the day or at night, whether the crew was in the spacecraft at the time of the accident or if they parachuted out -- the list goes on.

My philosophy regarding the establishing of a tag structure is to consider what I am likely to search for 20 years in the future. Twenty years from now, I may or may not remember that some of the simulations occurred at night or that some involved the use of parachutes. Even if I do remember those details, I probably won't be searching for the term parachute.

Instead, I would probably be more interested in just finding the pictures from when I did that space medicine class. Besides, applying lots of tags to every picture can be labor-intensive.

With that in mind, my approach to tagging photos is to use three tags: the year, a general description and a more specific description. In the case of the pictures from last week, for example, the year would be 2017. The general description would be Astronaut Training, and the specific tag would be Space Medicine and Wilderness Survival.

The reason why I use a general tag is because there may be more than one thing that falls under the general tag. If I searched for 2017 and Astronaut Training, for example, I would get the space medicine course pictures, but I would also find pictures from other training exercises that I have done this year, such as sea survival.

The important takeaway is that when you are planning an AWS tagging taxonomy, form a plan and stick to it. I recommend using a tagging structure that uses a mixture of general and specific tags. In the case of an EC2 instance, for example, you might use tags for things such as the server's role, the OS and the point of contact (i.e., who is responsible for the instance). In this case, the server's role and point of contact are really specific attributes, while the OS is a much more general (but useful) attribute.

When you develop a tagging taxonomy, you should also think about the ground rules for creating new tags. Some things to consider might include:

• Who is allowed to create new tags?
• Will the tags use upper case letters, special characters, et cetera?
• Will the tags use a single word or more than one word?
• Is there a master list of the tags that have been created and the purpose of each tag?

Ultimately, there is no right or wrong way to create tags. The key is to use a system that works for you. Regardless of your approach to tagging, it is important to have a carefully controlled tagging structure in place. Otherwise, your tags can become meaningless.