How-To

Best Practices for AWS Tagging Revisited

The trick to using a minimal number of tags is to make sure that all of the tags that you do use are both meaningful and useful.

• By Brien Posey
• 04/09/2019

A couple of years ago, I wrote an article in which I discussed my own personal approach to tagging Amazon Web Services (AWS) resources. Within that article, I used the example of tagging a large collection of photos, and treated the tags as searchable metadata describing each photograph. The general approach that I used in that article would work fine for tagging data files (such as photographs or documents), and it could even be used to tag Amazon Elastic Compute Cloud (EC2) instances. As an organization grows, however, my previously described three-tag system probably wouldn't be adequate. That being the case, I wanted to take a step back and discuss some tagging practices that I've adopted more recently.

One of the things that I feel like I really got right in my previous article was the need for tagging consistency. Let's suppose for a moment that you wanted to tag each of your AWS resources with a version number. The tags probably wouldn't do you much good if you tagged some resources with a tag named Version and other resources with a tag named Ver. Making consistent use of tag names not only makes resources searchable, it also allows you to perform tag-based automation.

As important as naming consistency may be, however, not every tag will be appropriate for every object. Let's pretend for a moment that you have a large collection of videos, and you create a tag called Resolution, because you want to differentiate between HD videos and 4K videos. While the Resolution tag makes perfect sense for videos (and maybe even for photos), it wouldn't make sense for use with an object such as an EC2 instance or an Amazon Elastic Block Store (EBS) volume. The point is that while you'll likely have some general-purpose tags that are appropriate for every object regardless of type, you'll likely have some other tags that will only be applied to certain types of objects.

So what are some examples of general-purpose tags that might be valid for all of the objects within an organization's AWS environment? Obviously you're free to come up with tags of your own, but here are a few of the tags that I like to use:

Name: This one is obvious. Every object in AWS has a name associated with it.

Application: An application tag doesn't really work all that well for tagging data files, but it works pretty well for other AWS resources. After all, a group of EC2 instances, a back-end database, an EBS volume and a security group might all be part of the same application. Having an Application tag makes it easy to figure out what a particular object is used for.

Environment: The Environment tag can be really useful, but it doesn't necessarily work for every organization. This tag is most useful in AWS environments containing a mixture of production and dev/test resources. You might tag a particular resource as being a production resource or a test resource. Of course, many organizations create several test environments, so you could even use this tag to identify to which test environment the resource belongs. The Environment tag doesn't work for every organization because some organizations isolate their production and dev/test resources from one another by using separate subscriptions.

Owner: The Owner tag is another really important one. Over the years I've seen several examples of organizations losing track of resources. What usually ends up happening is that an administrator needs to perform a migration, or an upgrade, or some other low-level function on a particular collection of virtual machines (VMs). However, the administrator doesn't actually know who the workload belongs to, or what it does (the admin may have inherited the VM from someone else). After a considerable amount of research, the administrator may even discover that the workload belonged to someone who left the company several years ago, and is no longer being used by anyone.

Regardless of whether or not the workload is still being actively used, just figuring out who it belongs to can sometimes be a major undertaking. Using tags to identify the owner or even the department can make this process far less complicated and time-consuming.

Incidentally, having an owner tag can also be useful for reporting purposes, because it makes it easy to identify all of a particular person's or department's AWS resources.

Although many people recommend creating a really rich tagging ecosystem, my personal philosophy is to keep the number of tags to a minimum. Excessive tagging is labor-intensive, and it makes it much more difficult to maintain tagging consistency. The trick to using a minimal number of tags is to make sure that all of the tags that you do use are both meaningful and useful. It's also important to accept the idea that you'll likely have to create some new tags (and possibly even retire old tags) in the future as your environment evolves.