AWS Tagging Strategy & Best Practices

Your ops team are driven to maximize performance with real-time alerting and remediation.

Your engineering teams are keen to move at pace, often automating everything in sight.

Your finance team is desperate to keep a lid on costs, reducing them wherever possible.

Your security & compliance teams need to minimize risk.

Your CTO wants all of it!

It turns out that your cloud architecture gets pulled in quite a few different directions. The more cloud services you adopt, the more interested parties you have. Spend goes up, managing risk becomes more complex, understanding your inventory becomes a full-time job.

This is where AWS tags come in.

In this guide, we'll cover everything you need to know to create a world-class tagging strategy:

• What are AWS Tags?

• AWS Tag Format

• Why You Need a Tagging Strategy

• Tagging Best Practices

• Common Challenges

• Conclusion

Azure & GCP Tagging Strategy & Best Practices

Although this guide is focused on tagging in AWS, the vast majority applies to GCP & Azure tags. Where possible, we'd recommend adopting a tagging strategy to suit your entire architecture.

What are AWS Tags?

AWS tags are labels that can be applied (optionally) to resources, including EC2 instances, S3 buckets, AMIs, and lots more. They are a simple way to add context to a resource.

Each tag comprises a key and a value, both of which you generate.

Their flexibility means that tags are a hugely valuable form of metadata and a great tool to help organizations manage their cloud architecture.

When done well, tagging is much more than just a just time-saving way to search and filter through your resource inventory. A comprehensive tagging strategy will help you understand your AWS usage, reduce your costs, monitor your performance, and manage your risk.

Tags also facilitate a cross-team focus, so each area of your organization can hone in on their area of responsibility. Whether you need a helicopter view or a detailed FinOps dashboard, resource tags are at the heart of it all.

Examples of keys include a resource's owner, environment, or project...  the possibilities are virtually limitless, though.

Here are some examples in the format key = value:

• owner = engineering

• project = marketingWebsite

• environment = production

• businessUnit = 016

• sensitiveData = true

• application = fin-app-1

• resize = false

What Format is an AWS Tag?

A single AWS resource can have up to 50 tags applied to it. AWS generated tags are the one exception; these are automatically generated, cannot be edited, and don't count towards the limit of 50.

Each tag comprises a key and a value, both of which you define.

System-generated AWS tags that aren't editable have keys beginning 'aws', e.g.

aws:createdBy

The tags we are mainly concerned with, user-generated tags, normally don't have anything populated before the key you have created, e.g.

environment

NB: In the wild, in some AWS reports, you might spot 'user' being prefixed before your key, e.g. user:environment. This is to differentiate your user-created tags from AWS' system-generated ones for the sole benefit of the reports.

A key is mandatory for all tags; they can be up to 128 Unicode (UTF-8) characters long. Tag values are actually optional and can be up to 256 Unicode (UTF-8) characters long.

The characters permitted in both keys & values vary slightly per AWS service, but in general UTF-8 letters, numbers and spaces are accepted, along with these special characters:

 _ . : / = + - @.

Tag keys must be unique on a resource, and each key can only have one value.

Importantly, tag keys & values are case sensitive (more on this later).

Why You Need a Tagging Strategy

A tagging strategy is a set of policies and processes, with reference points, that your team or organization agree to implement and live by.

Ultimately, your strategy is there to define how tags should be used in your AWS (and Azure) architecture.

Put simply, a best-in-class tagging strategy...

• Saves money
• Reduces risk
• Improves efficiency & agility
• Facilitates automation
• Provides clarity & answers questions

What are the Benefits?

With the addition of codeless cloud automation tools, like Hyperglance, tagging opens more doors than ever before.

We've included some great examples of how you can benefit from a tagging strategy, but the sky is the limit. Get a good team together for some ideation, and you'll amaze yourself with the problems you can solve (often within minutes!).

Save Money

• Use tags for resource allocation, e.g. owner, team, project, or cost center
• Use tags to help resource owners analyze their costs and plan/forecast for the future
• Find resources that were intended to have a temporary lifespan
• Find resources that aren't used 24/7, and should be automatically started and stopped
• Use resources to manage EC2 reserved instances and identify RI recommendations
• Enable cost-allocation tags, and use them in combination with Cost Explorer and a cloud management tool to identify many other cost-saving opportunities

Reduce Risk

• Tag resources based on their data/security risk, regulatory requirement, or internal policies
• Tag resources to manage IAM access/permissions
• Tag resources with owners to speed up decision making in critical situations
• Use tags in rules & conditions to implement monitoring & alerts, reducing increasingly common 'alert fatigue'
• Find resources that need updating
• Use a clear strategy to lead the way for your future organizational standards

Improve Efficiency

