Resource tags may seem unimportant or trivial as you get started on AWS. But as your estate grows tags are fundamental to operational scalability and managing sprawl in your AWS account. In this blog we go over some of the key reasons why you should spend that extra time tagging your AWS resources.
Some History On AWS Account Management
Most AWS customers use accounts as a unit of autonomy and security boundary between environments. For example, the QA team and the production team each have their own accounts, often connected to separate VPCs. Then, they link all the accounts together to a central account with consolidated billing enabled. The end result looks like a star topology, the central billing account in the center, all the other accounts around it.
This makes it hard to create the linkage between AWS spend and business initiatives. To the central bill paying account, the individual resources are anonymous; anonymization is the enemy of accountability. Therefore, tags are the only way in AWS to bring back the accountability and trackability needed to establish good governance.
Tagging Basics
Each AWS resource can have up to 50 tags, so you can create a multi-dimensional tagging strategy. For example, an object can be simultaneously tagged by ProjectID, Owner and Application, making it possible to track this object by any of these properties.
They key use cases for tagging are
- Cost Allocation: This is probably the most common use case for tagging. AWS Cost Explorer and third party tools allow you to visualize and report using these tags. But, before you can use them, you have to go to the billing section of the AWS management console. enable “Cost Allocation Tags” and choose which tags you want to see in AWS Cost Explorer.
- Organizing Resources: You can create resource groups which allow you to view and manage your resources as a collection. A resource group is not a static collection, it is query based so resources are dynamically added as they are tagged. Resource groups can have their own tags as well, so they can be nested into other resource groups.
- Automation: You can use tags to drive key automation tasks such as backup, startup, shutdown and so on. For example, you could configure your backup software to only backup instances which have the tag Production or DoBackup set to True. The DevOps community has embraced tags as the way t
- Managing Permissions: You can create policies that allow access to resources that have specific tags set. For example, you can create a policy for all QA users that only gives them write access to resources that have the QA tag set.
- Managing Serverless Deployments: Developers building Lambda applications use tags as a way to group and track the frequency and cost of each function invocation. A typical Lambda function can be a part of several applications across regions, tags make it easier to access and analyze a specific set by filtering on those that contain a specific tag.
The AWS Management Console also allows you to name some resources (for example, you can give an instance a name); but, these names are just values for a tag called “Name”. The AWS Management Console is smart enough to display the value of the Name tag.
Tagging Best Practices
Tagging is often being the best (and in cases like Lambda, the only) way to manage operations at scale. Therefore, it is important to use tags appropriately. Below are some best practices we’ve gathered, as end users who run sizeable AWS estate and as developers who build a set of management tools for AWS.
Best Practice 1: Tag Early, Tag Often
Tags are not retroactive, any tag created today will not reflect itself in a report on yesterday’s activity. It is better to err on the side of using too many tags than using too few. If you need to modify these, AWS makes it easy to modify tags to accommodate changing business requirements.
Best Practice 2: Tagging Policy
Make sure to create an appropriate tag policy. Your tagging policy should accurately reflect your organizational setup. Define a set of mandatory tags, for example ProjectID, ApplicationName, OwnerContact, that must be defined for all resources.
Best Practice 3: Tags are Case Sensitive
Never forget that tags are case sensitive. Make sure your policy accounts for this.
Best Practice 4: Automate Tagging
Use automation to deploy tags. Ensure your automation templates (CloudFormation, Ansible, Chef, Serverless, SAM etc.) templates are applying tags appropriately.
Best Practice 5: Cost Allocation Tags
Enable cost allocation tags. Cost allocation is the most-cited reason for using Tags, but this is disabled by default. You have to manually set it up in the Billing section of the Management Console and choose which tags are reflected in the Cost and Usage Reports.
Best Practice 6: Tagging for User Governance
Use tags to control access. Use tags in IAM to control access to resources. This will not only make IAM management easier (fewer policies to manage), but will also ensure that your users are using tagging to identify their objects.
Best Practice 7: Tag Compliance
Enforce Tag Compliance. There’s no point in having a policy if you don’t enforce. Ideally you would want a tagging dashboard that monitors tag utilization and allows you to remediate the issue from the dashboard.
So What is Tagging Good For?
Tagging is the most effective way in AWS to handle deployment sprawl. When you have a number of resources, but no accountability in how they are deployed and paid for. For this reason, managing tags and ensuring compliance as as important as the tagging process itself.
