This was originally posted on our blog on August 12, 2020: https://www.cloudforecast.io/blog/aws-tagging-best-practices/

Part 1: An Introduction to AWS Tagging Strategies

If you've worked in Amazon Web Services for long, you've probably seen or used AWS cost allocation tags to organize your team's resources. AWS tags allows you to attach metadata to most resources in the form of key-value pairs called tags. In this guide (the first in a three-part series), we'll cover some of the most common use-cases for AWS tags and look at some best AWS tagging best practices for selecting and organizing your AWS tags. Finally, we'll explore some examples of AWS resource tagging strategies used by real companies to improve visibility into their resource utilization in Amazon Web Services.

Why use AWS Tags?

AWS tags can help you understand and control your AWS costs. AWS Cost Explorer allows you to use tags to break down your AWS resource usage over time, while tools like CloudForecast keep you informed of your spending proactively.

Understanding and controlling your costs isn’t the only reason you should AWS tags to tag your resources. You can use AWS tags to answer a variety of questions, including:

• Which team member is the point of contact for this AWS resource?
• How many of our servers have been updated with the latest version of our operating system?
• How many of our services have alerting enabled?
• Which AWS resources are unnecessary at low-load hours?
• Who should have access to this resource?

Before you start adding AWS tags to all of your AWS resources, it's essential to create a strategy that will help you sustainably manage your tags. AWS tags can be helpful, but without a consistently applied plan, they can become an unsustainable mess.

Read also: How Tagging AWS Resources can Reduce Your Bill

AWS Tagging Best Practices

While there isn't a perfect AWS tagging strategy that works for every organization, there are a few AWS tagging best practices that you should be familiar with.

1. Know how each tag you create will be used

AWS cites four categories for cost allocation tags: technical, business, security, and automation. Consider which of these categories you will need when creating your AWS tagging strategy:

• Technical Tags help engineers identify and work with the resource. These might include an application or service name, an environment, or a version number.
• Business Tags allow stakeholders to analyze costs and the teams or business units responsible for each resource. For example, you might want to know what percentage of your AWS spend is going towards the new product you launched last year so you can determine the return on investment of that effort.
• Security Tags ensure compliance and security standards are met across the organization. These tags might be used to limit access or denote specific data security requirements for HIPAA or SOC compliance.
• Automation Tags can be used to automate the cleanup, shutdown, or usage rules for each resource in your account. For example, you could tag sandbox servers and run a script to delete them after they're no longer in use.

2. Decide which AWS tags will be mandatory

As you decide which AWS tags you need and how you will use them, set rules about their usage. Decide which AWS tags will be mandatory, what character should be used as a delimiter, and who will be responsible for creating them. If you already have many resources, you may have to delegate tag assignment to the teams who use them.

3. Develop a consistent AWS tag naming convention

Choosing a consistent and scalable AWS tag naming convention for your AWS tag keys and values can be complicated. There are different AWS tag naming convention rules about which characters you can use and how long AWS tag keys and AWS tag values can be. Be sure to read up on these tag restrictions before you select a AWS tag naming convention.

A common AWS tag naming convention pattern is to use lowercase letters with hyphens between words and colons to namespace them. For example, you might use something like this:

Where mifflin is the name of your company, eng designates this tag as being relevant to the engineering team, os-version indicates the purpose of the tag, and 1.0 is the value.

4. Limit the number of AWS tags you adopt

There are technical and practical limits to the number of tags you should use. First, AWS enforces a 50-tag limit on each resource. More importantly, engineers will have a hard time keeping track of and remembering how to properly use tags if you require too many.

Fortunately, many tags can be avoided by relying on AWS's built-in resource metadata. For example, you don't have to store the creator of an EC2 instance because Amazon adds a createdBy tag by default. Decide which tags you need and try to limit the creation of new tags.

5. Automate AWS tag management

