Skip to main content

Tagging Strategy

Overview

AWS tags can help you understand and control your AWS costs. AWS Cost Explorer allows you to use tags to break down your AWS resource usage over time.

AWS Tags are also useful for:

  • Discovering which team member is the point of contact for this resource?
  • How many of our services have alerting enabled
  • Who should have access to this resource?

Tags should fall within the following categories. Technical, Automation, Business and Security. Below is a guide on our proposed tags. Tags with an * are deemed mandatory.

TechnicalAutomationBusinessSecurity
name* Resource Name (Human readable). This needs to be updated on a resource basis. An example would be Product Deduplication Queue, Product Deduplication Deadletter Queue and Product Deduplication Lambdadate/time Identify the date or time a resource should be started, stopped or deletedproject* Identify projects that the resource supports. This could be NewStore / Platform or Angliru
description* Brief description of what the resource is responsible for (transformation, formatting, validation etc)owner* Identify who is responsible for the resource. This can be the email of the person who worked on it. These can be namespaced to give more context owner:team owner:department
terraform* True if infra has been provisioned by Terraformclient Identify which client the resource belongs to.
ver* Distinguish between versions of resources or applications
gitlab_environment_name* Distinguish between development, test, and production resources. This is managed by Gitlab CI
gitlab_project_url* The project url in Gitlab
gitlab_pipeline_url* The pipeline url that create the resource in Gitlab
gitlab_pipeline_triggerer* The user in Gitlab which triggered the pipeline

Best Practises

  • name tag - The first best practice is ensuring that all your resources have a Name tag. Name is a tag which is used by AWS, and many services that provide users with additional support for their AWS account. The name tag should be unique for the resource.
  • lowercase - Where possible, use lowercase for your tag keys and values.

Limits and requirements

  • For each resource, each tag key must be unique
  • Each key can only have one value
  • The tag key must be a minimum of 1 and a maximum of 128 Unicode characters in UTF-8
  • The tag value must be a minimum of 0 and a maximum of 256 Unicode characters in UTF-8

Implementation, Automation, Auditing and Maintenance

Above we have defined what our mandatory tags are that we need to include on a resource basis.

When it comes to implementing them we can use variables with built in validation. This means when we run terraform plan we will get error feedback. Validation rules can be as complex as the Terraform config language allows so functions such as distinct() and regex() are available.

In terms of tag compliance we are able to leverage the power of AWS Config.

AWS Config allows us to identify resources which still require tagging, and will notify us when new, untagged resources are added, or previously tagged resources are deployed without tags.

We can setup AWS Config via terraform and share the implementation to other accounts once it has been proven out. Notifications can be delivered to an S3 bucket or via a SNS topic. AWS comes with 128 managed rules which you can apply. However for the sake of this document we are interested in required-tags.

Resources