[Tagging AWS resource] #AWS

tagging_aws_resource.md

Tag is metadata of a resource; allow up to 50 tag per resource.

Why tagging resource

1. Reporting: in AWS console or billing reports
2. Management: tools like Stax use tags to group and classify your cloud data
3. Permissions: can restrict permission based on tag data
4. Filtering: AWS Resource Groups allow the console to be filtered based on tag
5. Automated Processes: used to drive scheduled shutdowns, backup policies, or AWS config policies

Build your own tagging policy based on practices, publish it within your organisation and then enforce it.

Tips

1. store it in your own DB
2. AWS Tag as foreign key to point to it
3. store a limited amount of redundant data in AWS Tags, e.g. app name, owner email, to avoid cross system look up
4. non-human-readable tag + human-readable tag, e.g. ApplicationGUID, ApplicationName
5. Do not duplicate AWS data which is avaiable through AWS APIs
6. use Name tag for redunant data, it's frequently used in AWS console to identify resource by you. If your Name is PROD-app101, add another two: info:env=PROD and info:appId:101
7. Tag should be static (almost)
8. use Tag to reflect environment, e.g. load testing
9. use colon-separated namespace, e.g. aws:, myorg:
10. use camelCase for key name. kebab-case, e.g. stack-id, is not supported by all AWS resource types.
11. use a version number, e.g. info:taggingVersion for future
12. multi-value: tagName=value:value2 or tagName=value1-value2
13. multi-attribute: tagName=att1=v1/att2=v2
14. combination: tagName=att1=v1:v2/att2=v2:v3
15. Each tag should be defined with its scope, e.g. enterprise wide, team wide, or department wide and its compliance level, e.g. mandatory or optional. Your tagging policy should be defined and enforced.
16. define a time format and use it consistently, e.g. ISO6801
17. buildID for the infrastructure code
18. security tag, IAM Policy allows you to restrict access based on tag values

Eample