I read AWS tagging best practices whitepaper which was published in December 2018 and distilled 5 takeaways.
1. Use cases – tags have several use-cases including:
- Cost allocation – using AWS Cost Explorer you can break down AWS costs by tag
- Access Control – AM policies support tag-based conditions
- Automation – for example tags can be used to opt into or out of automated task
- AWS Console Organization and Resource Groups – e.g. create a custom console that organizes and consolidates AWS resources based on one or more tags
- Security Risk Management – use tags to identify resources that require heightened security risk management practices
- Operations Support – I find this use case tightly related to the automation use case
2. Standardized tag names and tag values –
There are only two hard things in Computer Science: cache invalidation and naming things.Phil Karlton (check here)
A good practice as suggested in the whitepaper is to gather tagging requirements from all stakeholders and only then start implementing but a minimal step can be to define a convention for tags names and values that everyone can follow, see example from the document below.
3. Cost allocation tags delay – this is something I experienced personally – “Cost allocation tags appear in your billing data only after you have (1) specified them in the Billing and Cost Management Console and (2) tagged resources with them”. And even then it can take around 24 hours to appear, take it into account.
4. Tag everything – sounds trivial but sometimes organizations tag only some of the resources, tag everything you can to get a more comprehensive and accurate data of your expenses. A nice feature in the Billing and Cost Management Console is the ability to find resources the don’t have a specific tags so you can easily find out what you missed.
5. Tags limitations – until 2016 AWS allowed up to 10 tags for a given resource. The current limit is 50. It definitely allows much more but it is still a limit to bear in mind when creating a tagging strategy. One way to avoid it is by using compound values, e.g. “anycompany:technical-contact = Susan Jones;firstname.lastname@example.org; +12015551213” rather than a tag for each attribute (e.g. “anycompany:technical-contact-name = Susan Jones”).