Tags are, quite simply, metadata stored against resources in AWS. They’re not required for AWS to operate, but they can be used to great advantage. A common example of a tag you have probably already used is the “Name” tag. Some resources will set that up for you automatically. You might use it to give an EC2 instance a human-readable description, rather than using the instance's ID or ARN. You might also use tags to denote who “owns” a particular resource from a technical standpoint, or to which cost centre a resource should be charged back to within your organization.

Not all resources in AWS support tags, but the majority you are likely to encounter will. Resources that do support tagging support up to 50 user-created tags.

Why Tag Resources?

Organising one, two, or a small handful of AWS resources is straightforward. You’ll be familiar with each and their details. When you progress to a larger environment of tens, hundreds, or thousands of resources, this becomes considerably more challenging.

Effective tagging makes questions like “who created this, why, and for which project?” easier to answer. Combined with the right tools, it enhances your ability to trace and audit resources.

Consider a few more common use cases for tagging:

  • Cost Reporting: easily carve out different teams, initiatives, business units, etc.
  • Management/Compliance: tools such as Stax use tags to group and classify resources
  • Permissions: IAM allows you to specify permissions on some resources using tags
  • Automation: Tags can store important metadata supporting your automation initiatives. For example, scheduled shutdowns of development/testing resources after hours, backup policies, build versions, and so on

Tagging is important to get right from the start (or, ideally, before you start!). It is a challenging technical endeavour to retroactively “fix” tags, so consider formalising your tagging policy at the beginning of your cloud journey.

How to Tag - Principles

The principles discussed here won’t necessarily apply in every situation, but in our experience, cover most organizations’ requirements comfortably. You may have your own additional business requirements to consider here as well.

Primary Data Source

AWS tags can provide a great amount of detail to your Configuration Management Database (CMDB). That said, AWS tags should not be your CMDB. A common practice is to retrieve information from AWS to update your CMDB, rather than the inverse.

Avoid Redundant Data

Tags are a great place to refer to information about a resource. Every tag that you mandate, however, must be kept up-to-date. If data is stored in your CMDB, and separately in a tag, and separately again in some other system, that’s multiple locations that must be updated every time a change occurs.

AWS data

AWS has some good APIs for retrieving information about resources, there’s no need to store that in a tag as well. For example, things like “Availability Zone”, “Region”, or “Instance Type” are attributes that generally shouldn’t need to be in a tag.

Tags should be static information

For a myriad of reasons, relying on tags for frequently-updated data is not a great idea. Only information that is static, or mostly static, should be stored in a tag. CreatedBy, Owner, CostCentre, are great examples of tags. LastRebooted, LastPatched, etc., might not be.

Environments are elastic

"Environment” is a great tag for tracking whether a resource is for production (“prod”), testing (“uat”/”test”), development (“dev”), or other use. You should work with your DevOps teams to determine an appropriate boundary for this tag. If modern deployment strategies are used, there may be many more environments than just those listed above, and it is crucial to ensure that tagging strategies work within the processes teams already use.

Multi-value tags

Resources support up to 50 tags, but tags can have fairly long strings as their values. Consider using JSON or another syntax to store multiple values in a single tag key. A tag with Key “backupDetails” might include a value such as “{“frequency”:”daily”,”time”:”0600Z”,”storagePolicy”:”shortTerm”}”. This approach allows for storing several pieces of information in a single tag value.

Mandatory and Optional Tags

Each tag should have a defined scope (e.g. organization, team, initiative), and state (mandatory/optional).

Data formats

If dates, times, numbers, or other formats are to be stored in tags, it's important to make sure the same format is in use across the board. Computers like consistency! Picking a consistent and machine-readable date/time/number format is worth it in the long run.

Implementing a Tagging Policy

Once tags have been devised, documenting, updating, and enforcing a tagging policy is important.

The Tagging Policy Document

The tagging policy document can live on your corporate wiki or wherever else you store system documentation. It should be accessible to anyone who is creating resources in AWS so that they can have all the information required to best meet the organizational requirements. Consider the following format for each tag:

  • Key name (e.g. “myorg:environment”)
  • Necessity (Mandatory or Optional)
  • Data Type (Number, text, chosen from a list of supported values)
  • Permitted values (e.g. “prod”, “uat”, “dev”, and so on)
  • Definition (explanation of why this tag key exists, and how the value is to be decided)

This is generally presented in a tabulated format to make it easy to read.

Enforcement

A great tagging policy is all well and good, but it’s useless without controls in place to ensure that the policy is adhered to. If you’re using Stax, these controls can be implemented at the technical level with Compliance Rules. If not, you could consider building your own automation to monitor, track, and alert on rule compliance.

For management purposes, Stax can use your resource tags to create groupings of resources, which are used to:

  • Compare metrics such as Cost across groups
  • Filter views of Stax down to specific groups
  • Assign compliance rules to specific groups

For example, a grouping might be “Environment”. The groups you create in Stax might be simply “Prod” and “Non-prod” — all myorg:environment tags names are allocated to one of these two groups in Stax, so that you can then track, compare and report on the cost, compliance or quality for all Prod and Non-Prod resources. You could assign specific compliance rules to Non-Prod, and different rules to Prod.

Using tagging makes management and visibility of AWS through a tool like Stax much easier, as you can align your Views of each critical metric to a specific part of your business, thus enabling you to have the right conversations with the right people, concerning issues such as cost.

Interested in learning more about how Stax works?
Topics
By Team Stax