Business Challenge
Tag policies are usually reached for after someone runs a cost report and finds a third of the spend unattributable. The definition contains the reason that will not work, in a subordinate clause:
“In a tag policy, you specify tagging rules applicable to resources when they are tagged.”
And then the consequence, stated directly: “Untagged resources or tags that aren't defined in the tag policy aren't evaluated for compliance with the tag policy.”
A tag policy is a schema for tags that exist. The resource with no tags is not non-compliant; it is out of scope.
Enforcement is real and it is useful: “A tag policy can also specify that noncompliant tagging operations on specified resource types are enforced. In other words, noncompliant tagging requests on specified resource types are prevented from completing.”
Read the object of that sentence. What is prevented is a tagging request that does not
match the schema — a CostCenter of Finnance when the policy allows
Finance. AWS extends it to creation for values:
“you can prevent resource creation with tag values that do not meet the requirements
specified in your tag policy.”
But the page then draws its own boundary, in bold, and it is the most useful paragraph in the documentation:
“Basic compliance rules do not enforce tag compliance on resources that are created without tags. This capability does not enforce missing tag keys. You cannot use this capability to ensure that required or mandatory tag keys are configured at resource creation.”
So enforcement constrains the values of tags somebody chose to apply. Create the same resource with no tags at all and nothing stops you.
FixWrite down which problem you have. Our tags are inconsistent is a tag policy. Half our resources have no tags is not, and no amount of tag policy configuration will become one.
The same paragraph does not leave you stranded:
“Use reporting mode in “Required tag keys” to enforce required tag keys for resources created by IaC tools such as CloudFormation, Terraform, and Pulumi. Use SCPs to prevent IAM users and roles in target accounts from creating certain resource types if the request doesn't include the specified tags.”
That is the division of labour, and it is worth stating plainly because estates routinely buy one and expect both. An SCP with a condition on the tag keys in the request is what makes tagging mandatory, because it is evaluated at the API call and refuses it. A tag policy is what makes the applied tags consistent once they are there.
This is the same split as #103 seen from the other side: an authorization policy can refuse the call, and a configuration or schema policy governs the state. Mandatory tagging is a question about a request, so it needs the policy type that evaluates requests.
FixUse both, deliberately. SCPs for the tag keys that must be present at creation; tag policies for the values and the capitalisation those keys must then use. Either alone leaves a gap you can describe in one sentence.
The best-practices list carries a warning that is easy to read as generic and is not:
“Some AWS services have container-like groupings of resources that automatically create resources for you and propagate tags from a resource in one service to another. For example, tags on Amazon EC2 groups and Amazon EMR clusters can automatically propagate to the contained Amazon EC2 instances. You may have tag policies for Amazon EC2 that are more strict than for groups or Amazon EMR clusters. If you enable enforcement, the tag policy prevents resources from being tagged and may block dynamic scaling and provisioning.”
A tag that was compliant on the Auto Scaling group propagates to an instance governed by a stricter rule, the tagging operation is refused, and the scaling event fails. The policy did exactly what it was told. The failure surfaces as a capacity problem at the worst possible moment, and nothing in the incident will mention tags.
Which is why the warning next to it is phrased the way it is: “Test how enforcement works on a test account before expanding it to more accounts or organizational units. Otherwise, you could prevent users in your organization's accounts from creating the resources they need.”
FixBefore enabling enforcement anywhere, list the services in scope that propagate tags — Auto Scaling groups, EMR clusters, anything that creates resources on your behalf — and confirm the propagated tags satisfy the strictest policy that will apply to the child resource, not the parent.
Architecture
What is in scope, and what is simply not
| Situation | Tag policy result |
|---|---|
Resource tagged CostCenter=Finance, policy allows it |
Compliant |
Resource tagged CostCenter=Finnance |
Non-compliant; the tagging request is refused if enforcement is on for that type |
Resource tagged costcenter=Finance, capitalisation enforced |
A different key — “Capitalization treats CostCenter, costCenter, and Costcenter as unique tag keys” |
Resource tagged Owner=jay, not in the policy |
Not evaluated |
| Resource with no tags | Not evaluated |
The last two rows are the same answer for opposite reasons, and both are why a tag policy compliance report is not a tagging coverage report.
Two modes, two different questions
| Reporting | Enforcement | |
|---|---|---|
| What it answers | Which applied tags do not match the schema | Refuse the operation that would create a mismatch |
| Where you read it | AWS Resource Groups — “Use AWS Resource Groups to manage compliance with tag policies” | The failed API call |
| Scope | Evaluated broadly | “You can only enforce compliance with tag policies on supported resource types” |
| Can it require a tag? | No | No |
The bottom row is the post. Neither mode makes a tag mandatory, which is the thing most people install a tag policy to achieve.
What you can attach, and what does not count
The quotas matter once a tagging standard spans OUs, and one of them is easy to get wrong in the other direction. A tag policy document can be “Tag policies: 10,000 characters”, an organization can hold “Tag policies: 1000”, and the attachment limit is ten: ten to the root, ten per OU, ten per account.
The part worth knowing is what that ten counts: “These numbers apply to only those policies that are directly attached to an OU or an account. Policies that affect an OU or account by inheritance do not count against these limits.” So a deeply nested account can be subject to far more than ten tag policies, and the limit will never tell you. The same note closes off the usual escape: “All policy limits are hard limits.”
Compliance lives in a different service from the policy
Organizations holds the policy; Resource Groups holds the answer. That split is worth knowing before you look for a compliance view in the wrong console, and it has a practical consequence: the people who write the tagging standard and the people who can see who is failing it are often looking at different screens with different permissions.
One prerequisite before any of it: “Tag policies are available only in an organization that has all features enabled.”
Why This Architecture Holds Up
Not evaluating untagged resources is consistent, even though it disappoints
A tag policy describes what a tag should look like. A resource with no tags has nothing to compare against the schema, so marking it non-compliant would mean the policy was quietly asserting a second thing — that the tag must exist — which is a different rule with a far larger blast radius. Keeping the two separate is why enforcement can be switched on without accidentally blocking every untagged resource in the organisation.
Pointing at SCPs in the limitation itself is the right documentation
It would have been easy to leave “does not enforce missing tag keys” as a line in a limitations list. Putting the alternative in the same paragraph is what turns a disappointed reader into a correctly configured one, and it is the same instinct as the AMI-sharing bypass being named in the considerations of the feature it bypasses in #102.
Case sensitivity as an explicit option is a good default
CostCenter, costCenter and Costcenter being three keys is a fact
of AWS tagging, not of tag policies — the policy just gives you a way to stop it. Making it an
option rather than always-on matters, because an estate that has been accumulating variants for years
needs to see the report before it starts refusing the operations.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Making tags mandatory | An SCP with a tag condition on creation | AWS names it: a tag policy “does not enforce missing tag keys” |
| Making tag values consistent | A tag policy, reporting first | It is the only mechanism that understands allowed values and capitalisation |
| Turning on enforcement | One test account, then widen | AWS's own warning: you could “prevent users … from creating the resources they need” |
| Services that propagate tags | Check the child resource's policy, not the parent's | Enforcement there “may block dynamic scaling and provisioning” |
| Reading compliance | Resource Groups, with access for whoever owns the standard | The policy and its compliance view live in different services |
The audit worth running
Compare your tag policy compliance report against a plain inventory of resources. The difference between them is the untagged estate, and it is invisible to the first document by design. If the two numbers are close, your problem really was consistency; if they diverge, the tag policy was never going to be the answer.
For every resource type you plan to enforce on, find out what creates it. If anything creates it on your behalf and propagates tags, enforcement is a change to your scaling behaviour as well as to your tagging.
Then check who can see the compliance view. A standard nobody can measure against is a document, and Resource Groups is where the measurement lives.
Closing Thought
The recurring shape in this series is a control that is precisely described and widely read as larger. Tag policies are the clearest case yet, because the gap is between what the feature is called and what the first paragraph says it does: it standardises the tags attached to resources, and a resource with no tags has none attached.
What makes this one unusually easy to get right is that AWS writes the answer next to the limitation. Mandatory tagging is an authorization question, so it belongs to SCPs. Consistent tagging is a schema question, so it belongs here. Most estates need both and install one.
#103 separated policies by where they act. This is the same separation arriving as a practical question on a Monday morning: whoever asked you to “enforce tagging” meant two different controls, and only one of them is in the console tab marked tag policies.
Cost & Governance — AWS Resource Groups and Tag Editor: how tag policy compliance is actually surfaced, what the compliance view can and cannot see, and what remediating a non-compliant tag involves.
Official AWS Reference
- Tag policies — what a tag policy standardises, the statement that rules apply to resources when they are tagged, the statement that untagged resources and undefined tags are not evaluated, what enforcement prevents, the split between Organizations and Resource Groups, the all-features prerequisite, and the caution before enforcing
- Enforce tagging consistency — preventing resource creation on noncompliant tag values, case-sensitive key treatment, the statement that basic compliance rules do not enforce missing tag keys at resource creation, the direction to use SCPs for mandatory tags, enforcement being limited to supported resource types, and the warning that enforcement may block dynamic scaling and provisioning where tags propagate
- Quotas and service limits for AWS Organizations — the 10,000-character tag policy document size, the limit of 1000 tag policies per organization, the maximum of ten attached to a root, OU or account, and the note that inherited policies do not count against those limits and that all policy limits are hard
- Services and resource types that support enforcement — further reading on which resource types enforcement reaches; no claims in this post are drawn from it
- Getting started with tag policies — further reading on the recommended rollout workflow; no claims in this post are drawn from it
Comments