These are some notes on AWS Tagging Best Practices. See reference section below for sources.

Amazon Web Services 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.

 

Tag Use Cases

Following are some sample use cases for using tags.

Resource Groups

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.

Cost Allocation Tags

AWS Cost Explorer and Cost and Usage Report support the ability to break down AWS costs by tag. Typically, customers use business tags such as cost center, business unit, or project to associate AWS costs with traditional financial reporting dimensions within their organization.

Automation

Resource or service-specific tags are often used to filter resources during infrastructure automation activities. Tags can be used to opt into or out of automated tasks, or to identify specific versions of resources to archive, update, or delete.

Operations Support

Tags can be used to integrate support for AWS resources into day-to-day operations including IT Service Management (ITSM) processes such as Incident Management.

Access Control

AWS Identity and Access Management (IAM) policies support tag-based conditions, enabling customers to constrain permissions based on specific tags and their values.

Security Risk Management

Tags can be assigned to identify resources that require heightened security risk management practices, for example, Amazon EC2 instances hosting applications that process sensitive or confidential data. This can enable automated compliance checks to ensure that proper access controls are in place, patch compliance is up to date, and so on.

 

Tag Requirements

Tag stakeholders in an organization typically include IT Finance, Information Security, application owners, cloud automation teams, middleware and database administration teams, and process owners for functions such as patching, backup/restore, monitoring, job scheduling, and disaster recovery.

It’s important to employ a consistent approach in tagging your AWS resources. If you intend to use tags for specific use cases, as illustrated by the examples in the introduction, you will need to rely on the consistent use of tags and tag values.

Consider tags from a cost/benefit perspective when deciding on a list of required tags. While AWS does not charge a fee for the use of tags, there may be indirect costs (for example, the labor needed to assign and maintain correct tag values for each relevant AWS resource).

Tags can be required, conditionally required, or optional. Conditionally required tags are only mandatory under certain circumstances (for example, if an application processes sensitive data, you may require a tag to identify the corresponding data classification, such as Personally Identifiable Information or Protected Health Information).

Tagging decisions are reversible, giving you the flexibility to edit or change as needed in the future. However, there is one exception—cost allocation tags—which are included in AWS monthly cost allocation reports. As a result, when you introduce a new cost allocation tag it takes effect starting from that point in time. The new tag will not apply to past cost allocation reports.

 

Tag Naming

Keep in mind that names for AWS tags are case sensitive so ensure that they are used consistently. For example, the tags CostCenter and costcenter are different, so one might be configured as a cost allocation tag for financial analysis and reporting and the other one might not be. Similarly, the Name tag appears in the AWS Console for many resources, but the name tag does not.

A number of tags are predefined by AWS or created automatically by various AWS services. Many AWS-defined tags are named using all lowercase, with hyphens separating words in the name, and prefixes to identify the source service for the tag. For example:

• aws:ec2spot:fleet-request-id
• aws:cloudformation:stack-name
• lambda-console:blueprint
• elasticbeanstalk:environment-name

Consider naming your tags using all lowercase, with hyphens separating words, and a prefix identifying the organization name or abbreviated name.  Using all lowercase with hyphens for separators avoids confusion about how to capitalize a tag name. For example, anycompany:project-id is simpler to remember than ANYCOMPANY:ProjectID, anycompany:projectID, or Anycompany:ProjectId.

• anycompany:cost-center
• anycompany:environment-type
• anycompany:application-id

Consider keeping tag names under 255 characters. Note that for multi-cloud strategy, we should consider other tagging restrictions from each of the cloud platforms. For example Google Cloud Platform supports lower-case tag names only and limited to 63 characters.

 

 

Name tag

Assigning names to AWS resources is another important dimension of tagging that should be considered. This is the value that is assigned to the predefined AWS Name tag (or in some cases by other means), and is mainly used in the AWS Management Console.

Naming for EC2 instances is a good place to start. Most organizations have already recognized the need to standardize on server hostnames, and have existing practices in effect.

Name tags could follow its own naming convention for the values. For example, the values could use periods as environment seperators:

• prod.public-az1.subnet
• services.az2.subnet
• prod.webesrver.sg
• prod.ec2-s3-access.role
• prod.companyname.kms-key

 

Cost Allocation Tags

AWS provides detailed cost reports and data extracts to help you monitor and manage your AWS spend. When you designate specific tags as cost allocation tags in the AWS Billing and Cost Management Console, billing data for AWS resources will include them. Remember, billing information is point-in-time data, so cost allocation tags appear in your billing data only after you have (1) specified them in the Billing and Cost Management Console and (2) tagged resources with them. Typically, financial reporting covers a variety of dimensions, such as business unit, cost center, product, geographic area, or department.