• Categorize resources to solve problems faster. Combine tags with a tool that simplifies your inventory, diagrams your cloud, and has a superior search function to AWS' own.
• Use tags to trigger automation and alerting. Start by identifying your team's most menial tasks and see how you can automate them.
• Tag resources based on how often they need manually reviewing
• Use tags to identify resources that should be opted out of certain automated tasks
• Use a clear strategy as the foundation to free up decision-makers, increasing your team's agility (and creativity!)
• Tag business-critical resources to improve operational focus and clarity, and adhere to SLAs
• If you're subject to audits, no matter internal or external, tag the relevant resources to save swathes of time processing auditor requests (not to mention managing the day-to-day operational risk of those resources)
• Quickly answer common questions from other people/teams in your organization, e.g.
  • How much does it cost to support this project?
  • Which team owns the most high-risk resources?
  • Who should I contact about a problem with this resource?
  • How many critical servers need updating?
  • Which resources should we stop at the weekend?

AWS Tagging Best Practices

The recipe for a great tagging strategy is no secret. Here are the ingredients:

1. Plan Your Tag List

Nail this stage and everything after becomes easier.

Realistically, in most organizations, you'll have stakeholders with requirements from a cross-section of teams.

Think about who has sufficient technical experience and could provide valuable input from areas such as:

• Compliance & security
• Finance
• IT operations & disaster recovery
• Database admin
• Engineering & product
• Process & business unit owners

When you get your team together, start by thinking about the outcomes you'd like, as opposed to the tags you want.

You're less likely to miss requirements if you work backwards from outcomes such as 'I want to be able to find & monitor resources that store sensitive data', versus jumping straight to a solution like 'I want a tag for resources that store sensitive data'. After discussion, the former might lead you to suggest a useful scale; the latter is more likely to end up as a less-detailed binary outcome.

Each desired outcome (requirement) should be mapped to propose a new/existing tag. And for each of those tags, make sure you know the answer to these questions:

• What will the tag be used for?
• Who will use the tag (people & system)?
• When will the tags be used?
• How will the tag be added?
• Who should have permission to add/edit/delete the tag?
• Who are the tag's stakeholders?
• What format will the tag key take?
• What format will the tag value take?
• How can the tag be future-proofed?

If you have one available, a technical business analyst is a good person to have around at this stage. They are trained in eliciting requirements from stakeholders, and tend to be strong at documentation.

You'll quickly come up with the desired list of tag keys and possible values. In case you're low on ideas, here are some nice tag keys that you might be able to apply in your organization:

Technical Tag Keys

These help engineers find and manage resources, e.g.

• Name
• Owner
• Application
• Environment
• Cluster
• Version
• SLA

Business Tag Keys

These help stakeholders plan and analyze, e.g.

• Team/Department
• Project
• Process
• Customer
• Cost Center
• Region
• Business Unit
• Revenue Impact
• Business Impact

Security Tag Keys

These ensure compliance, minimize risk, and save time in audits, e.g.

• Data Classification
• Compliance Classification
• Security Impact

Automation Tag Keys

These can be used to automate a resource start/stop and deletion, send alerts, schedule patches, exclude resources from resizing, and more, e.g.

• Start/stop date-time
• Review date-time
• Process opt-in/opt-out

2. Document Definitions & Standards

Plenty of people will live and die by this documentation, so make sure you give it its due.

Here are our essential tips for the documentation itself:

• Use a collaboration-friendly tool, such as Confluence
• Make sure that the standards are peer-reviewed for clarity & accuracy from time to time
• Use Grammarly to improve the readability
• Make sure there is a simple process for stakeholders to ask questions and request changes
• Depending on demand, you might want to start (and link to) a prioritised backlog of ideas and requests
• Review the tags with stakeholders regularly

For each tag, we'd recommend recording this information:

• The tag key, including spelling and casing
• The tag value, including spelling, casing, and possible options (where there is a fixed list worth communicating)
• The tag's purpose
• Whether each tag is mandatory or optional
• Useful background, e.g. who requested the tag, when was it implemented or last changed
• The tag's owner/decision-makers and related permission/rules

3. Agree & Implement Governance

By now, you should have an owner recorded for each of your tags. That person should understand the tag's value, and be empowered to make decisions about changes to it. It's ok if they don't make the changes, but they should be signing them off.

The next step, once you've agreed on your governance, is to implement it using IAM (Identity and Access Management). Start with a review of your tag permissions, then use rules & conditions to fine-tune how your tags work within AWS.

When you're allocating permissions in IAM, remember to think about who can change the tag editing permissions, not just the editing of the tag itself.

4. Tag Every Resource

Although tags are technically optional in AWS, we'd strongly recommend tagging all of your resources. AWS advise 'tag too much' over 'tag not enough', which is a sensible approach. With proper tagging unlocking so many possibilities, it's just not possible to get the most without them.

By the way, if you decide that there's a scenario where a tag isn't required, be clear about this in your documentation.

5. Don't Store Sensitive Data in Tags

This might sound obvious, but it's easily forgotten.

