Tagging in Amazon Web Services (AWS) helps you keep your AWS assets organized. Their tag editor is a simple but effective asset-management tool that allows you to assign tags when creating or editing assets.
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 AWS tagging strategy from the start and advise them on general AWS tag best practices. This leads to the smooth and successful use of AWS across their business.
Having honed these strategies over the years, we’re happy to share our best practices for tagging in AWS with you in this article.
What are tags in AWS?
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 AWS tagging examples appear below:
Why use tags in AWS?
You should use resource tagging to group everything 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 the 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 the 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. 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 labelling 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 the overall authority of your tagging strategy to ensure that the number of tags and possible duplicates does 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) that adheres to AWS naming convention best practices from the start will be important to avoid “duplicate” tags with very similar keys and values that are intended for the same purpose.
Without agreement on an AWS 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.
AWS tag limits vs. your company’s tag limits
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 organizational 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 guidelines for AWS tagging
It’s important to realize that tags are not confidential and are visible in the AWS console as well as 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
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. 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 also 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 are being handled by people who are up to date with the latest AWS tools and best practices on tagging and everything else. Contact us or book a free discovery call to find out more about how we can help you.