Tagging Best PracticesAWS Whitepaper

Tagging Best Practices AWS Whitepaper

Tagging Best Practices: AWS WhitepaperCopyright © Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is notAmazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages ordiscredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who mayor may not be affiliated with, connected to, or sponsored by Amazon.

Tagging Best Practices AWS Whitepaper

Table of ContentsAbstract and introduction .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Introduction .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Are you Well-Architected? .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

What are tags? .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Building your tagging strategy .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Defining needs and use cases .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Defining and publishing a tagging schema .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

AWS Organizations – Tag policies ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Implementing and enforcing tagging .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Manually managed resources .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Infrastructure as Code (IaC) managed resources .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11AWS Service Catalog and external ITSM resources .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12CI/CD pipeline managed resources .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Enforcement .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Measuring tagging effectiveness and driving improvements .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Tagging use cases .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Cost allocation and financial management .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17AWS Cloud Financial Management .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Cost allocation tags .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Building a cost allocation strategy .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Operational considerations and reporting .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Cloud operations and automation .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Tags for Business Continuity .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Tags for Operational Observability ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Tags for identifying application resource collections .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Tags for incident and event management .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Tags for patching .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Data security, risk management, and access control ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Access control ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Data security and risk management .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Tags for data classification and regulatory data retention .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Data lake strategy .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Conclusion .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Contributors ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Further reading .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Document history .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Notices .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33AWS glossary .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

iii

Tagging Best Practices AWS WhitepaperIntroduction

Tagging Best PracticesImplement an Effective AWS Resource Tagging Strategy

Publication date: April 22, 2022 (Document history (p. 32))

Amazon Web Services (AWS) allows you to assign metadata to many of your AWS resources in the formof tags. Each tag is a simple label consisting of a key and an optional value to store information aboutthe resource or data retained on that resource. This whitepaper focuses on tagging use cases, strategies,techniques, and tools that enable you to categorize resources by purpose, team, environment, or othercriteria relevant to your business. Implementing a consistent tagging strategy can make it easier to filterand search for resources, monitor cost and usage, as well as manage your AWS infrastructure at scale.

IntroductionAWS enables you to easily deploy your workloads in the cloud by creating resources, such as AmazonEC2 instances, Amazon EBS volumes, security groups, and AWS Lambda functions. You can also scaleand grow the fleet of AWS resources that hosts your applications, store your data, and expand yourAWS infrastructure over time. As your AWS usage grows to many resource types spanning multipleapplications, you will need a mechanism to track which resources are assigned to which application. Usethis information to support your operational activities, such as cost monitoring, incident management,patching, and access control.

In on-premises environments, this knowledge is often captured in knowledge management systems,document management systems, and on internal wiki pages. With a Configuration ManagementDatabase (CMDB), you can store and manage the detailed metadata using standard change controlprocesses. This approach provides governance, but requires additional effort to develop and maintain.You can take a structured approach to the naming of resources, but a resource name can only hold alimited amount of information:

Structured approach to resource naming

For example, EC2 instances have a predefined tag called Name that provides similar functionality andallows you to name workloads as they are moved to AWS.

In 2010, AWS launched resource tags to provide a flexible and scalable mechanism for attachingmetadata to your resources. This whitepaper will guide you through the process of developing and

1

Tagging Best Practices AWS WhitepaperAre you Well-Architected?

implementing a robust tagging strategy across your AWS environment. This guidance will help youensure tagging consistency and coverage that supports your decision-making and operational activities.

Are you Well-Architected?The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you makewhen building systems in the cloud. The six pillars of the Framework allow you to learn architectural bestpractices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems.Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you canreview your workloads against these best practices by answering a set of questions for each pillar.

For more expert guidance and best practices for your cloud architecture—reference architecturedeployments, diagrams, and whitepapers—refer to the AWS Architecture Center.

2

Tagging Best Practices AWS Whitepaper

What are tags?A tag is a key-value pair applied to a resource to hold metadata about that resource. Each tag is a labelconsisting of a key and an optional value.

Tags that a user creates and applies to AWS resources using the AWS CLI, API, or the AWS ManagementConsole are known as user-defined tags. Several AWS services, such as AWS CloudFormation, ElasticBeanstalk and Auto Scaling, automatically assign tags to resources that they create and manage. Thesekeys are known as AWS generated tags and are typically prefixed with aws. This prefix should not be usedin user-defined tag keys.

There are usage requirements and limits on the number of user-defined tags that can be added to anAWS resource. For more information, refer to Tag naming limits and requirements in the AWS GeneralReference guide. AWS generated tags do not count against these user-defined tag limits.

Table 1: Examples of user-defined tag keys and values

Instance ID Tag Key Tag Value

CostCenter 98765i-01234567abcdef89a

Stack Test

CostCenter 98765i-12345678abcdef90b

Stack Production

Table 2: Examples of AWS generated tags

AWS Generated Tag Keys Rationale

aws:ec2spot:fleet-request-id Identifies the Amazon EC2 Spot Instancerequest that launched the instance

aws:cloudformation:stack-name Identifies the AWS CloudFormation stack thatcreated the resource

lambda-console:blueprint Identifies blueprint used as a template for anAWS Lambda function

elasticbeanstalk:environment-name Identifies the application that created theresource

aws:servicecatalog:provisionedProductArn The provisioned product Amazon ResourceName (ARN)

aws:servicecatalog:productArn The ARN of the product from which theprovisioned product was launched

AWS generated tags can exhibit a hierarchy. For example, in a CloudFormation template, you define aset of resources to be deployed together in a stack, where stack-name is a descriptive name that youassign to identify it. If you examine a key, such as aws:cloudformation:stack-name, you can seesuch a hierarchy:

3

Tagging Best Practices AWS Whitepaper

• aws – organization• cloudformation – service

• stack-name – parameter

User-defined tags can also have a hierarchy. Hierarchies can be useful in a variety of situations, forexample, to a managed service provider or venture capital business that is hosting workloads on behalfof different clients in a shared AWS environment. Each client can be given their own tagging scheme,agreed to by the partner, and includes the company name in the prefix:

Table 3: Example multi-client hierarchical tag use case

Tag Key Tag Value

company-A:application-class business-critical

company-B:impact-level very-high

In large and complex organizations where businesses can be acquired and divested regularly, a similarsituation is likely to occur until a new acquisition’s processes and practices are harmonized with the widergroup. The following examples show how hierarchical key prefixes can indicate a scope. These can bealigned to organizational owners.

Table 4: Example of additional hierarchical tag use cases

Use Case Tag Key Rationale Allowed Values

Data Classification example-inc:info-sec:data-classification

Info-sec defined set ofdata classification

sensitive,company-confidential,customer-identifiable

Operations example-inc:dev-ops:environment

Implement schedulingof test and devenvironments

development,staging, quality-assurance,production

Business Continuity example-inc:business-continuity:recovery-priority

Define workloadrecovery priority

0, 1, 2, 3, 4

Cost Allocation example-inc:cost-allocation:business-unit

Finance teams needscost reporting on eachteam's usage andspend

corporate,recruitment,support,engineering

Tags are simple and flexible. Both the key and the value of the tag are variable-length strings and cansupport a wide character set. For more information, see Tagging AWS resources in the AWS GeneralReference. Tags are case sensitive, meaning that costCenter and costcenter are different tag keys. Indifferent countries, the spelling of a word might differ, which might affect your keys. For example, in theUnited States one might define a key as costcenter, but in the United Kingdom, costcentre mightbe preferred. These are different keys from the resource-tagging perspective. Define spelling, case, andpunctuation as part of your tagging strategy. Use these definitions as a reference for anyone creating ormanaging resources. This topic is discussed in more detail in Building your tagging strategy (p. 5).

