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.

Conclusion

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...

Mark Zuckerberg

Cloud Computing is too Expensive (Says Mark Zuckerberg)

At a recent conference about bio-sequencing, Mark Zuckerberg, founder of Facebook, called out that cloud computing costs are getting way too expensive, and that this is holding up advancements in medical research. He specifically called out AWS (Amazon Web Services) and jokingly suggested he may call Amazon founder Jeff Bezos to discuss.   Perhaps he […]

View Post
iStock

A Complete Guide to AWS Storage Services

Confused about the myriad of AWS Data Storage Options?  In this post we take a look at the whole range of AWS Storage services, and the different types of storage available.  By the end of the article you should know your EBS from your EFS and know which AWS storage services are right for your particular use […]

View Post
Application Modernization

Legacy Application Modernization and Cloud Migration

Do you have legacy systems and applications that are holding your business back? If so, then you could benefit from a program of legacy application modernization. This could revolutionize and improve your business technology platforms. Legacy applications can also benefit significantly from migrating to the cloud. The cloud offers improved scalability & reliability for your […]

View Post
ebook featured image

5 Steps to a Successful

AWS Migration

DOWNLOAD FREE EBOOK