Best Practices for Tagging AWS Instances

Amazon Web Services is an amazing set of tools. But when performing testing and configuration, it can be easy to lose track of your work and leave orphaned resources running without oversight. Doing so creates a security vulnerability and adds cost, because you pay for orphaned resources that you are not using.

How can you avoid this problem? One useful tip is to make the most of AWS tagging. When used properly, tagging AWS instances helps keep developers mindful of how applications are operated, built-out out and scaled, as well as how (and how well) they are constructed. In most scenarios, tags are invaluable for managing and tracking these precious resources.

In this post, I outline best practices to follow so that AWS tags are used most effectively.

Tag Everything (or Almost Everything)

First and foremost, tag everything you can. The AWS team has worked over the last couple of years to make nearly everything taggable in the AWS infrastructure, with very few limitations. Tags are the primary way one resource is differentiated from another. Since instances receive effectively random names (and in a modern architecture, are more likely to be stateless and ephemeral), it becomes increasingly important to know what an instance does from the API or management console.

Tags follow a key-value format and can be placed on almost any resource. Tags can be placed for any number of reasons, but most commonly are used to track an owner or responsible party or to provide contextual metadata for the resource. It is best to use a consistent key name. Even different cases can make tags difficult to aggregate. Resource Groups make for a great, readily accessible way to begin leveraging these tags to make your AWS account easier to navigate.

Most important is the placement of tags—especially for billing—on the most expensive items in your account. These are typically your Elastic Compute Cloud (EC2) instances. Common tags include:

  • listing the asset owner
  • noting which is which if you (inadvisably) run test, staging, and production in the same AWS account
  • annotating the role of an EC2 instance (such as database, web, app, or the specific service it serves)
  • a cost code or PO number linked to the instance

Tagging AWS Instances for Budgeting and Billing

Tagging AWS Instances for Budget

Tags can be used to track resources for cost accounting purposes. AWS will automatically create a createdby tag, for instance, so that you can see who (or what process) created the resource. AWS also offers a Cost Allocation report that you can use to keep track of which resources are tagged, and which haven’t yet been tagged. This can also help in planning budgets for future resource allocations, and tags will help improve estimates when using reserved instances. Even more helpfully, tags can be rolled up to a master payer account when using linked accounts, giving you visibility over and across all associated accounts.

Editor’s note: Tags are also used by Netuitive to filter metric data for performance, capacity, and cost optimization. Users can utilize tags to filter dashboards and compare metric widgets for specific parts of an environment, as well as configure alerting policies to include only elements with certain tags. Additional Netuitive EC2 cost reports contain a ‘cost by tag’ view, in which tags are leveraged to drill down into costs based on user-created parameters.

Tag Programmatically and By Policy

Since manual entry is prone to error, AWS provides a couple of different ways to drive consistency in applying tags. The AWS CLI and APIs both provide a means to create, delete, and describe tags. On the other end of the spectrum, AWS Config Rules can be used as a policy enforcement mechanism to ensure any resource that is created receives a proper base set of tags. As with everything in AWS, permissions to create, delete, or modify tags can be provided or revoked through the use of IAM policies.

Tags have a secret use as well. They can be used to inform and trigger other applications, especially if they are part of your development pipeline. Just as Jenkins can look for a change in certain branches in a code repository and trigger an action, why not use Lambda to trigger actions (like a Slack notification) when something in your AWS environment has changed?

Ultimately, good tagging hygiene will make for a healthy AWS account. It will make resources easier to navigate, and improperly configured or rogue resources easier to spot. Tagging is a critical tool in your AWS management toolkit.

AWS provides a helpful resource on tagging strategies here:

Over the last 10 years, Sara Jeanes has held numerous program management, engineering, and operations roles. She has led multiple team transformations and knows first hand the pain of traditional waterfall development. She is a vocal advocate for DevOps, microservices, and the cloud as tools to create better products and services. Sara is currently a Contributor at and can be found on Twitter @sarajeanes.

Netuitive’s cost reporting and other monitoring tools work seamlessly with your AWS tagging structure, to help you get the most out of your environment. Check out our 21-day, no-obligation free trial.