4

Tagging Best Practices AWS Whitepaper

Building your tagging strategyAs with many practices in operations, implementing a tagging strategy is a process of iteration andimprovement. Start small from your immediate priority and grow the tagging schema as you need to by:

Topics• Defining needs and use cases (p. 6)• Defining and publishing a tagging schema (p. 7)• Implementing and enforcing tagging (p. 11)• Measuring tagging effectiveness and driving improvements (p. 16)

Tagging strategy iteration and improvement cycle

Throughout this process, ownership is key to accountability and progress. As tags can be used fora variety of purposes, the overall tagging strategy can be split by areas of responsibility withinan organization. Tagging enables a programmatic approach to activities that depend upon thecharacterization of resources. The range of stakeholders that can benefit from tagging will depend onthe size of the organization and operational practices. Larger organizations can benefit from clearlydefining the responsibilities of the teams involved in building and implementing a tagging strategy.Some stakeholders can be responsible for identifying the needs (defining use cases) for tagging, whileothers can be responsible for maintaining, implementing, and improving the tagging strategy.

By assigning ownership, you are in a good position to implement individual aspects of the strategy.Where appropriate, this ownership can be formalized as policy and documented in a responsibilitymatrix (for example, RACI: Responsible, Accountable, Consulted, and Informed), or in a shared

5

Tagging Best Practices AWS WhitepaperDefining needs and use cases

responsibility model. In smaller organizations, teams might play multiple roles in a tagging strategy,from requirements definition to implementation and enforcement.

Defining needs and use casesStart building your strategy by engaging with stakeholders who have fundamental underlying needs toconsume metadata. These teams define the metadata that resources need to be tagged with to supporttheir activities, such as reporting, automation, and data classification. They outline how the resourcesneed to be organized and which policies they need to be mapped to. Examples of roles and functionsthat these stakeholders can have in organizations include:

• Finance and Line of Business need to understand the value of investment by mapping it to costs (highcost, low value resources) to prioritize actions that need to be taken when addressing inefficiency.Understanding cost vs value generated helps to identify unsuccessful lines of business or productofferings. This leads to informed decisions about continuing support, adopting an alternative (forexample, using a SaaS offering or managed service), or retiring an unprofitable business offering.

• Governance and Compliance need to understand the categorization of data (for example, public,sensitive, or confidential) and the criticality of the service (whether the service or application isbusiness-critical) to apply appropriate controls and oversight, such as permissions, policies, andmonitoring.

• Information Security (InfoSec) and Security Operations (SecOps) outline what controls must beapplied and which are recommended. InfoSec normally defines the implementation of the controls,and SecOps is generally responsible for managing those controls.

Depending on your use case, priorities, size of your organization, and operational practices, you mightneed representation from various teams within the organization, such as IT, Finance, Procurement,Information Security, Cloud Enablement, DevOps, Automation, and Cloud Operations. You also needrepresentation from application and process owners for functions such as patching, backup and restore,monitoring, job scheduling, and disaster recovery. These representatives help drive the definition,implementation, and measure the effectiveness of the tagging strategy. They should work backwardsfrom stakeholders and their use cases, and conduct a cross-functional workshop. In the workshop, theyget a chance to share their perspectives and needs, and help drive an overall strategy. Examples ofparticipants and their involvement in various use cases are described later in this whitepaper.

The stakeholders also define and validate the keys for mandatory tags, and can recommend the scopefor optional tags. For example, Finance Teams might need to relate a resource to an internal costcenter, business unit, or both. Thus, they might require that certain tag keys, such as CostCenter andBusinessUnit, be made mandatory. Individual development teams might decide to use additional tagsfor automation purposes, such as EnvironmentName, OptIn, or OptOut.

Key stakeholders need to agree on the tagging strategy approach, and document the answers forcompliance- and governance-related questions, such as:

• What use cases that need to be addressed?

• Who is responsible for tagging resources (implementation)?

• How are tags enforced and what methods and automation will be used (proactive vs reactive)?

• How are tagging effectiveness and goals measured?

• How often should the tagging strategy reviewed?

• Who drives improvements? How are they done?

Business functions, such as Cloud Enablement, Cloud Business Office, and Cloud Platform Engineering,can then play a role of facilitators for the process of building tagging strategy, help drive its adoption,

6

Tagging Best Practices AWS WhitepaperDefining and publishing a tagging schema

and ensure consistency of its application by measuring progress, removing roadblocks, and reducingduplicated effort.

Defining and publishing a tagging schemaEmploy a consistent approach in tagging your AWS resources, both for mandatory and optional tags. Acomprehensive tagging schema helps you achieve this consistency. The following examples can help getyou started:

• Agree on the mandatory tag keys

• Define acceptable values and tag naming conventions (upper or lower case, dashes or underscores,hierarchy, and so on)

• Decide who can define and create new tag keys

• Agree on how to add new mandatory tag values and how to manage optional tags

Review the following tagging categories table, which can be used as a baseline.

7

Tagging Best Practices AWS WhitepaperDefining and publishing a tagging schema

Tabl

e 5:

Exa

mpl

e of

a d

efini

tive

tag

ging

sch

ema

Use

Cas

eTa

g K

eyR

atio

nale

All

owed

Val

ues

(Lis

ted

or v

alue

prefi

x/su

ffix)

Enab

lefo

r Co

stA

lloc

atio

n

Reso

urce

Type

sSc

ope

Requ

ired

Cost

Allo

cati

onexample-inc:

cost-allocation:

ApplicationId

Trac

k co

st v

s va

lue

gene

rate

d by

eac

hlin

e of

bus

ines

s

DataLakeX

,RetailSiteX

YA

llA

llM

anda

tory

Cost

Allo

cati

onexample-inc:

cost-allocation:

BusinessUnitId

Mon

itor

cos

ts b

ybu

sine

ss u

nit

Architecture

,DevOps

, Finance

YA

llA

llM

anda

tory

Cost

Allo

cati

onexample-inc:

cost-allocation:

CostCenter

Mon

itor

cos

ts b

y co

stce

nter

123-*

YA

llA

llM

anda

tory

Acc

ess

Cont

rol

example-

inc:access-

control:LayerId

Iden

tify

subc

ompo

nent

 or

laye

r to

gra

nt a

cces

sto

reso

urce

s ba

sed

on t

he ro

le

DB_Layer

,Web_Layer

,App_Layer

NA

llA

llM

anda

tory

Aut

omat

ion

example-inc:

automation:

EnvironmentId

Impl

emen

tsc

hedu

ling

of t

est

and

deve

lopm

ent

envi

ronm

ents

Prod

, Dev

, Test

,Sandbox

NEC

2, R

DS,

EBS

All

Opt

iona

l

Back

up a

ndRe

cove

ryexample-

inc:business-

continuity:rpo

Defi

ne t

he re

cove

rypo

int

obje

ctiv

e (R

PO)

for

a re

sour

ce

6h

, 24h

NS3

, EBS

Prod

Man

dato

ry

Dat

aCl

assi

ficat

ion

example-

inc:data:

classification

Clas

sify

dat

a fo

rco

mpl

ianc

e an

dgo

vern

ance

Public

, Private

,Confidential

,Restricted

NS3

, EBS

All

Man

dato

ry

8

Tagging Best Practices AWS WhitepaperAWS Organizations – Tag policies

After the tagging schema is defined, manage the schema in a version-controlled repository that is madeaccessible to all the relevant stakeholders for easy reference and trackable updates. This approachimproves efficiency and allows for agility.

