AWS Tags. What Are They Good For?

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 usecases 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 dont 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.

Tagging is a a first-class citizen in the latest release of our HyperCloud. We are also available on AWS Marketplace.

Manoj Nair joins HyperGrid from HPE where he was GM and VP of Product Management for Converged Infrastructure. His team was responsible for driving the Product Strategy and Roadmap across all elements of the Converged Portfolio & Infrastructure Management. Prior to HPE, Manoj was SVP leading strategy and R&D for the Public Cloud solutions at EMC. This was an incubation team working across the EMC federation of companies. Previously, Manoj was SVP & GM at RSA – responsible for IAM & Authentication product lines. Previously he led R&D and Product Management for RSA Security Management portfolio. Manoj also led R&D for EMC's internal incubation project, EMC Infoscape, as well as the architecture of the EMC PowerPath product family. Manoj has also held development and research positions at Data General, Novell and US NSF funded Research Labs. He is also the holder of over a dozen patents granted by USPTO in Systems Software, File systems, Information Management and Security. Manoj holds a M.S. in Computer Science from Clemson University. Forbes Technology Council, Official Member 2018

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.