Tag names are prone to be shared via one of the many AWS services you use, often accidentally, maybe deliberately. If you choose to store sensitive or confidential data in your tag names, don't expect the data to stay secure for long.

AWS themselves make it pretty clear:

"Do not add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including billing. Tags are not intended to be used for private or sensitive data."

6. Use (Lower) Camel Case

As many a developer will testify, casing matters across a wide variety of life tasks. To compound that mantra, AWS tags are case sensitive, so there's a real chance that erroneous casing can trigger a rapid tagging strategy failure. Get this right to begin with, then monitor it closely thereafter.

We'd strongly recommend using camel case for your tag names, specifically lower camel case (i.e. lowerCamelCase)... as opposed to upper camel case (i.e. UpperCamelCase), aka Pascal case.

Case... closed?

7. Use a Tool to Normalize Tags

Best-in-class cloud management tools give you the ability to group tags.

This allows you to configure related tags, making it easier to manage and analyze resources and... account for (inevitable) errors.

This grouping can help normalize typos and inconsistencies in casing. All of this is possible in the app itself - no need to change the tags on your actual resources!

8. Change Tags in Bulk

The AWS Management Console comes with its own tag editor, which allows you to apply changes to tagging in bulk, saving valuable time. It's great for rectifying mistakes that have snowballed, or applying new tags to lots of resources.

If you're wasting time finding and fixing tagging problems, you should go a step further and use a tool that automates your tag updates.

9. Use a Future Proof Schema

When you're planning your tags, be sure to include business information that you can refer back to in the future. Technology and projects change constantly, but concepts such as 'purpose' and 'cost center' remain constant.

For each key, consider whether to have binary values, e.g. true/false or a fixed list of permissible values, e.g. high/medium/low.

Also, be sure you are clear about your use (or non-use) of enum values. As your organization grows, so might its tendency to prefer using enum values that are less likely to be broken by localized language and culture.

Lastly, even if you aren't multi-cloud yet, try and keep tag keys agnostic of your cloud service provider. Someone will thank you for it one day.

10. Think Beyond AWS

Azure has its own tagging capabilities, with very similar requirements to AWS' on tags. So, even if you aren't multi-cloud now, you might be in the future.

Where possible, try and avoid keys that are specific to AWS, just in case.

If you have multi-cloud knowledge available to you in your initial planning, it's unlikely to be a bad thing.

11. Monitor & Automate

Naturally, you're going to encounter a few challenges after implementing your strategy.

Firstly, the adoption will take time. Maintaining it thereafter is perhaps an even more complex beast, but it doesn't have to be.

• Plant the seed of consistency by including tagging requirements in CloudFormation templates
• Use AWS config, or a specialist tool, to monitor your resources, and alert you when something isn't right, e.g. missing or badly formatted tags (configure alerts wisely to avoid alert fatigue)
• When something goes wrong, use automation to put it right. With the progression in cloud management tools, there is very little value in a human constantly looking for bad and missing tags, let alone fixing them.

Common Challenges

As you might have already found out, implementing a tagging strategy can be challenging.

Here are some of the most common obstacles you'll encounter.

1. Starting With The Right People

As with any project, the difference between success and failure can be the stakeholder list. Spend time thinking about the potential decision-makers, as well as those who might be indirectly affected by your proposal (negatively or positively!).

Consider using lightweight project management or business analysis frameworks and tools to help you agree on your foundation, including decision-makers, benefits, and the requirements themselves.

Even if you're not adept at requirements analysis or project management, tools like BOSCARD terms of reference are relatively easy to digest and translate to your organization.

2. Updating & Reviewing Standards

You'll be doing well if this doesn't become a problem at least once in the first few months.

Implementing your initial standards will be half the challenge - keeping them relevant and updated will be something you'll need to become comfortable with.

As a starting point, when you first agree on your standards, ask the team how regularly they'd like to review them. Every time you meet, check that the cadence is still ok.

3. Overtagging or 'Tag Creep'

If your list of mandatory tags is starting to look excessively large, it's probably time to reassess things. Maybe those tags are taking the place of valuable cost-saving or security tags? Even if they aren't, there's a good chance that your teams will be struggling to uphold the standards.

Do what you can to figure out what's causing the tag 'creep'. A common reason is too many teams sharing an account, something that can also complicate management as you scale up your resources over time. Perhaps temporary tags aren't being deleted once a project is complete? Or, dare we say, maybe someone got trigger happy in Pascal case?

4. Not Utilizing Helpful Tools

As you start to scale your tagging strategy throughout your organization, implementing the standards becomes more complex and time-consuming. You'll quickly want to monitor for missing tags, typos, and more.

If you're going to take on a large manual edit, do the sensible thing and use the Tag Editor in your AWS console. If you're automating deployments, include your tagging requirements in CloudFormation templates.

Best-in-class tag strategies now comprise tools (e.g. Hyperglance and, to a lesser extent, AWS Config) that monitor tag standards, alert you to problems, and automatically fix them.