An Overview to AWS Tagging Strategies
It is best practices to tag all resources within AWS. Most firms do not tag, or do not properly tag their resources. This makes it difficult to allocate costs and resources used by area, department or even by environment. Along with using AWS Organisations (OUs, SCPs); tagging deployed resources from the sandbox, to development, testing, and production, is necessary. This means building an environmental management design, which should include tagging including the use of AWS cost allocation tags to organize all deployed resources and services. AWS allows you to attach metadata to these resources in the form of key-value pairs called tags.
Why Tag AWS Resources?
AWS cost allocation tags can help a company understand and control AWS costs. AWS Cost Explorer will use your tags to analyse and organise AWS resource usage over time by area (dev, prod etc) and produce an overview of resource and service consumption by area within the firm.
Tagging services are useful to help control costs. But that is not their only function. We need to know who, from which department and what services they deployed. Some architectures contain 1000s of Virtual Machines and dozens if not hundreds of containers. We will very quickly have out of control sprawl and cost issues. Tags will tell us the following:
- Who deployed the service or resource, when, why?
- Who should have access to this resource?
- What part of the company is responsible for the service or resource?
- Who is the contact for the service?
- How many of the servers are updated (or not updated) with the latest OS patch?
- Is the service enabled for alerting and monitoring?
- Are the services right sized, or do we have low load capacity usage?
Key Take Away: You need to build an Environmental Control Document which outlines how all environments are controlled, monitored, and audited. This will include your tagging strategy. This plan must be implemented across the firm, implemented on every project, and reviewed at least every quarter.
AWS Tagging Best Practices from real Projects
There are many Tag strategies which can be valid. Firms may decide on different but equally productive and valid approaches. The key will be consistency and applicability. Make the strategy and approach SMART (simple, measurable, applicable, relevant, time-bound).
1. Each tag serves a purpose
AWS states there are four categories for cost allocation tags: technical, business, security, and automation. You will use all four.
- Technical Tags: identifies the engineering area which deployed and works with the service or resource. These tags must include application or service name, an environment, or a version number.
- Business Tags: allow stakeholders to analyse 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 clean-up, 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 are no longer in use.
All of these Tag categories are mandatory to use.
2. Develop a consistent AWS tag naming convention
The Environmental Strategy Document should outline a standardised and scalable AWS tag naming convention (or Meta-Data convention). 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. AWS has posted tag restrictions which will impact your tagging conventions. Please read these before developing the standard Tag approach.
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:
| Tag Key | Value |
| mydepartment:dev:os-version | ECom1 |
Tag: the company’s department (engineering group 03), I am working in Development (not production); the OS is RHEL 7.x; and the Value is my application named Ecommerce 1.
3. 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 effectively use tags if the Tag Strategy is too complicated.
Some 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 as a default. Decide which tags you need and try to limit the creation of new tags.
4. Automate AWS tag management
As the number of AWS resources grows enforcing conventions and updating tags will become increasingly difficult. As your landscape grows within AWS, you will need to use automated scripts to manage the resources and Tags including Terraform, CloudFormation, or a 3rd party product like Cloud Custodian. At a minimum consider building CloudFormation templates upfront and begin testing resource Tag management at some scale (Terraform is also good on AWS but does not have the native API integration). CFT to manage Tags are available on AWS and in GIT and other repos.
Amazon also offers tag policies, tagging by resource group, and a resource tagging API to help 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.
5. Audit and maintain AWS tags
Tagging resources will require on-going assessments and work. Depending on how many resources are deployed, it would be wise to audit the tags every quarter. A small committee may be set up to review and audit the Tags every month or quarter. Amazon Web Services provides a comprehensive document of their recommended practices for tagging resources.
==END