Among Amazon Web Services’ helpful “Answers” pages there are five AWS tagging best practices recommended. We expand on the recommendations to explain the benefits of each best practice—highlighting where AWS users should take care when developing tagging strategies in order to avoid potential issues in the future.
AWS first gave users the option to tag EC2 resources in 2010. Since then the option has been extended to most AWS resources, enabling AWS users to assign metadata to each resource with user-defined keys and values. This process makes it easier to manage, search for, and allocate cost categories to resources. Tags can also be used to implement access controls.
However, tags are only effective if everyone is using an identical tagging strategy. Furthermore, AWS tags are case-sensitive; so if one user was to tag their resource “DemoServer” and another user tag their resource “Demoserver,” the two resources would appear independently in search results and not combined for the purpose of cost analysis.
The 5 AWS tagging best practices
In order to help users develop an optimal and identical tagging strategy, Amazon recommends 5 AWS tagging best practices:
- Always use a standardized, case-sensitive format for tags, and implement it consistently across all resource types.
- Consider tag dimensions that support the ability to manage resource access control, cost tracking, automation, and organization.
- Aim towards using too many tags rather than too few tags. You can assign up to fifty AWS tags per resource.
- Implement automated tools to help manage resource tags. The tools should be capable of reallocating existing tag names to comply with a new strategy.
- Remember that it’s easy to modify tags to accommodate changing business requirements, however, consider the ramifications of future changes, especially in relation to tag-based access control, automation, or upstream billing reports.
The five AWS tagging best practices make perfect sense if AWS is the only cloud service that’s going to be used—ever. The benefits of a standardized, case-sensitive format for tags has already been explained, and the names given to tag keys should meaningfully reflect the resources’ roles (Environment, Billing, Application, etc.). Naturally, the more tags applied, the greater the clarity into resource usage and cost.
With regard to the AWS tagging best practices related to automated tools and modifications, the two recommendations are similar. If users automate the governance of strategies via tagging policies, managing the strategies is much easier. Non-compliant tags can be corrected, and changes in business requirements (with regard to tagging) can be addressed effortlessly. Effectively, policy-driven automation can future-proof an AWS tagging strategy provided care is taken in developing strategies.
Where to take care when developing tagging strategies
The key area of consideration when applying AWS’ tagging best practices is asking yourself if AWS will be the only cloud service provider you’ll ever use. If it is, great. Just ensure each stakeholder has their say about which keys and values to use and create a universal strategy with regard to spellings and abbreviations, and how to deal with non-conforming tags.
If AWS isn’t the only cloud service provider you plan on using, you must give deeper thought to the format of tags and the characters used in them. Not every cloud service provider provides the same tagging agility as AWS. For example, AWS tags are case-sensitive and allow numbers and special characters, but Google resources can only be tagged using lowercase letters, while Azure tags are not case-sensitive and the use of certain special characters is not allowed.
Tagging issues can also surface when businesses adopt a multi-cloud strategy. With AWS, the tag value field can accommodate 256 characters and Google Cloud Platform places a limit of 63 characters to the tag value field. Consequently, when developing a tagging strategy for a multi-cloud environment, consider the lowest common denominator.
More about policy-driven automation to govern tagging strategies
Regardless of a business’s current cloud strategy, policy-driven automation is the most effective way to manage resource tags. Not only can policy-driven automation correct non-conforming tags or reallocate tag names to implement a new or modified tagging strategy, the actions taken can be configured to each business’s individual requirements. For example:
- System administrators can configure a policy to stop an instance if it’s lacking a tag or if the key field has been left empty.
- Policies can be configured to send an email notification to the resource owner if its tag is missing a value description.
- If a word has been spelled incorrectly a Lambda function can be run to correct the spelling.
- Similarly, if non-compliant abbreviations have been used in either the key or values fields, the function can change the abbreviations to long-form descriptions.
With ongoing policy monitoring, tagging strategies are constantly enforced for easier resource management, accurate cost analyses, and more effectively security. These key benefits of AWS’ tagging best practices overflow into other areas of cloud management such as reserved instance management and scheduling on/off times for non-production resources. For this reason, implementing a unified cloud management platform can be the best way to maximize the benefits of AWS’ tagging best practices.
CloudHealth is a total cloud management solution. Not only does our platform simplify tag management policies, it also reports on where costs can be saved, performance improved, and security gaps closed. Whether you are exclusively using AWS to deploy resources in the cloud, have already migrated to multi-cloud, or are balancing a hybrid environment, we’d love to discuss AWS’ tagging best practices and how CloudHealth can help you enforce your tagging strategy quickly and easily.