AWS Governance and Tagging cheat sheet · AWS

1.A Tagging Schema That Holds

A tag is a key-value label on an AWS resource. A tagging schema is the small, fixed set of keys every resource must carry, with the exact spelling and the allowed values written down. The schema is what makes tags useful — six keys applied everywhere beat forty keys applied inconsistently, because only the first can be queried.

Key features

Tag keys and tag values are both case sensitive, so `Environment` and `environment` are two different keys and split every report in half
AWS warns not to store personally identifiable information or other confidential data in tags, because tags are used for billing and administration services
Tag policies in AWS Organizations standardise tags across accounts, including the preferred case treatment of keys and values
A tag policy can enforce noncompliant tagging operations on specified resource types, preventing them from completing
Untagged resources, and tags not defined in the tag policy, are not evaluated for compliance — a policy is not a coverage guarantee
IAM adds validation preventing tag keys on IAM resources that differ only in casing, and AWS recommends avoiding such keys generally

Six keys, their allowed values, and what breaks without them

Six keys, their allowed values, and what breaks without them
Key	Allowed values	What is impossible without it
`Application`	A fixed list of product slugs	Answering "what does this resource belong to" during an incident
`Environment`	`prod` · `staging` · `dev`	Any policy or automation that must treat production differently
`Owner`	A team identifier, never a person	Knowing who to ask before deleting something
`CostCenter`	A finance-issued code	Attributing spend to anyone; the bill stays one number
`DataClassification`	`public` · `internal` · `confidential` · `restricted`	Knowing which buckets and databases need the strictest controls
`ManagedBy`	`terraform` · `cdk` · `cloudformation` · `manual`	Telling a deliberate manual resource apart from drift

Six keys, one question each

Each key exists because someone regularly asks the question beside it. A key with no question behind it is the first one to drift out of use.

Signature

Application · Environment · Owner · CostCenter · DataClassification · ManagedBy

Six keys — Application, Environment, Owner, CostCenter, DataClassification, ManagedBy — each answering a real question, with fixed values and one casing. Keys and values are case sensitive, teams own resources rather than individuals, and nothing personal or confidential goes in a tag.

2.What Tags Are Actually Used For

Tags are not documentation. They are an index that five different systems read: the bill, the on-call rotation, automation that acts on resources, access control, and compliance reporting. Each one turns a tag into a decision, which is why a missing tag is a broken feature rather than untidy metadata.

Key features

Cost allocation tags must be activated in the Billing console before they appear in Cost Explorer or a cost allocation report — applying the tag is not enough
There are two kinds: AWS-generated tags with an `aws:` prefix, and user-defined tags with a `user:` prefix, and both are activated separately
All tags can take up to 24 hours to appear in the Billing and Cost Management console
Only the management account of an organization, and standalone accounts, can reach the cost allocation tags manager in the Billing console
IAM policies can allow or deny actions based on tags, which turns a tag into an access-control input rather than a label
The cost allocation report includes both tagged and untagged resources, so untagged spend shows up as an unattributed bucket rather than disappearing

What each consumer does with which key

What each consumer does with which key
Consumer	Reads	The decision it makes
Cost Explorer and CUR	`CostCenter`, `Application`, `Environment`	Which team's budget a line of spend belongs to
Incident response	`Owner`, `Application`	Who to page, and what else is affected
AWS Backup	`Environment`, `DataClassification`	Which resources a backup plan covers, without a manual list
Patch and maintenance automation	`Environment`, `ManagedBy`	What may be patched now, and what needs a window
Fault injection	An explicit opt-in key	Which resources an experiment may touch
IAM policy conditions	`Environment`, `Owner`	Whether this principal may act on this resource
Compliance reporting	`DataClassification`	Which stores are in scope for the strictest controls
Cleanup and rightsizing	`ManagedBy`, `Owner`	Whether an idle resource is abandoned or deliberate

Five systems read your tags

Money

Cost allocation

CostCenter and Application split the bill

Must be activated first

in Billing, then up to 24 hours to appear

Operations and ownership

Who to contact

Owner answers it during an incident

Dashboards and alarms

grouped by Application and Environment

Automation

Backup and patch selection

act on tags, not on hand-kept lists

Chaos and cleanup targets

opt-in by tag, so scope cannot creep

Security and compliance

Tag-based IAM conditions

permissions that follow the resource

Compliance reporting

DataClassification drives the evidence

Signature

cost allocation · incident ownership · automation selection · IAM conditions · compliance scope

Tags are an index read by five systems: the bill, incident response, automation, IAM and compliance. A user-defined tag does nothing for cost reporting until it is activated in the Billing console by the management account, and it can take a day to appear. Tags refine access inside a boundary; the account is the boundary.

3.Naming, Boundaries and Guardrails Come First

Naming conventions, account boundaries and guardrails are all cheap to set up on day one and expensive to retrofit. The reason is not technical difficulty — it is that every one of them has to be applied to resources that already exist, owned by teams who did not agree to it, in an estate nobody has a complete list of.

Key features

Tag policies are available only in an organization with all features enabled, so the organization structure is a prerequisite for the tagging controls
AWS recommends understanding a tag policy's effects on one account before widening it to an OU or the organization, and especially before enforcing it
Enforcement prevents noncompliant tagging requests on specified resource types from completing — which will block real work if turned on too early
AWS Organizations, Resource Groups and the Billing console are three different services in the tagging workflow, usually owned by three different teams
A resource name is fixed at creation for most services, so a naming standard applied later leaves a permanent legacy of exceptions
AWS frames tagging strategy as ownership: assign who defines the use cases and who maintains and improves the strategy, or it stops being maintained

Four decisions, and what each one costs if deferred

Four decisions, and what each one costs if deferred
Decision	On day one	Deferred
Account boundaries	Create separate accounts per environment from the start	Migrating live workloads between accounts, with new ARNs everywhere
Naming standard	A pattern in the project template	Most names cannot be changed, so the legacy is permanent
Tagging schema	Default tags in the IaC provider	Backfilling thousands of resources across teams who did not agree to it
Guardrails (SCPs, tag policies, Config rules)	Applied to an empty organization	Every existing violation must be triaged before the control can be turned on

Rolling out a guardrail without breaking delivery

Rolling out a guardrail without breaking delivery
Stage	What is on	What you learn
1 · Document	Nothing enforced	Whether the rule is even agreed
2 · Default	IaC applies it to new resources	Whether it is workable in practice
3 · Report	Compliance visible per account	The real size of the gap, as a number
4 · Enforce narrowly	One account, one or two resource types	What legitimate work it accidentally blocks
5 · Enforce widely	The OU or the organization	Nothing new — by now it should be uneventful

The cost of introducing a control, over time

The work is the same at every point on this curve. What grows is the number of existing resources, teams and dependencies that the control has to be reconciled with.

Signature

document → default in IaC → report compliance → enforce narrowly → enforce widely

Account boundaries, naming standards, tagging schemas and guardrails all get more expensive with every account and every resource. Introduce them as a line in the sand rather than a cleanup, prioritise the retrospective work by cost and by incident response, and enforce only once the reported gap is already near zero.