AWS Tagging Best Practices

Voiced by Amazon Polly

Tagging in Amazon Web Services (AWS) helps you keep your AWS assets organized. It is a simple but effective management tool: when creating or editing assets you just assign the tags you want. However, it’s important to plan ahead and apply AWS tagging best practices, otherwise your infrastructure could soon end up a mess of disorganized and duplicated tags that are difficult to manage, defeating their purpose entirely.

At Logicata, we help our clients to devise a good tagging strategy from the start, and advise them on general best practices for tagging. This leads to smooth and successful use of AWS across their business. Having honed these strategies over the years, we now share our best practices for tagging in AWS with you in this article.

What are tags in AWS?

AWS tags are labels that you can attach to your AWS resources, including Elastic Compute Cloud (EC2) instances, Simple Storage Service (S3) buckets, and Relational Database Service (RDS) instances. Tags are small pieces of metadata to help you manage your AWS resources, consisting of a key (like “Environment”) and a value (like “Production”). The keys and values of tags should be short, text-based pieces of meaningful information that describe things such as the purpose, ownership, or grouping of an AWS resource. Some examples appear below.

Examples of AWS tags.
Examples of AWS tags.

Why use tags in AWS?

You should use resource tagging to group resources together in a way that helps your business to manage its AWS resources. The primary reasons for using tags tend to be either business/cost-related or technical/security-related. A business-related tag such as “CostCentre: Marketing014” can help with billing, enabling each department to easily track the overall costs of their resources by using a program such as AWS Cost Explorer to filter all the resources with their department-specific tag.

Technical tags are also useful as your business and number of resources grow. Tagging different environments such as “Staging” and “Production” means you can restrict access for making changes to production resources to a handful of trusted developers. You might also want to restrict access for security reasons: for this you could use a tag such as “SensitiveData: Yes”, and could set up a policy in AWS Identity and Access Management (IAM) policies to restrict access to a few trusted users.

If you regularly need to upgrade software running on your resources, It is much easier to do this if you make good use of tags. You can use tags to describe the software stack, last update time, or a version number on any resource. For example, EC2 instances could be tagged with “WindowsVersion: WindowsServer2019”, which would allow you to easily filter and find any resources that may require an upgrade to Windows Server 2022.

Tags aren’t just for humans — they provide a way to identify resources for the automation of tasks. You can tag resources that don’t need to be running out of office hours, and shut them down on a schedule based on this tag, saving your business money. There are many different options for running automated scheduled tasks in AWS, and one such option is AWS Instance Scheduler, which allows you to automatically turn off EC2 instances at certain times. These times can be defined in the tags themselves, for example “Schedule: mon-9am-fri-5pm”. This tag gets parsed by the Instance Scheduler, which is able to read dates and times that conform to a specified format.

Getting started: deciding on a tagging strategy for your company

Tagging and labeling all your AWS resources without having first defined a proper tagging strategy will result in a mess of too many tags that have overlapping purposes and a hodgepodge of naming conventions. This will create confusion among your engineers, who will need to remember all the different keys and purposes of each tag, and increase the chances of a mistake being made.

You should start on the right foot now by putting serious thought into your company’s tagging strategy, which will allow you to save time later instead of trying to retroactively fix your tags once they’re already in use. Ask yourself the following questions now to save time and headaches later:

Who will be in charge of tagging strategy for your company?

Someone needs overall authority of your tagging strategy to ensure that the number of tags and possible duplicates do not spiral out of control. Will this be you, or is there someone you can delegate this to? It should be someone with a good overview of both business needs and technical matters.

Which resources must be tagged and which tags will be mandatory?

Whenever a new tag gets created, your Tagging Strategist must decide (and then communicate to all relevant employees) whether this tag is mandatory or optional, and which types of resources must be tagged with this tag. Because of this, it also makes sense to have a policy that limits who is allowed to create new tags, to ensure that this practice is followed.

What naming convention and case system will you follow?

Agreeing upon a naming convention and case system (tags are case-sensitive) now will be important to avoid “duplicate” tags with very similar keys and values that are intended for the same purpose. Without agreement on a naming convention it is very easy to end up with tags such as:

  • “Environment: Production”
  • “environment: production”
  • “Env: Prod”
  • “Env: PROD”

In this example scenario, mismatched naming conventions may lead to a situation where an environment intended to be a production environment is not treated as one. This could cause big problems for the deliverability or reliability of your product or service. It’s worth familiarizing yourself with AWS’s restrictions on tags, as this may inform your tagging strategy.

What is the maximum number of tags your company will use?

