Amazon Web Services (AWS) allows customers to assign metadata to their AWS resources in the form of tags. Each tag is a simple label consisting of a customer-defined key and an optional value that can make it easier to manage, search for, and filter resources. Although there are no inherent types of tags, they enable customers to categorize resources by purpose, owner, environment, or other criteria. This webpage describes commonly used tagging categories and strategies to help AWS customers implement a consistent and effective tagging strategy. The following sections assume basic knowledge of AWS resources, tagging, detailed billing, and AWS Identity and Access Management (IAM).
When creating a tagging strategy for AWS resources, make sure that it accurately represents organizationally relevant dimensions and adheres to the following tagging best practices:
- Always use a standardized, case-sensitive format for tags, and implement it consistently across all resource types.
- Consider tag dimensions that support the ability to manage resource access control, cost tracking, automation, and organization.
- Err on the side of using too many tags rather than too few tags.
- Remember that it is easy to modify tags to accommodate changing business requirements, however consider ramifications of future changes, especially in relation to tag-based access control, automation, or upstream billing reports.
Organizations that are most effective in their use of tags typically create business-relevant tag groupings to organize their resources along technical, business, and security dimensions. Organizations that use automated processes to manage their infrastructure also include additional, automation-specific tags to aid in their automation efforts.
Name – Used to identify individual resources
Application ID – Used to identify disparate resources that are related to a specific application
Application Role – Used to describe the function of a particular resource (e.g. web server, message broker, database)
Cluster – Used to identify resource farms that share a common configuration and that perform a specific function for an application
Environment – Used to distinguish between development, test, and production infrastructure
Version – Used to help distinguish between different versions of resources or applications
Date/Time – Used to identify the date a resource should be started, stopped, deleted, or rotated
Opt in/Opt out – Used to indicate whether a resource should be automatically included in an automated activity such as starting, stopping, or resizing instances
Security – Used to determine requirements such as encryption or enabling of VPC Flow Logs, and also to identify route tables or security groups that deserve extra scrutiny
Owner – Used to identify who is responsible for the resource
Cost Center/Business Unit – Used to identify the cost center or business unit associated with a resource; typically for cost allocation and tracking
Customer – Used to identify a specific client that a particular group of resources serves
Project – Used to identify the project(s) the resource supports
Confidentiality – An identifier for the specific data-confidentiality level a resource supports
Compliance – An identifier for workloads designed to adhere to specific compliance requirements
The following sections describe common tagging strategies to help identify and manage AWS resources.
Tags are a great way to organize AWS resources in the AWS Management Console. You can configure tags to be displayed with resources, and can search and filter by tag. By default, the AWS Management Console is organized by AWS service. However, the Resource Groups tool allows customers to create a custom console that organizes and consolidates AWS resources based on one or more tags or portions of tags. Using this tool, customers can consolidate and view data for applications that consist of multiple services, resources, and regions in one place.
AWS Cost Explorer and detailed billing reports support the ability to break down AWS costs by tag. Typically, customers use business tags such as cost center/business unit, customer, or project to associate AWS costs with traditional cost-allocation dimensions. However, a cost allocation report can include any tag. This allows customers to easily associate costs with technical or security dimensions, such as specific applications, environments, or compliance programs. The table to the right shows a partial cost allocation report.
Resource or service-specific tags are often used to filter resources during infrastructure automation activities. Automation tags are used to opt in or opt out of automated tasks or to identify specific versions of resources to archive, update, or delete. For example, many customers run automated start/stop scripts that turn off development environments during non-business hours to reduce costs. In this scenario, Amazon Elastic Compute Cloud (Amazon EC2) instance tags are a simple way to identify the specific development instances to opt out of this action. For scripts used to locate and delete stale, out-of-date, or rolling Amazon EBS snapshots, snapshot tags can add an extra dimension of search criteria.
IAM policies support tag-based conditions, enabling customers to constrain IAM permissions based on specific tags or tag values. For example, IAM user or role permissions can include conditions to limit EC2 API calls to specific environments (e.g. development, test, or production) or Amazon Virtual Private Cloud (Amazon VPC) networks based on their tags. Support for tag-based, resource-level IAM permissions is service specific. When leveraging tag-based conditions for access control, make sure to also define and restrict who can modify those tags. Please see the IAM documentation for detailed information about leveraging tags to control API access to AWS resources.
As mentioned in the general best practices, an effective tagging strategy uses standardized tags and implements them consistently across AWS resources. Customers use both reactive and proactive approaches for governing the use of tags in their AWS environments. Reactive governance leverages tools such as Tag Editor, detailed billing reports, AWS Config Rules, or custom scripts to identify improperly tagged resources.; Proactive governance leverages tools such as AWS CloudFormation and AWS Service Catalog to ensure standardized tags are consistently applied at resource creation. More rigorous forms of proactive governance include automation to regularly scan an AWS environment’s tags and quarantine or delete improperly tagged resources.
The most suitable governance approach for an organization primarily depends on the customer’s AWS maturity model. Reactive governance typically works the best for organizations that have not fully developed a tagging standard or that are not yet ready to proactively enforce a tagging strategy across the organization. Proactive governance works well for more mature organizations, especially organizations that can incorporate a tagging strategy with other standardization efforts, such as standardized environment builds using AWS CloudFormation or AWS Service Catalog.