AWS provides options for consolidated billing by associating payer accounts and linked accounts. You can also use AWS Organizations to create master accounts with associated member accounts to take advantage of the additional centralized management and governance capabilities.

For shared resources, you may need to allocate costs to several applications, projects, or departments. One approach to allocating costs is to create multi-valued tags that contain a series of allocation codes, possibly with corresponding allocation ratios, for example:

companyname:cost-center = 1600 | 0.25 | 1625 | 0.20 | 1731 | 0.50 | 1744 | 0.05

If possible, consider identifying existing cost sharing or chargeback mechanisms within your organization—or create new ones—and associate shared AWS resources to individual cost allocation codes defined by that mechanism.

Apply your cost allocation tags across all resource types that support tagging to get the most accurate data for your financial analysis and reporting.

After you or AWS applies tags to your AWS resources (such as Amazon EC2 instances or Amazon S3 buckets) and you activate the tags in the Billing and Cost Management console, AWS generates a cost allocation report as a comma-separated value (CSV file) with your usage and costs grouped by your active tags. You can apply tags that represent business categories (such as cost centers, application names, or owners) to organize your costs across multiple services.

The cost allocation report includes all of your AWS costs for each billing period. The report includes both tagged and untagged resources, so that you can clearly organize the charges for resources. For example, if you tag resources with an application name, you can track the total cost of a single application that runs on those resources. The following screenshot shows a partial report with columns for each tag.

The following restrictions apply to the AWS generated tags:

 

 

Tag Governance

You may decide to include tags on your AWS resources for which data is already available within your organization. For example, if you are using a Configuration Management Database (CMDB), you may already have a process in place to store and maintain metadata about your applications, databases, and environments.

In 2016, the number of tags per resource was increased to 50 (with a few exceptions, such as S3 objects). Because of this, it’s generally recommended to follow good data management practice by including only one data attribute per tag.

There are many automation solutions available at AWS Labs (https://github.com/awslabs) and the AWS Marketplace (https://aws.amazon.com/marketplace) that make use of compound tag values in their implementations.

AWS offers a variety of tools to help you implement proactive tag governance practices; by ensuring that tags are consistently applied when resources are created.

Service Catalog

AWS Service Catalog allows organizations to create and manage catalogs of IT services that are approved for use on AWS. These IT services can include everything from virtual machine images, servers, software, and databases to complete multi-tier application environments. AWS Service Catalog enables a self-service capability for users, allowing them to provision the services they need while also helping you to maintain consistent governance – including the application of required tags and tag values.

One way to reduce human error is by using AWS Service Catalog. One of the key features of AWS Service Catalog is TagOption libraries. With TagOption libraries, you can specify required tags as well as their range of allowable values.

IAM

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow or deny their access to AWS resources. When you create IAM policies, you can specify resource-level permissions, which include specific permissions for creating and deleting tags. In addition, you can include condition keys, such as aws:RequestTag and aws:TagKeys, which will prevent resources from being created if specific tags or tag values are not present.

For consistency, best practice is to propagate tags and tag values across related resources. If resources are created by AWS CloudFormation templates, they are created together in groups called stacks from a common automation script, which can be configured to set tag values across all resources in the stack.

Access Control

While the use of tags for this purpose is convenient, it can be easily circumvented if users have the ability to modify tag values in order to gain access that they should not have. Take preventative measures against this by ensuring that your IAM policies include deny rules for actions such as ec2:CreateTags and ec2:DeleteTags.

Even with this preventative measure, IAM policies that grant access to resources based on tag values should be used with caution and approved by your Information Security team.

Remediating Untagged Resources

Automation and proactive tag management are important, but are not always effective. Many customers also employ reactive tag governance approaches to identify resources that are not properly tagged and correct them. Reactive tag governance approaches include (1) programmatically using tools such as the Resource Tagging API, AWS Config rules, and custom scripts; or (2) manually using Tag Editor and detailed billing reports.

Tag Editor is a feature of the AWS Management Console that allows you to search for resources using a variety of search criteria and add, modify, or delete tags in bulk.

With AWS Config, you can create rules to check resources for required tags and it will continuously monitor your resources against those rules. Any non-compliant resources are identified on the AWS Config Dashboard and via notifications. In the case where resources are initially tagged properly but their tags are subsequently changed or deleted, AWS Config will find them for you.

You can use AWS Config with CloudWatch Events to trigger automated responses to missing or incorrect tags. An extreme example would be to automatically stop or quarantine non-compliant EC2 instances.

 

 

References

AWS Tagging Best Practice White Paper
https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf

Tagging in AWS
https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html

EC2 Tagging
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html

Cost Allocation Tags
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html

AWS Cost Usage Report
https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html