The AWS tagging limit is 50 tags per resource. But you will fry your engineers’ brains if you expect them to remember company policies about that many tags. Limiting your number of tags will help avoid placing undue cognitive load on your staff. The simplest organization system is often the most effective!

How often will you audit your tags?

You’ll want to schedule regular times to audit your tags to ensure they’re fit for purpose. If tags aren’t providing enough value, be bold and delete them to reduce the mental load on everyone who has to remember what they are and what they do.

General best practices for AWS tagging

It’s important to realize that tags are not confidential and are visible in the AWS console and to other AWS services, so you should keep sensitive information out of your tags. This includes personally identifiable information, credentials, and business-sensitive information that you don’t want to be shared across departments.

Planning your tagging scheme in advance will reduce the chance of having to update lots of resources later on. It’s good practice to avoid tags that are AWS-specific (in either their key or value) as you may later switch to another cloud provider and have to redesign your tagging scheme and re-tag your assets.

Tag keys should be self-descriptive and relevant. You do not want an engineer (or automated script) to accidentally shut down critical infrastructure due to confusion over the meaning of a tag. If you do decide to change the key of a tag, you should ensure that any AWS policies that reference the old tag key are updated.

Tagging policies and management

AWS Organizations is a tool for centrally managing multiple AWS deployments. It includes tag policies that can enforce your naming conventions and agreed-upon case-sensitivity of tags. You can even specify a list of allowed values for a particular tag, or add some non-compliant values which can be flagged if used. You can use this to prevent tag duplication and mistyped tags.

You can group your resources together under the same tag using AWS Resource Groups. This lets you save time by applying bulk updates to your AWS resources.The AWS Resource Groups Tagging API lets you quickly find all resources that have a particular tag key or value, or apply bulk updates to tag or untag multiple resources.

Using an infrastructure-as-code approach such as AWS CloudFormation is another way to simplify the management of tags, as all tags are easily visible and searchable in your CloudFormation code. CloudFormation allows you to group together resources as a particular “stack” (a collection of infrastructure); for example, you could have a “Production” stack and a “Staging” stack. CloudFormation permits you to apply a tag at the level of either an AWS resource or a stack, and applying a tag at the stack level means you won’t need to apply the tag separately to multiple resources.


Managing large AWS deployments can quickly eat into your productivity time as the quantity and complexity of your AWS assets grow.

Tagging your resources will improve the manageability of your AWS fleet. However, dedicated efforts are still required to keep a handle on your infrastructure. Keeping your assets organized will ensure that as your deployment grows, it remains easy to manage. This reduces the time it takes your engineers to apply changes, and reduces the chance of a show-stopping mistake being made.

AWS contains a huge number of tools that allow you to build the infrastructure for your projects. Due to the scope and increasing number of these tools, it is all too easy for an inexperienced user to introduce a misconfiguration leading to reliability or security concerns. It is not reasonable to expect development teams to be well versed in all aspects of AWS.

Working with a Managed Service Provider such as Logicata ensures that your team can focus on developing and improving their products, instead of trying to wrangle AWS. Employing the talents of dedicated AWS experts will give you peace of mind that the reliability and security of your infrastructure is being handled by people who are up to date with the latest AWS tools and best practices on tagging and everything else. Contact us to find out more about how we can help you.

You Might Be Also Interested In These...

Money growth vector illustration, flat golden coins pile with revenue graph, concept of income increase or earnings, financial boost chart, success capital investment, cash budget isolated

Don’t get Caught Out by AWS Data Egress Fees…

It’s no secret that AWS, like most cloud providers, charge nothing for data ingress.  It’s free to put your data in to the cloud, yet they do charge for data egress – getting your data back out again.  This fact is often overlooked when modelling the business case for cloud versus on premise. Recently NASA […]

View Post
Data storage archive concept

What is AWS Database Migration Service?

AWS Database Migration Service is a simple and cost effective way to migrate live, petabyte scale databases both into and out of the AWS Cloud with virtually no downtime. Those databases could be hosted on premise, already in the AWS cloud, or in another cloud.

View Post
Abstract Amazon DynamoDB

AWS DynamoDB Pricing: 13 Tips to Reduce Costs

In this post, Karl Robinson introduces the technical elements of Amazon DynamoDB, and how to calculate DynamoDB Pricing. He also shares 13 invaluable tips on configuration to keep your Amazon DynamoDB Costs under control.   What is Amazon DynamoDB? Amazon DynamoDB is the AWS fully managed NoSQL database service, enabling AWS customers to build NoSQL […]

View Post
ebook featured image

5 Steps to a Successful

AWS Migration