AWS Organizations – Tag policiesPolicies in AWS Organizations enable you to apply additional types of governance to AWS accounts inyour organization. A tag policy is how you can express your tagging schema in JSON form so that theplatform can report and optionally enforce the schema within your AWS environment. The tag policydefines which tag keys are required to be present on specific resource types and can define the valuesthat are acceptable for each tag key. This policy can be in the form of a list of values, or a prefix followedby a wildcard character (*). The simple prefix approach is less rigorous than a discrete list of values butrequires less maintenance. 

The following examples show how to define a tagging policy to validate the values that are acceptablefor a given key. Working from the human-friendly tabular definition of the schema, you can transcribethis information into one or more tag policies. Separate policies can be used to support delegatedownership or some policies might only apply in specific scenarios. 

ExampleInc-CostAllocation.json

The following is an example of a tag policy that reports and enforces Cost Allocation tags.

{ "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } }}

9

Tagging Best Practices AWS WhitepaperAWS Organizations – Tag policies

ExampleInc-BusinessContinuity.json

The following is an example of a tag policy that reports and enforces Business Continuity tags.

{ "tags": { "example-inc:business-continuity:rpo": { "tag_key": { "@@assign": "example-inc:business-continuity:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } }}

In this example, the ExampleInc-CostAllocation tag policy is attached to the Workloads OU, andtherefore applies to all of the accounts in both the Prod and Test sub OUs. Similarly, the ExampleInc-BusinessContinuity tag policy is attached to the Prod OU and therefore only applies to accountsbelow this OU. The Organizing You Environment Using Multiple Accounts whitepaper explores therecommended OU structures in more detail.

Attachment of tag policies to an OU structure

10

Tagging Best Practices AWS WhitepaperImplementing and enforcing tagging

Looking at the marketing-prod account in the diagram, both tag policies apply to this account,so we have the concept of an effective policy, which is the aggregate the policies of a giventype that apply to an account. If you primarily manage your resources manually, then you canreview the effective policy by visiting the Resource Groups & Tag Editor:Tag policies in theconsole. If you use infrastructure as code (IaC) or scripting to manage your resources, you can usethe AWS::Organizations::DescribeEffectivePolicy API endpoint, using the AWS CLI or theSDKs and programming toolkits.

Implementing and enforcing taggingDepending on the method that you use to manage the resources within a workload, some approacheswill be more suitable than others. In this section, we’ll introduce you to the tools available for thefollowing resource management strategies: manual, infrastructure as code (IaC), and continuousintegration/continuous delivery (CI/CD). The key dimension for these approaches is an increasinglyfrequent rate of deployment. 

Manually managed resourcesThese are typically workloads that fall into the foundation or migration stages of the cloud adoptionframework (CAF). Often, these are simple largely static workloads that have been built using traditionalwritten procedures or those migrated "as is" using tools such as CloudEndure from an on-premisesenvironment. Migration tools, such as Migration Hub and CloudEndure, can apply tags as part of themigration process. However, if tags were not applied during the original migration or the tagging schemahas changed since then, the Tag Editor (a feature of the AWS Management Console) allows you to searchfor resources using a variety of search criteria and add, modify, or delete tags in bulk. Search criteria caninclude resources with or without the presence of a particular tag or value. The AWS Resource TaggingAPI allows you to perform these functions programmatically.

As these largely static workloads are modernized, resource types such as Auto Scaling groups areintroduced. These resource types allow for greater elasticity and improved resilience. The auto scalinggroup manages EC2 instances on your behalf, however, you might still want them to be taggedconsistently with the manually created resources. An EC2 launch template provides the means to specifythe tags that the Auto Scaling should apply to instances that it creates.

When the resources of a workload are being managed manually, it can be helpful to automate thetagging of resources. There are various solutions available. Automatically tag new AWS resources basedon identity or role describes one approach that detects resource creation events using CloudWatch andstarts an AWS Lambda function to retrieve the tags from an AWS Systems Manager Parameter Store,and then applies the tags to the resource. Another approach is to use AWS Config Rules, which can checkfor required_tags and then start a Lambda function to apply them. AWS Config Rules is described inmore detail later in this whitepaper. 

Infrastructure as Code (IaC) managed resourcesAWS CloudFormation provides a common language for provisioning all the infrastructure resources inyour AWS environment. CloudFormation templates are JSON or YAML files that create AWS resourcesin an automated manner. When you create AWS resources using CloudFormation templates, you canuse the CloudFormation Resource Tags property to apply tags to certain resource types upon creation.Managing the tags as well as the resources with IaC helps ensure consistency. 

CloudFormation provides the capability to detect when a resource provisioned from a template hasbeen modified and is therefore no longer consistent with the template—this is known as drift. If youuse automation to apply tags to resources managed via IaC, then you are modifying them, that is,introducing drift. So how do you differentiate between drift due to tag automation and other changes?

11

Tagging Best Practices AWS WhitepaperAWS Service Catalog and external ITSM resources

You can’t without considerable effort. When using IaC, it's currently recommended to manage anytagging requirements as part of the IaC templates.

When resources are created by AWS CloudFormation, the service automatically applies a set of AWSdefined tags to the resources created by the CloudFormation template. These are:

aws:cloudformation:stack-nameaws:cloudformation:stack-idaws:cloudformation:logical-id

You can easily define a resource group based on the CloudFormation stack. These AWS defined tagsare inherited by the EC2 instances within an Auto Scaling group (and therefore the instance to beincluded in the resource ). However, if you want tags that you define to be applied, you need to setthe AWS::AutoScaling::AutoScalingGroup TagProperty in the definition of the Auto Scalinggroup scaling group in your CloudFormation template. Alternatively, if you are using an EC2 LaunchTemplate with the Auto Scaling group then you can define the tags in its definition. Using EC2 LaunchTemplates with Auto Scaling groups or with an AWS container service is recommended. These servicescan help ensure consistent tagging of your EC2 instances and also support Auto Scaling Across MultipleInstance Types & Purchase Options, which can improve resilience and optimize your compute costs.

AWS Elastic Beanstalk also applies tags to all the resources it creates. It does this by using AWSCloudFormation, which applies its tags as outlined previously. Elastic Beanstalk also adds the followingAWS defined tags, although they don’t have the aws: prefix: 

elasticbeanstalk:environment-idelasticbeanstalk:environment-name

AWS Service Catalog and external ITSM resourcesMany organizations already have an established Configuration Management Database (CMDB), whichoften is acquired as part of broader IT Service Management (ITSM) solutions. ServiceNow and JiraService Desk are two such AWS Partner offerings that have AWS Service Management Connectors. Theseintegrations provide the means to define workflows for the deployment of applications and architecturalpatterns. As part of these workflows, attributes from requestors, approvers, or both can be captured andrecorded as tags on the deployed resources.

AWS Service Catalog allows you to easily manage tags on provisioned products and provides aTagOption library. A TagOption serves as a template for creating AWS tags.

CI/CD pipeline managed resourcesAs the maturity of a workload increases, it’s likely techniques such as continuous integration andcontinuous deployment are adopted. These techniques help to reduce deployment risk by making iteasier to deploy small changes more frequently with increased automation of testing. An observabilitystrategy that detects unexpected behavior introduced by a deployment can automatically roll back thedeployment with minimal user impact. As you get to the stage of deploying more than 10 times a day,applying tags post deployment is simply no longer practical. Everything needs to be expressed as code orconfiguration, version controlled, and, wherever possible, tested and evaluated before deployment intoproduction. In DevOps, there is a move to address operational considerations as code and validate themearly in the deployment lifecycle. This strategy also applies to security (DevSecOps) as is the subject ofBuilding an end-to-end Kubernetes-based DevSecOps software factory on AWS.

AWS CloudFormation Hooks provide developers with a means of keeping key aspects of their applicationconsistent with their organization’s standards. Hooks can be configured to provide a warning or preventdeployment. This feature is best suited to checking key configuration elements in your templates, such aswhether an Auto Scaling group is configured to apply customer defined tags to all the EC2 instances it

12

Tagging Best Practices AWS WhitepaperEnforcement

will launch by specifying  AWS::AutoScaling::AutoScalingGroup TagProperty in the definitionof the Auto Scaling group or using an EC2 Launch Template. Alternatively, it might be used to ensurethat all S3 buckets are created with the required encryption settings. In both cases, evaluation of thiscompliance is being pushed to the left, with AWS CloudFormation hooks, prior to deployment.

Ideally, you want to push these checks as far left in the process as you can, so that you can be confidentthat your CloudFormation template meets your policies, before they leave the developer's machine.You can save time and money by running them through automated testing. AWS CloudFormationGuard 2.0 provides the means to write preventative compliance rules, for anything you can define withCloudFormation. The template is validated against them in the development environment. Clearly, thisfeature has a range of applications but in this whitepaper we will just look at some examples that wouldensure the AWS::AutoScaling::AutoScalingGroup TagProperty is always being used.

The following is an example of a CloudFormation Guard rule.

let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ]

rule tags_asg_automation_EnvironmentId when %all_asgs !empty {    let required_tags = %all_asgs.Properties.Tags.*[        Key == 'example-inc:automation:EnvironmentId' ]    %required_tags[*] {        PropagateAtLaunch == 'true'        Value IN ['Prod', 'Dev', 'Test', 'Sandbox']        <<Tag must have a permitted value          Tag must have PropagateAtLaunch set to 'true'>>    }}

rule tags_asg_costAllocation_CostCenter when %all_asgs !empty {    let required_tags = %all_asgs.Properties.Tags.*[        Key == 'example-inc:cost-allocation:CostCenter' ]    %required_tags[*] {        PropagateAtLaunch == 'true'        Value == /^123-/        <<Tag must have a permitted value          Tag must have PropagateAtLaunch set to 'true'>>    }}

In the code example, we filter the template for all resources that are of the type AutoScalingGroupand then have two rules:

• tags_asg_automation_EnvironmentId: Checks that a tag with this key exists, has a value withinthe allowed list of values, and that PropagateAtLaunch is set to true.

• tags_asg_costAllocation_CostCenter: Checks that a tag exists with this key, has a value thatbegins with the defined prefix value, and that PropagateAtLaunch is set to true.

EnforcementAs described previously, Resource Groups & Tag Editor provides the means to identify where yourresources fail to meet the tagging requirements defined in the tag policies applied to the OUs of theorganization. Accessing the Resource Groups & Tag Editor console tool from within a linked accountshows you the policies that apply to that account and the resource within the account that fail to meetthe tag policy’s requirements. If accessed from the management account (and if Tag policies has Accessenabled in services under AWS Organizations), then it is possible to view the tag policy compliance for allthe linked accounts in the organization.

Within the Tag Policy itself, you can enable enforcement for specific resource types. In the followingpolicy example, we’ve added enforcement such that all resources of types ec2:instance and

13

Tagging Best Practices AWS WhitepaperEnforcement

ec2:volume are required to be compliant with the policy. There are some known limitations, such asthere must be a tag on a resource for it to be evaluated by the tag policy. Also, not all resource types thatsupport tags, are supported by tag policies. 

ExampleInc-Cost-Allocation.json (updated forenforcement)The following is an example of a tag policy that reports and/or enforces Cost Allocation tags.

{ "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } }}

AWS Config (required_tag) AWS Config is a service that enables you to assess, audit, and evaluate theconfigurations of your AWS resources. In the case of tagging, we can use it to identify resources that arelacking tags with specific keys. From the earlier example, we might test for the existence of the key on allEC2 instances. In cases where the key doesn’t exist, the instance will be registered as non-compliant. ThisCloudFormation describes an AWS Config Rule to test for the presence of the mandatory keys describein the table, on S3 buckets, EC2 instances, and EBS volumes. It can be deployed automatically to allaccounts within an organizational unit via a CloudFormation StackSet, or it could be published in AWSService Catalog so developers can optionally deploy the config rules into their AWS account.

14

Tagging Best Practices AWS WhitepaperEnforcement

Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS

For environments where resources are managed manually, an AWS Config rule can be enhanced toautomatically add the missing key to the resources using an automated remediation via a Lambdafunction. While this works well for static workloads, it's progressively less effective as you start tomanage your resources via IaC and deployment pipelines. 

AWS Organizations – Service Control Policies are a type of organization policy that you can use tomanage permissions in your organization. SCPs offer central control over the maximum availablepermissions for all accounts in your organization or organizational unit (OU). They are principally usedto enforce security controls but they support conditions that evaluate the resource properties. In thefollowing example, the policy will deny ec2:RunInstances requests where the example-inc:cost-allocation:CostCenter tag is not present.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ]}

If you are using, or considering using, attribute-based access controls (ABAC) for granular accesspermissions, SCPs can be used to secure resource tags. For details, see Securing resource tags used forauthorization using a service control policy in AWS Organizations.

Unlike tag policies, there is no easy way to review the effective service control policy that applies to alinked account. You must provide a strategy as to how developers can review the policies that have beenapplied to their accounts.

This approach can be effective but also disruptive, forcing engineering teams to prioritize tag complianceover other activities and priorities. The error messages resulting from a deny in an SCP are limited

15

Tagging Best Practices AWS WhitepaperMeasuring tagging effectiveness and driving improvements

in detail—they provide you with the unique ID to look up the event in AWS CloudTrail. It's importantthat developers have read-only access to CloudTrail in their account. Alternatively, IAM users withDecodeAuthorizationMessage policy attached to their permissions can invoke the decode-authorization-message API via AWS CLI to decode the error message returned by SCP.

aws sts decode-authorization-message -—encoded-message "<<Error Message from SCP goes here>>"

Measuring tagging effectiveness and drivingimprovements

After you have implemented a tagging strategy, it's important to measure its effectiveness against thetarget use cases. The measure of effectiveness will vary by use case. For example:

• For cost attribution, coverage can be measured based on spend in Cost Explorer or Cost and UsageReports (CUR)

• For automation use cases, you might have to audit if the desired result has been achieved, for example,to suspend non-production EC2 instances outside of business hours, audit instance start and stoptimes.

Resource Groups & Tag Editor within the management account, provides additional capabilities toanalyze tag policy compliance for all the linked accounts in your organization.

Based of these measurements, identify if there are improvements or alternations needed in any of thesteps like use case definition, tagging schema or implementation and enforcement. Make necessarychanges and repeat the cycle until desired effectiveness is achieved.

Since it’s the developers and operators that actually need to perform the tagging of resources, it's criticalto have them take ownership. This isn’t the only additional responsibility that teams typically assumein their journey of AWS adoption. Increased responsibility for the security and cost of developing andoperating their application are also important. Organizations often use goals and targets as a meansof motivating the adoption of new practices and this can apply equally here. Since no two workloadsare going to have the same cost optimization opportunities, rather than direct comparison, it's moreeffective to look at percentage improvement. Over time, it becomes possible to determine a cost pertransaction, at this point, each release can be considered based on its impact on the transaction cost, andif it starts to grow, then cost optimization becomes the focus of the next sprint.

16

Tagging Best Practices AWS WhitepaperCost allocation and financial management

Tagging use casesTopics

• Tags for cost allocation and financial management (p. 17)• Tags for cloud operations and automation (p. 22)• Tags for data security, risk management, and access control (p. 26)• Tags for data lake strategy (p. 28)

Tags for cost allocation and financial managementAWS Cloud Financial ManagementOne of the first tagging use cases organizations often tackle is visibility and management of cost andusage. There are usually a few reasons for this:

• It's typically a well understood scenario and requirements are well known. For example, financeteams want to see the total cost of workloads and infrastructure that span across multiple services,features, accounts, or teams. One way to achieve this cost visibility is through consistent tagging ofresources.

• Tags and their values are clearly defined. Usually, cost allocation mechanisms already exist inan organization’s finance systems, for example, tracking by cost center, business unit, team, ororganization function.

• Rapid, demonstrable return on investment. It’s possible to track cost optimization trends over timewhen resources are tagged consistently, for example, for resources that were rightsized, auto-scaled, orput on a schedule.

Understanding how you incur costs in AWS enables informed financial decision making. Knowingwhere you have incurred costs at the resource, workload, team, or organization level enables yourunderstanding of the value delivered at the applicable level when compared to the business outcomesachieved.

The engineering teams might not have experience with financial management of their resources.Attaching a person with a specialized skill in AWS financial management who can train engineering anddevelopment teams on the basics of AWS financial management, and create a relationship betweenfinance and engineering to foster the culture of FinOps will help achieve measurable outcomes for thebusiness, and encourage teams to build with cost in mind. Establishing good financial practices is coveredin depth by the Cost Optimization Pillar of the Well-Architected Framework, but we will touch on a fewof the fundamental principles in this whitepaper.

Topics• Cost allocation tags (p. 17)• Building a cost allocation strategy (p. 18)• Operational considerations and reporting (p. 21)

Cost allocation tagsCost allocation refers to the assignment or distribution of incurred costs to the users or beneficiaries ofthose costs following a defined process. In the context of this document we divide cost allocation intotwo types: showback and chargeback.

17

Tagging Best Practices AWS WhitepaperBuilding a cost allocation strategy

Showback tools and mechanisms help enable cost awareness. Chargeback helps with cost recovery anddrives enablement of cost awareness. Showback is about presentation, calculation, and reporting ofcharges incurred by a specific entity, such as business unit, application, user, or cost center. For example:the infrastructure engineering team was responsible for $X of AWS spend last month, while a chargebackis about an actual charging of incurred costs to those entities via an organization’s internal accountingprocesses, such as financial systems or journal vouchers. For example: $X was deducted from theinfrastructure engineering team's AWS budget. In both cases, tagging resources appropriately can helpallocate the cost to an entity, the only difference being whether or not someone is expected to make apayment.

Your organization's financial governance might require transparent accounting of costs incurred at theapplication, business unit, cost center, and team level. Performing cost attribution supported by CostAllocation Tags provides you the data necessary to accurately attribute the costs incurred by an entityfrom appropriately tagged resources.

• Accountability — Ensure that cost is allocated to those who are responsible for resource usage. Asingle point of service / group can be accountable for spend reviews and reporting.

• Financial transparency — Show a clear view into cash allocations towards IT by creating effectivedashboards and meaningful cost analysis for leadership.

• Informed IT investments — Track ROI based on project, application, or business line, and empowerteams to make better business decisions, for example, allocate more funding to revenue generatingapplications.

In summary, cost allocation tags can help to tell you:

• Who owns the spend and is responsible for optimizing it?

• What workload, application, or product is incurring the spend? Which environment or stage?

• What spend areas are growing fastest?

• How much spend can be deducted from a cloud budget based on past trends?

• What was the impact of cost optimization efforts within particular workloads, applications, orproducts?

Activating resource tags for cost allocation enables the definition of measurement practices within theorganization that can be used to provide the visibility of cloud usage that enables transparency intoaccountability for spend. It also focuses on creating an appropriate level of granularity with respect tocost and usage visibility and influencing cloud consumption behaviors through cost allocation reportingand KPI tracking.

Building a cost allocation strategyDefining and implementing a cost allocation model.

Create account and cost structure for the resources being deployed in AWS. Establish the relationshipbetween costs from AWS spend, how those costs were incurred, and who or what incurred those costs.Common cost structures are based on AWS Organizations, AWS accounts, environments, and entitieswithin your organizations, such as a line of business or workload. Cost structures can be based onmultiple attributes to enable examination of costs in different ways or at different levels of granularitysuch as rolling up the costs of individual workloads to the line of business they serve.

When choosing a cost structure that aligns with the desired outcomes, evaluate the cost allocationmechanisms on the ease of implementation versus desired accuracy. This might include considerations inregards to user accountability, tooling availability and cultural changes. Three popular models that AWScustomers usually start from are:

18

Tagging Best Practices AWS WhitepaperBuilding a cost allocation strategy

• Account-based — This model requires the least amount of effort and provides high accuracy forshowbacks and chargebacks, and is suitable for organizations that have a defined account structure(typically using AWS Organizations). This provides clear cost visibility on a per-account basis. For costvisibility and allocation, one can use AWS Cost Explorer,  Cost and Usage Reports, as well as AWSBudgets for cost monitoring and tracking, as these tools provide filtering and grouping options byAWS accounts.

• Business Unit or Team-based — Cost allocatable to teams, business units, or organizations within anenterprise. This model requires a moderate amount of effort, provides high accuracy for showbacksand chargebacks, and is suitable for organizations that have a defined account structure (typicallyusing AWS Organizations) with separation between various teams, applications, and workload types.This provides clear cost visibility across teams and applications, and as additional benefit reducesthe risk of hitting AWS service quotas within a single AWS account. For example, each team mayhave 5 accounts (prod, staging, test, dev, sandbox), and no two teams and applications will sharethe same account. With such structure AWS Cost Categories will then provide the functionality togroup accounts and/or other tags (“meta-tagging”) into categories, which can be tracked in the toolsmentioned in the previous example. It’s important to note that AWS Organizations allows tagging ofaccounts and organizational units (OUs), however these tags will not be applicable for cost allocationand billing reporting (that is, you cannot group or filter your cost in AWS Cost Explorer by OU); AWSCost Categories should be used for this purpose.

• Tag-based — This model requires more effort compared to the previous two and will provide highaccuracy for showbacks and chargebacks depending on the requirements and end goal. It is suitablefor organizations with mixed and complex account structures, typically using AWS Organizations,where the same accounts and services within an AWS account might be shared between teams,applications, or both. Implementing a rigorous and effective tagging strategy is the key in thisscenario, followed by activating relevant tags for cost allocation in the Billing and Cost Managementconsole (in AWS Organizations, tags can be activated for cost allocation only from the ManagementPayer account). After tags are activated for cost allocation, then tools for cost visibility and allocationthat were mentioned in the previous methods can be used for showbacks and chargebacks. Note thatcost allocation tags are not retrospective, and will only appear in billing reporting and cost trackingtools after they were activated for cost allocation.

19

Tagging Best Practices AWS WhitepaperBuilding a cost allocation strategy

Sample account structure for a digital native business that was born on AWS and operates in a multi-account cost structure

In this example, if you need to track costs by Business Unit, you can use AWS Cost Categories to grouplinked accounts accordingly and view this grouping in billing reports. If you create separate accountsfor production and non-production environments, you can filter the costs related to environments intools such as AWS Cost Explorer, or track those costs using AWS Budgets. Finally, if your use case requiresmore granular cost tracking, for example, by individual workloads or applications, you can tag resourceswithin those accounts accordingly, activate those tag keys for cost allocation on the managementaccount, and then view cost by the relevant filters in the billing reporting tools.

Establishing cost reporting and monitoring processes.

Start with identifying the types of costs that are important for internal stakeholders (for example,daily spend, cost by account, cost by X, amortized costs). By doing so, you can mitigate budgetary risksassociated with unexpected or anomalous spend faster than waiting for the finalized AWS invoice. Tagsprovide the attribution that enables these reporting scenarios. Insights gained from reporting can enableaction to mitigate the impact from anomalous and unexpected spend on financial budgets. When thereis an unexpected surge in costs, it's important to evaluate if there has been an unexpected surge in thevalue delivered so that you can determine if and what action is required. 

When working on a strategy, keep in mind the following building blocks:

20

Tagging Best Practices AWS WhitepaperOperational considerations and reporting

• AWS Organizations. Cost allocation within multiple accounts can be performed by account, groupsof accounts, or group of tags created for resources on those accounts. Tags created for resourcesresiding in individual accounts in AWS Organizations can be enabled for cost allocation only from theManagement Payer account.

• AWS Account. Cost allocation within one AWS account can be performed by services and otherdimensions. It’s possible to further tag resources within an account and work with the groups of suchresource tags.

• Cost Allocation Tags. Both user-created tags and AWS generated tags can be activated for costallocation, if necessary. Enabling tags for cost allocation in the billing console (of the ManagementPayer account in AWS Organizations) helps with showbacks and chargebacks. The minimum bestpractices are that one should not overload tags, agree on a simple schema, be consistent with taggingacross accounts, and tag everything that can be tagged.

• Cost Categories. AWS Cost Categories allow grouping accounts and grouping tags (“meta-tagging”)across AWS Organizations, which further provides capability to analyze the cost related to thesecategories through tools such as AWS Cost Explorer, AWS Budgets and AWS Cost and Usage Report.

Performing showback and chargeback for business units, teams, or organizations within theenterprise.

Attribute costs using your cost allocation process supported by your cost structure and cost allocationtags. Provide showback to the teams and organizations that are not directly responsible to payfor costs but are responsible for having incurred those costs. This approach provides awareness oftheir contribution to spend and how those costs are incurred. Perform chargeback to the teams andorganizations that are directly responsible for costs to recover the expense of the resources they haveconsumed, and to enable their awareness of those costs and how they were incurred.

Measuring and circulating efficiency or value KPIs. Agree on a set of unit cost or KPI metrics tomeasure the impact of your cloud financial management investments. This exercise creates a commonlanguage across technology and business stakeholders, and tells an efficiency-based story, rather than astory focused solely on absolute, aggregate spend.

Operational considerations and reportingThere are several operational considerations that should be included in the overall cost allocationstrategy.

Allocating unallocatable spend. Depending on the organization’s accounting practices, different chargetypes might require different treatment. Identify the resources or cost categories that cannot be tagged.Depending on the services used and those planned to be used, agree on the mechanisms on how to treatand measure such unallocatable spend. For example, check the list of resources that are supported byAWS Resource Groups and Tag Editor in the AWS Resource Groups and Tags User Guide.

A common example of cost category that cannot be tagged is some fees for commitment-baseddiscounts such as Reserved Instances (RI) and Savings Plans (SP). While upfront, monthly subscription,and unused SP and RI fees cannot be tagged in advance of appearing in billing reporting tools, it'spossible to track the RI and SP discount application to accounts in AWS Organizations, resources, andtheir tags post-factum. For example, in AWS Cost Explorer it’s possible to look at the amortized costview, group that spend by the relevant tags and use filters applicable to your use case. In AWS Costand Usage Report (CUR), it’s possible to filter out lines that correspond to usage covered by RI and SPdiscounts and select only the columns that are relevant to your use case (for example, resource IDs,amortized cost, tag keys) where each tag key activated for cost allocation will be presented in its ownseparate column. Check the AWS Well-Architected Labs for examples of gaining cost and usage insightsfrom CUR data.

Build vs buy. In addition to the AWS tools available to assist with showbacks and chargebacks, thereis also a range of other AWS created and third-party solutions that can help with the cost allocation

21

Tagging Best Practices AWS WhitepaperCloud operations and automation

exercise. It depends on both the requirements and the end objective of the organization, so that onecould either invest time and resources into building customized solutions or purchase tools provided byone of the AWS Cloud Management Tools Competency Partners. If you decide to create your own singlesource of truth cost allocation tool with controlled parameters relevant for the business, AWS Cost andUsage Report (CUR) provides most detailed cost and usage data and enables creation of customizedoptimization dashboards, allowing filtering and grouping by accounts, services, cost categories, costallocation tags and multiple other dimensions, as well as automating cost allocation. Among CUR-based solutions developed by AWS that can be used as an example of such tools, check Cloud IntelligentDashboards on AWS Well-Architected Labs site.

Tags for cloud operations and automationTags for business continuityAWS Backup provides a unified backup experience across several AWS services, such as Amazon EC2,Amazon RDS, Amazon EFS, DynamoDB, and Amazon S3. Tag-based backup policy is a core tenet of thisservice. Tagging makes it easier to implement your backup strategy across all your applications and helpvalidate that all your AWS resources are backed up and protected. Varying degrees of recovery timeobjective (RTO) and recovery point objective (RPO) requirements can be configured with multiple backupplans paired with specific resource tags.

Within AWS Backup, you start by creating a backup plan, which gives you the ability to define backupfrequency and backup window. These should be configured to match the RTO and RPO requirements,and to support your organization's business needs.

After your backup plan is defined resource assignment can be simplified using resource tags. Forexample, an EC2 instance defined with a tag key example-inc:business-continuity:rpo andvalue 12h can be associated with a backup plan that has a 12-hour backup frequency, versus an instancewith the key example-inc:business-continuity:rpo and value 7d be associated with a backupplan that has a weekly backup frequency. Disaster recovery (DR) strategy plays a key role in businesscontinuity. When disaster occurs, the business needs to know about impact—in terms of nature, scope,and severity. This impact drives the running of the DR playbook that lists out key applications andresources and prioritizes applications for recovery, based on dependencies and accepted RTO. To helprun the DR playbook, tags can play an important part with resource grouping and classification. Theautomated recovery of resources relies on tags to identify the backup plans and policies that they wereused.

DR can be based on several approaches, such as Backup and Restore, Pilot Light, Warm Standby, andActive-Active. More details on these various approaches can be found in the AWS Well-ArchitectedReliability Pillar whitepaper. Depending on the business RPO and RTO requirements along with cost andoperational implications, your organization might decide on one or several DR approaches.

Tags for operational observabilityObservability is required to gain actionable insights into the performance of your environments andenable you to detect and investigate problems. It also has a secondary purpose that enables you todefine and measure key performance indicators (KPIs) and service level objectives (SLOs) such as uptime.For most organizations, important operations KPIs are mean time to detect (MTTD) and mean time torecover (MTTR) from an incident.

Throughout observability, context is the key, as data is collected and then associated tags are gathered.Regardless of the service, application, or application tier that you are focusing on, you can filter andanalyze for that specific dataset.

Tags can be used to automate on-boarding to CloudWatch alarms so that the right teams can be alertedwhen certain metric thresholds are breached. For example, a tag key example-inc:ops:alarm-tag

22

Tagging Best Practices AWS WhitepaperTags for identifying application resource collections

and the value on could indicate creation of the CloudWatch Alarm. A solution demonstrating this isdescribed in Use tags to create and maintain Amazon CloudWatch alarms for Amazon EC2 instances

Having too many alarms configured can easily create an alert storm—this is when a large number ofalarms or notifications rapidly overwhelm operators and reduce the overall effectiveness, while operatorsare manually triaging and prioritizing them individually. Additional context for the alarms can beprovided in the form of tags, which means that rules can be defined within EventBridge to help ensurethat focus is given to the upstream issue rather than downstream dependencies. 

The role of operations alongside DevOps is often overlooked, but for many organizations, centraloperations teams still provide a critical first response outside of normal business hours. Unlike theDevOps team that owns the workload, they typically do not have the same depth of knowledge, so thecontext that tags provide within dashboards and alerts, can direct them to the correct runbook for theissue, or initiate an automated runbook (refer to the blog post Automating Amazon CloudWatch Alarmswith AWS SageMaker).

AWS strives for high availability and has a 99.9% uptime for most services. However, in the rare eventthat an incident does occur, you should be prepared to respond. AWS Health is the primary channel tocommunicate service degradation, scheduled changes, and resource impacting issues. AWS Health Awareis an incident management and communication framework to ingest proactive and real-time alerts fromAWS Health to your preferred communication channels. Alerts can be configured to endpoints such asinstant messaging services (including Amazon Chime and Slack), and email alerts. Find out more in theblog article AWS Health Aware – Customize AWS Health Alerts for Organizational and Personal AWSAccounts.

Tags for identifying application resource collectionsIt's essential for businesses to understand the resource collection related to each of their business unitsor products so that there is an operational or financial accountability. This could be a scenario wherea business owner is looking for a full set of resources across all environments or building correlationacross multiple resources for internal tooling or installation of third-party software. For a DevOps or ITOperations team member, they might need to understand the application context of a resource, such asthe environment, Recovery Time Objective, and applicable operational runbooks.  

The AWS Service Catalog AppRegistry is one such feature that provides a central place to associate yourapplication’s resource collections and attribute groups. After your AppRegistry application is created, youcan assign metadata to your application using tags. All resources assigned to an AppRegistry applicationwill automatically get three system tags, applicationID, name, and ARN. Both system tags and usertags can help you manage, identify, search for, and manage your applications. 

To add tags for an AppRegistry application, see Adding tags in the AWS Service Catalog AdministratorGuide.

Tags for incident and event managementTags can play a vital part in all phases of incident management starting from incident logging,prioritization, investigation, communication, resolution to closure.

Incident Management

Tags can detail where an incident should be logged, the team or teams who should be informed of theincident, and the defined escalation priority. These tags don’t need to be exclusive. For instance, thecost center tag could be reused as an incident logging application code construct. Make it clear in youroperational definitions that this tag reuse is being done.

Table 6: Example incident management tags

23

Tagging Best Practices AWS WhitepaperTags for incident and event management

Use Case Tag Key Rationale Example Values

Incident Management example-inc:incident-management:escalation-log

The system in use bythe supporting team tolog incidents

jira, servicenow,zendesk

Incident Management example-inc:business-continuity:recovery-priority

Priority of applicationrecovery if a majorincident is affectingmultiple applications

1, 2, 3, 4

Incident Management example-inc:incident-management:escalation-path

Path of escalation ops-center, dev-ops,app-team

Cost Allocation andIncident Management

example-inc:cost-allocation:CostCenter

Monitor costs bycost center. This is anexample of a dual usetag where the costcenter is being used asan application code forincident logging

123-*

Prioritization metadata

Operational requirement tags can be detailed as well, to help incident managers and operationspersonnel further refine their objectives in response to an incident or event.

Table 7: Example operational requirement tags

Use Case Tag Key Rationale Example Values

Business Continuity example-inc:business-continuity:recovery-priority

Priority of applicationrecovery in the case of amajor incident affectingmultiple applications

0, 1, 2, 3, 4

Business Continuity example-inc:business-continuity:rpo

Application RPO <20mins

Business Continuity example-inc:business-continuity:rto

Application RTO <4hrs

Automation and defined procedure

Management of incidents and events is critical, and tag metadata can help in coordinating anorganization’s response. Automation of defined procedures in the event of an incident can be extremelyeffective in helping operational personnel to react to the issue as quickly and accurately as possible. Thetags can quickly direct personnel to defined operational playbooks.

Table 8: Example automation procedure tags

24

Tagging Best Practices AWS WhitepaperTags for patching

Use Case Tag Key Rationale Example Values

Incident Management example-inc:incident-management:playbook

Documented playbook  https://example.com/documentbase/webapp/incident/playbook

Business Continuity example-inc:business-continuity:playbook

Documented playbook  https://example.com/documentbase/webapp/bcm/playbook

Tags for patchingOrganizations are able to automate their patching strategy and keep mutable instances in-line with thedefined patch baseline of that application environment by using AWS Systems Manager Patch Managerand AWS Lambda. A tagging strategy for mutable instances within these environments can be managedby assigning said instances to Patch Groups and Maintenance Windows. See the following examples fora Dev → Test → Prod split. AWS prescriptive guidance is available for the patch management of mutableinstances.

Development

The following is output of tags applied on resources.

{    "Tags": [        {            "Key": "Maintenance Window",            "ResourceId": "i-012345678ab9ab111",            "ResourceType": "instance",            "Value": "cron(30 23 ? * TUE#1 *)"        },        {            "Key": "Name",            "ResourceId": "i-012345678ab9ab222",            "ResourceType": "instance",            "Value": "WEBAPP"        },        {            "Key": "Patch Group",            "ResourceId": "i-012345678ab9ab333",            "ResourceType": "instance",            "Value": "WEBAPP-DEV-AL2"        }    ]}

Test

The following is output of tags applied on resources.

{    "Tags": [        {            "Key": "Maintenance Window",

25

Tagging Best Practices AWS WhitepaperData security, risk management, and access control

            "ResourceId": "i-012345678ab9ab444",            "ResourceType": "instance",            "Value": "cron(30 23 ? * TUE#2 *)"        },        {            "Key": "Name",            "ResourceId": "i-012345678ab9ab555",            "ResourceType": "instance",            "Value": "WEBAPP"        },        {            "Key": "Patch Group",            "ResourceId": "i-012345678ab9ab666",            "ResourceType": "instance",            "Value": "WEBAPP-TEST-AL2"        }    ]}

Production

The following is output of tags applied on resources.

{    "Tags": [        {            "Key": "Maintenance Window",            "ResourceId": "i-012345678ab9ab777",            "ResourceType": "instance",            "Value": "cron(30 23 ? * TUE#3 *)"        },        {            "Key": "Name",            "ResourceId": "i-012345678ab9ab888",            "ResourceType": "instance",            "Value": "WEBAPP"        },        {            "Key": "Patch Group",            "ResourceId": "i-012345678ab9ab999",            "ResourceType": "instance",            "Value": "WEBAPP-PROD-AL2"        }    ]}

For strategies around enforcement and monitoring of tagging for patching, see Implementing andenforcing tagging (p. 11).

Tags for data security, risk management, andaccess control

Access controlAWS Identity and Access Management (IAM) and AWS Single Sign-On (AWS SSO) policies support tag-based conditions, enabling customers to constrain permissions based on specific tag key-value pairs, forexample, IAM user or role permissions can include conditions to limit access to specific environments(such as development, test, or production) or Amazon Virtual Private Cloud (Amazon VPC) networks

26

Tagging Best Practices AWS WhitepaperData security and risk management

based on their tags. This allows for simpler and scalable access control solutions where the resourcecreator defines who has access to the resource and what actions are allowed. More details can be foundin:

• Controlling access to AWS resources using tags in the IAM User Guide• Attribute-based access control in the AWS Single Sign-On User Guide• Attribute-Based Access Control with AWS Single Sign-On blog post

Data security and risk managementTags can be used to identify and filter resources that require additional monitoring for data securityaspects. Many organizations run workloads that contain sensitive data subject to regulations, such asHIPAA. In such cases where the security of the deployment is of paramount importance, organizationscan use tags to identify resources that require additional monitoring, for example, Amazon EC2 instanceshosting applications that process sensitive or confidential data. This tagging can enable automatedcompliance checks to validate that proper access controls are in place, patch compliance is up to date,and so on.

Many organizations use AWS to run workflows containing confidential and highly sensitive informationthat needs to be protected at all times. To manage the risk without compromising security, it's essentialthat preventive controls are placed on the AWS infrastructure. Tagging sensitive resources provides userswith the necessary visibility that they require to enforce preventive controls for identifying security risksof your infrastructure deployments on AWS. For example, Amazon EC2 instances hosting applicationsthat process sensitive or confidential data can be tagged appropriately. This can be then used forautomated compliance checks to achieve that proper access controls are in place, patches are up to date,and so on.

Tags for data classification and regulatory dataretentionOrganizations have varying needs and obligations to meet regarding the appropriate handling of datastorage and processing. Data classification is an important precursor for several use cases, such as accesscontrol, data retention, data analysis, and compliance.

Tagging is an effective way to manage data classification. For example, S3 buckets that hold sensitivedata can be tagged with the  AWS Config rule s3-bucket-public-read-prohibited that checksthat your Amazon S3 buckets do not allow public read access. The rule checks the Block Public Accesssettings, the bucket policy, and the bucket access control list (ACL). 

You can enable this rule for the resources with a specific tag, such as example-inc:data:classification with the value of Private, Confidential, or Restricted whileexcluding the value of Public.  Based on this rule, you can initiate notification and take corrective actionfor buckets to restrict public access. S3 objects can also be tagged for categorization. See the examplesin the Amazon S3 User Guide

Another use case of data classification is to detect and alert on the presence of personal identifiableinformation (PII) in S3 buckets that should not have been there to begin with. One solution is UsingAmazon Macie to Validate S3 Bucket Data Classification to cost efficiently discover sensitive data at scale.Amazon Macie uses machine learning (ML) and pattern matching to classify data. When you create ajob to scan buckets, you can do so based on tags specified on the bucket. In this case, you can enablea Macie job to scan for PII data on buckets with the tag example-inc:data:classification andvalue Public. You can find more details on this use case in these blog posts.

Certain regulatory environments, such as insurance and healthcare, might be subject to mandatorydata retention policies. Data retention using tags can be an effective and simple way, combined with

27

Tagging Best Practices AWS WhitepaperData lake strategy

Amazon S3 Lifecycle policies, to scope object transitions to a different storage tier. Also, Amazon S3Lifecycle rules can be used to expire objects for data deletion after the mandatory hold period expires.See Simplify your data lifecycle by using object tags with Amazon S3 Lifecycle for an in-depth guide tothis process.

Tags for data lake strategyAWS Lake Formation is a fully managed service that makes it easier for you to build, secure, and managedata lakes. AWS Lake Formation can use several AWS services, such as AWS Glue, Amazon Athena,Amazon Redshift Spectrum and Amazon QuickSight, to provide a complete service experience.

Tags have several integration points for these services, for example Lake Formation tag-based accesscontrol (LF-TBAC) is an authorization strategy that defines permissions based on attributes. These LF-tags can be attached to Data Catalog resources, Lake Formation principals, and table columns. LakeFormation will allow desired operations on those resources when the principal's tag matches to theresource tag

28

Tagging Best Practices AWS Whitepaper

ConclusionAWS resources can be tagged for a variety of purposes, from implementing a cost allocation strategyto supporting automation or authorizing access to AWS resources. Implementing a tagging strategycan be challenging for some organizations, owing to the number of stakeholder groups involved andconsiderations such as data sourcing and tag governance.

In this whitepaper, we’ve outlined recommendations regarding designing and implementing a taggingstrategy in an organization based on operational practices, defined use cases, stakeholders involved inthe process, and tools and services provided by AWS. When it comes to a tagging strategy, it’s a processof iteration and improvement, where you start small from your immediate priority, identify relevant usecases across your organization, and then implement and grow the tagging schema as you need to, whilecontinuously measuring and improving effectiveness. We’ve pointed out that a well-defined set of tagswithin your organization will allow you to relate AWS usage and consumption to teams responsible forthe resources and business purpose for which they exist, in order to align with organizational strategyand value.

29

Tagging Best Practices AWS Whitepaper

ContributorsContributors to this document include:

• Chris Pates, Sr Specialist Technical Account Manager, Amazon Web Services• Vijay Shekhar Rao, Enterprise Support Lead, Amazon Web Services• Nataliya Godunok, Specialist Technical Account Manager, Amazon Web Services• Yogish Kutkunje Pai, Sr Solutions Architect, Amazon Internet Services Private Limited• Jamie Ibbs, Sr Specialist Technical Account Manager, Amazon Web Services

30

Tagging Best Practices AWS Whitepaper

Further readingFor additional information, see:

• AWS Cloud Security: Shared Responsibility Model• AWS re:Invent 2020: Working backwards: Amazon’s approach to innovation• AWS Prescriptive Guidance: Automated patching for mutable instances in the hybrid cloud using AWS

Systems Manager• AWS Architecture Center

AWS Well-Architected

• AWS Well-Architected Framework• Operational Excellence Pillar - AWS Well-Architected Framework• Plan for Disaster Recovery (DR) - AWS Well-Architected Reliability pillar• Cost Optimization Pillar - AWS Well-Architected Framework• AWS Well-Architected Labs: Enable AWS-Generated Cost Allocation Tags• AWS Well-Architected Labs: Tag Policies• AWS Well-Architected Labs: AWS CUR Query Library

AWS Blogs

• AWS Health Aware – Customize AWS Health Alerts for Organizational and Personal AWS Accounts• Automatically tag new AWS resources based on identity or role• How to Automatically Tag Amazon EC2 Resources in Response to API Events• AWS Generated vs. User-Defined Cost Allocation Tag• Cost Tagging and Reporting with AWS Organizations• Patching your Windows EC2 instances using AWS Systems Manager Patch Manager

AWS Documentation

• Using Cost Allocation Tags - AWS Billing and Cost Management and Cost Management• What are AWS Cost and Usage Reports?• AWS Resource Groups API Reference• How can I use IAM policy tags to restrict how an EC2 instance or EBS volume can be created?• Mutable vs immutable update models.

Other

• Bryar, C. and Carr, B. (2021). Working backwards insights, stories, and secrets from inside Amazon.London Macmillan.

• AWS CloudFormation Guard (GitHub)

31

Tagging Best Practices AWS Whitepaper

Document historyTo be notified about updates to this whitepaper, subscribe to the RSS feed.

update-history-change update-history-description update-history-date

Minor update (p. 32) Fixed table formatting in PDFversion.

April 25, 2022

Major revision (p. 32) Updated document structureand expanded Tagging Strategyand Use Cases sections. Addedmore prescriptive guidancebased on the latest tools,techniques, and availableresources.

April 22, 2022

Initial publication (p. 32) Whitepaper first published. December 1, 2018

NoteTo subscribe to RSS updates, you must have an RSS plugin enabled for the browser that you areusing.

32

Tagging Best Practices AWS Whitepaper

NoticesCustomers are responsible for making their own independent assessment of the information in thisdocument. This document: (a) is for informational purposes only, (b) represents current AWS productofferings and practices, which are subject to change without notice, and (c) does not create anycommitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or servicesare provided “as is” without warranties, representations, or conditions of any kind, whether express orimplied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements,and this document is not part of, nor does it modify, any agreement between AWS and its customers.

© 2022 Amazon Web Services, Inc. or its affiliates. All rights reserved.

33

Tagging Best Practices AWS Whitepaper

AWS glossaryFor the latest AWS terminology, see the AWS glossary in the AWS General Reference.

34