As the number of AWS resources in your account grows, keeping up with your AWS tags, enforcing conventions, and updating tags will get increasingly difficult. In Part 2 and 3 of this guide, we'll look at how you can use Terraform, CloudFormation, Cloud Custodian to manage tags across your resources.

Amazon also offers tag policies, tagging by resource group, and a resource tagging API to help you govern and assign tags in bulk. Automating as much of the tag management process as possible will result in higher quality, more maintainable tags in the long run.

6. Plan to audit and maintain AWS tags

You will undoubtedly need to revisit your AWS tags periodically to make sure they're still useful and accurate. Depending on how many resources you deploy, this might mean setting a reminder to audit your tags every quarter, or it might mean creating a committee to review and update tags every month. We'll look at some tools and strategies for managing your tags in Part 3 of this guide.

Amazon Web Services provides a comprehensive document of their recommended practices for tagging resources. Be sure to review it if you're new to AWS tags and want to dive deeper into some of these AWS tagging best practices.

Example AWS Tagging Strategies

Let's look at a few real-world tagging strategies. These are adapted from real companies that use AWS tags to organize their resources for various reasons. While they may differ from your use case, they'll offer you insight into how you might tag your resources in AWS.

Example 1: A Service-Based AWS Tagging Strategy

A widespread pattern for tagging resources is by service and environment. For example, if an organization has two services (cart and search) and two environments (prod and dev), they might set up the following tags:

If these two services share a single RDS instance, then the database can be tagged service=cart|search (to indicate that this resource serves both services) and the architecture might look something like this:

If you choose an AWS tagging strategy like the one above, you have to consider how tags will change over time. For example, if you add a new service that shares the same RDS instance, you’ll have to update the database’s tags to include the name of the new service. For this reason, some teams opt to use a single tag to indicate that a resource may be used by all services (eg: service=common).

Service-based tagging strategies like this are usually a good starting point if you'd like to understand which services contribute the most to your AWS costs. The business team can use these tags to see how much they're paying for each service or environment and reach out to the appropriate contact if they have questions.

Example 2: A Compliance AWS Tagging Strategy

AWS cost allocation tags may also help organizations manage governance or compliance. Tools like CloudForecast through their AWS Tagging Compliance feature can help you maintain tagging compliance if you tag your resources in specific ways. These AWS tags might be used to limit access or run extra security checks on particular resources.

In this example, the company tags resources that contain user data with user-data=true so that they can audit them more frequently and ensure they meet specific standards. All resources have a contact and env tag to designate the responsible team member and ensure someone is accountable for keeping them up to date.

Using a compliance tagging strategy does not preclude you from using other strategies as well. One of the advantages of AWS tags is that they let you segment your AWS resources in a nearly infinite number of ways.

Example 3: Account Segmented Environments

The final example we'll look at is an account-segmented tagging strategy. While AWS's IAM permissions allow you to assign access to users, roles, and teams granularly, some organizations may want to go a step further.

"When resources across heterogeneous logical environments are colocated, it is deceptively easy to accidentally use resources from another environment if you're not extraordinarily careful when provisioning resources and designing network/IAM policies" - Platform Engineer at Cars.com

In this example, the organization designated business unit and team tags to each resource, with each environment having a separate AWS account.

This allows them to generate reports in each environment to see what their resource costs are for the marketing (mktg) unit is vs. the data warehousing (data) unit. If the team uses this method of account-segmented tagging, they’ll need to use a master account to see resource usage across their entire organization. You can also use CloudForecast to generate regular cost reports and breakdowns across multiple AWS accounts.

Conclusion

Any organization that uses AWS at scale will need to develop a tagging strategy that works for them. Consider the AWS tagging best practices and examples above, as well as your organization's goals.

Once you decide on a AWS tagging strategy, you will need a plan for adding and maintaining AWS cost allocation tags. In the next part of this guide, we'll look at tools you can adopt to ensure your engineering teams are using AWS tags consistently across all your AWS resources.