Paste an AWS Organizations tag policy, or a plain list of Key=Value tags. The case collisions are the ones to look for: tag keys are case-sensitive, and a split dimension is not restated in cost history once it has happened.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Validate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Tag keys are case-sensitive, so every report grouped by one silently omits the resources carrying the other
{
"tags": {
"cc": { "tag_key": { "@@assign": "CostCenter" } },
"cc_legacy": { "tag_key": { "@@assign": "costcenter" } }
}
}Without enforced_for the policy is a compliance report, not a control: non-compliant resources are created successfully
{
"tags": {
"owner": { "tag_key": { "@@assign": "Owner" } }
}
}Permitting prod and Prod splits the dimension for the rest of time, which is what the allow-list existed to prevent
{
"tags": {
"env": {
"tag_key": { "@@assign": "Environment" },
"tag_value": { "@@assign": ["prod", "Prod", "staging"] }
}
}
}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Keys are case-sensitive, so `CostCenter` and `costcenter` are separate tags. Every report grouped by one omits the resources carrying the other, and because the grand total is unchanged the gap never announces itself.
Instead:Pick one form and delete the other rule, before the tags are in use. Cost allocation history is not restated.
A tag produces nothing in cost reports until its key is activated as a cost allocation tag, and activation applies from that point forward only. Every day in between is a day of history you cannot break down later.
Instead:Activate each key as it is defined, before the rollout.
A policy with no enforcement is a compliance report. Non-compliant resources are created successfully and appear in a report afterwards, which is not what most people believe they configured.
Instead:Add `enforced_for` once the existing estate complies. Enforcing before that blocks legitimate work.
Those two facts together are why a tagging mistake is expensive rather than annoying. CostCenter and costcenter are two different tags, both valid, both applied, and the history you lose to the split never comes back.
Every report grouped by CostCenter silently omits the resources tagged costcenter. Nothing errors, nothing looks wrong, and the grand total across all resources is unchanged, so the gap does not announce itself. It surfaces months later as a cost centre whose spend does not match what the team knows it is running.
A perfectly tagged estate produces nothing in cost reports until each key is activated as a cost allocation tag, and that is a separate action in a separate console. Activation applies from that point forward: costs already incurred are not broken down retroactively. Every day between rollout and activation is a day of history you cannot analyse later, which makes the ordering of those two steps matter more than either one.
A tag policy with no enforced_for does not prevent anything. Non-compliant resources are created successfully and appear in a compliance report afterwards. That is a reasonable first step, and it is not what most people believe they configured. Enforce only once the existing estate complies, because enforcing before that blocks legitimate work.
Permitting prod and Prod in the same tag_value list means both appear, which splits the dimension exactly as a key collision does. Pick one form. Lowercase is the usual choice, mostly because it is the only one nobody argues about.
A policy that only requires the key to exist is satisfied by Owner= with nothing after it. The resource is compliant and you still do not know who owns it, which is the question the tag existed to answer.
Keys beginning aws: are set by the service and cannot be created or modified. A policy governing one enforces nothing and can never be satisfied.
Your resources. It checks the policy document, or a list of tags you paste, and has no way to know which resources exist or what they currently carry. It also cannot tell you whether the taxonomy is a good one: a policy can be structurally perfect and still describe tags nobody can fill in correctly. Everything runs in your browser with no credentials and no API call.