This page is about tags which also get named as resource tags and why they are very essential no matter what infrastructure is in use. Theoretically tags would be even more important in an hybrid setup.
Tags are unrelated to a certain cloud infrastructure. Actually tags should be used in any deployment – no matter if it would be AWS, GCP or an on-premise deployment such like VMWare, Openstack etc etc.
Certainly a strategy to tag and name given workloads correctly and in a meaningful way needs time and efforts. However, the payout is worth to get a company wide standard on tags established.
Typical questions seen when it comes to get certain workloads, deployment identified:
- What all does belong to an environment named A, or B, C?
- How much resources is consumed by client A vs client B?
- How much infrastructure does the company need to support the core business itself? (so corporate, shared services, ..)
- If I have to patch/move/tier down (..) environment ABC – which consumer may be impacted by doing so?
- In which AZ and Region is client A located from an application perspective?
- Where is environment ABCD located at?
- What hosts (instance types, storage etc) are connected to ABCD?
- Team A needs AWS API access to maintain (i.e. stop, start, bounce) ABCD, GHI*PRD, … – to which resource tag group does these instances belong to?
- Which ELB is used by ABCD?
- Which security group belongs to CDEF?
- What is AWS RDS XYZ used for?
- What can be turned off during the weekend, off hours?
- … and so forth
With utilizing cloud deployed instances historically used dedicated hostnames would become meaningless. Even more important if cloud native services are used (i.e AWS RDS, AWS DynamoDB, AWS ElastiCache etc etc) an option for a hostname simply does not exists. Consequently tagging becomes a key need quickly to be able to get identified the purpose for of a given workload – such like why, by whom, for what purpose.
The better and the more unified a tagging concept will be the better and more precisely various questions (as those above as a typical sample of questions) can be answered.
Any automated processes to maintain, monitor and handle workloads will benefit from a good tagging strategy.
Some tags might not be needed and therefore would add an overhead to maintain and handle those. For example adding a tag to note which available zone a given AWS EC2 instance would belong to would be an obsolete one since that information would be available by various options (AWS CLI, API, ec2-metadata and so on)
Need for conventions
Before a service or instance gets tag’d it would be recommended to get a naming convention established which will be generic enough to allow future (not yet known) abbreviations and mutations.
It also will be a need to figure the tag word syntax and structure:
- word total length
- special characters?
- word patterns and abbreviations such like prod vs prd
- human readable and programmatically usable
It typically makes sense to create a library or dictionary that helps to re-use and assign tags.
Anything to be tag’d
When an instance is deployed – such like an AWS EC2 instance – it’ll be likely to keep in mind to get this deployment assigned with proper tags for future reference.
However, there are more components and function in actual use to make the instance usable: Security Group, Subnet, EBS, Lauch Template, Auto Scaling Group and so forth. All components included would want to be assigned with tags properly to ensure a full 360° view on a given deployment.
To ensure anything gets assigned with proper set of tags a policy might be introduced which enforces proper tags.
- AWS IAM policies could help to enforce a tagging strategy
- AWS Lambda could be invoked automatically during instance deployment to catch if tags would be set correctly and if not could correct them behind the scenes, automatically
What are tags good for?
Beside the obvious benefit to just be able to know at a later point in time where some deployment has been made for and why it will help on cost assignments. The AWS Cost Explorer for example is a great and powerful tool to help to understand where budgets are spent for. The more precisely a given infrastructure is tag’d at the cost review the better company internal cost distributions could be handled, the better cost optimizations could be discussed. In short – an ability for meaningful cost analytics.
Asset management becomes easier to handle as well as OS patching via AWS services such like AWS SSM will become much less of a headache but rather would be an easy, foreseeable event alongside the ability to fully automate.