Using Tags to Organize AWS Resources

Tagging is an important capability that helps AWS customers streamline the process of managing their environments.

In this first in a two-part series, I provide an overview of tagging, describe how one can apply tags to resources, and highlight common tag classes that mature AWS customers employ. In the next post in the series, I will describe how people use tags to
streamline management of their AWS resources.

Tagging Basics

Consider the following before you begin using tagging:

Tags are
key-value pairs.
There is a default tag for most resources (“NAME”).
Most AWS services, including EC2, S3, and RDS, support customer-defined tags.
Some AWS services, such as ELB, SQS, and DynamoDB, do not support customer-defined tags (other than name).
There is a maximum tag key length of 128 characters and a maximum value length of 256 characters.
Tags are case sensitive.

Tagging Your Resources

You can define tags from the EC2 console by selecting the relevant instance and selecting the “Tags” tag. Alternatively, you can select the instance, click “Actions” and select “Add/Edit Tags.”





From there, you can add tags until your heart’s content.
Or until you hit the maximum of 10 tags per resource.





You can add or remove tags in bulk by navigating to the EC2 console and clicking on “Manage Tags”.
In S3, you can apply tags at the object or bucket level. You’ll note that tags are called “Metadata” in S3:





You an also manage tags via the AWS APIs. See
Amazon’s documentation for more information and helpful code samples for this.
Tags are automatically generated by certain AWS features, including Autoscaling groups, CloudFormation stacks, and OpsWorks stacks.

Common Uses for Tags

Most large AWS users have, at a minimum, the following five classes of tags:

Environment – Used to distinguish between production, development, and staging infrastructure.
Application – Used to describe the set of disparate resources (or clusters) that work together to deliver a product or service to a customer.
Cluster – Used to identify the set of instances that share the responsibility for perform a specific function as part of an application. Clustered instances typically share the same configuration and exist behind a load balancer.
Role – Used to describe the function of a particular node (web server, database server, load balancer, etc.). Instances within a cluster generally play the same role, but machines with the same role are not necessarily part of the same
cluster or application (i.e. web server for app 1, web server for app 2).
Owner – Used to identify the individual who is responsible for the instance.

Here is an illustration of how many customers use tags to represent their application taxonomies:





Other common tag classes include:

Customer – Used to identify the particular client that a particular resource serves.
Launch time – Used to help determine when an instance was created.
Cost center – Used for cost accounting purposes.

The good news is that you can add and update tags on the fly–so you can go back and change things whenever you need to. Nonetheless, I’d recommend putting some thought into how you want to organize things up front. Also, keep in mind that several key services
do not support custom tags. Most customers work around this by embedding key information in resource names for those services (i.e. “LB-Cluster1-App1-Prod”).

So why are we adding all of these tags anyway? Check out our next post to learn how you can use tags to streamline management for your AWS environment.