Introduction to EC2 Tags
A Tag is an identifying label you attach to your AWS resource. As the name suggests, they function similarly to the tags you’d find in the books of your library, something to categorize the individual items by or the specific sections they’ll be available in. AWS Tags, however, offer a wide range of benefits through its simple categorization.
A tag has two components you get to define, a key and a value(optional). Tags are a great way to organize your AWS resources in various categories based on their purpose, environment, who maintains them, etc. When you have the same resource in n numbers, you are left without an identification metric.
Tags exist to save you from such a predicament, you can also manipulate multiple resources falling under the same tag together so that you won’t have to assign a function for each of them separately. For example, you could define a set of tags for your account's Amazon EC2 instances that helps you track each instance's owner and stack level
Tagging Use Cases
Tagging has several important use cases it can cover. A standardized approach to tagging is the surefire way to target these use cases.
Common tagging use cases:
Cost allocation
Automation
Access control
Security
Cost Allocation
Tags can assist in cost allocation in the way of AWS Cost Explorer and Cost and Usage Report. These services can analyze your resources by categorizing them into tags. Analyzing the cost of resources pertaining to specific projects or one area of business will become feasible when applying tags onto said resources.
So let’s say you have three different teams and you need to track the cost of these individual teams and assign responsibility to their utilization of resources. Tags could let you categorize the resources by departments or teams to give you clarity in exactly the flow of costs.
Automation
Tags can be the on/off switch of individual resources partaking in a collective automation function. Tags can filter specific groups of resources to automation activities across the whole environment, unrestricted by the walls of department/project/application, etc. Of course, this requires a tagging strategy and practice specific to automation goals. A key example of this is to start/stop AWS EC2 instances in non-business hours to save up on costs greatly. Also, new resources being launched with tags would be automatically grouped with your cost-saving functions.
Access Control
Defining access control through tags is also widely supported. AWS Identity and Access Management policies enable customers to limit permissions of resources by associating resources with tags and values. This way, resources can have limited access to test/prod/dev environments by their tags.
Security
The applications hosted by distinct resources will have their individual security risk levels. Identifying and managing these various levels of security through the use of tags is the simplest way to improve security management across the infrastructure. Combining this with automation allows for automated compliance checks/access control and as a result, increased security.
Why Implement a Tagging Strategy?
As the cloud continues to grow, organizations migrate many of their resources over to the cloud and have an abundance of services to keep in check. This is in many ways a positive change but the maintenance of these resources is a chore especially when you have it all loaded up in one account.
Tracking all these resources in terms of who uses what and where the utilization goes to is the primary necessity of a tagging strategy. A strategy is required because it has to be scalable across your organization. This way all of the resources can be filtered by its application, the teams that run it, the responsible members of its expenses, or by its type. These various identification methods also pave the way for careful reporting and targeted alerts for analytics purposes.
There are various tagging strategies you can employ based on the purpose of your tags. You can have multiple purposes based on what application or department it focuses on as well.
The purpose is determined by the use cases you are focusing on. For example, if you are tagging for cost allocation then your tagging strategy should focus on clear communication of your financial dimensions.
Typically, financial reporting covers a variety of dimensions, such as business unit, cost center, product, geographic area, or department. Aligning cost allocation tags with these financial reporting dimensions simplifies and streamlines your AWS cost management.
Best Practices for EC2 Tagging
Tag Every Resource
Ensure each resource is tagged. Nametags are a unique identifier so every resource that carries one can be individually manipulated. This comes in handy when you have the same resource in multiple numbers. Name tags also aid in manipulating the resources not only through AWS services but also third-party tools/platforms meant to utilize these resources.
Improve Identification with Camel Cases and Namespaces
Camel Cases are a very simple concept of naming the tags in the format of attaching multiple words in a string. The detailed method of tagging helps identification for your team and for anyone else that requires using the resource.
Namespaces are an allowed gimmick in tagging that also improves the identification of the resources upon looking at its tags. Here, the tags that all belong to one team, department, or any specific category is mentioned with a namespace, and then subsequently, it’s purpose or designation is added.
Team:proj1
Team:TestEnv2
And so on.
Limit Permission of Tags for Access Control
Tags used to manage your access control policies must have strict limitations on who gets access to creating, deleting, and modifying them. You could create IAM policies that utilize conditional logic to restrict access but this could be bypassed if the unauthorized party has access to modifying the tags directly. Make sure you prevent this by applying to deny rules on ec2: CreateTags and ec2: DeleteTags actions. Also, have your information security team run analyses on your tagged resources, their existing policies and permissions, and the vulnerabilities they pose.
Design a Schematic of your Tagging Strategy
When having to present your infrastructure to a separate entity, a schema of your resources properly tagged using the earlier tips and a standardized approach improves its readability and comprehension. This is part of having a solid tagging strategy.
Owner:department
Owner:team
Owner:application
The above strategy lets a single owner’s various resources be identified and analyzed based on the department it serves, the team it functions in, and the application it powers. This way cost and utilization reports can be analyzed by each department and the resources they avail or manipulate, automate or rightsize the resources deployed for any of the applications attached. As stated earlier, your strategies can be devised by focusing on the objective of your tags. Cost allocation? Access Control? Or Security? The purposes can dilute the tagging strategy and you can name accordingly.
Constrain Tag Values with AWS Service Catalog
Keeping track of the data values in a designated tag becomes a chore if you are to enter it manually. Tags that are being entered through automation scripts will have its own review as part of the process but manually entered tags opens up opportunities of error. The TagOption library that is part of the AWS Service Catalog lets you specify the required tags and the range of values, this reduces the likelihood of missing or invalid tags as limit and required values are already made aware.
Common Mistakes
Implementing tags into your environment has a few considerations for you to take note of. Some are minor things, some are major but all of them could leave lasting damage if you are running a large infrastructure.
Tags are case sensitive. This is a very small thing but when you have so many resources to account for, overlooking this fact could come back to bite you. Hence, I recommend you strictly use lowercase characters unless you are using namespaces.
Spelling mistakes when naming is also a common error that leaves a lot of resources outside the categories you are trying to form.
Tags attached to a single AWS resource, by default, only applies to that resource alone and not the resources attached to it as a dependency.
Maintaining Tags
Manually tagging each resource before you deploy it is a wishful scenario that is unlikely to happen, you will have several resources missing tags. Not to mention the challenges offered in case you make any of the common mistakes mentioned earlier, automating the tagging process by writing a script or creating a custom workflow can ease the process and secure its success during the deployment pipeline.
You can also use AWS config to identify resources with missing tags by writing rules that will alert you of such. This could also be achieved with the aforementioned workflows.
Conclusion
In essence, tagging is a very simple concept that lends your infrastructure easier means of categorizing to keep track of all that is happening and to communicate the developments clearly with people other than your own. In order to maintain tagging policies at scale, it's recommended to automate your tagging without the use of long-winded scripts. A platform like TotalCloud can not only help you with the automation & keeping track of all tags, but also report you on missing tags so you don't lose out on anything important.
Top comments (0)