The tags are on the resources and the cost report is still empty

Written by Formiga, an independent AWS consultancy. This page contains no product, nothing to buy on it, and no capability claim about any tool. It is the checklist we use ourselves.

1. Tagging a resource and being able to report on its cost are two different acts

This is the whole article, and most tagging projects are built without knowing it.

Applying Team=payments to an RDS instance is an act performed on the resource, in the account and Region where the resource lives, by whoever has permission on that resource. It is usually the part that gets a ticket, a Terraform module and a policy.

Making Team available as a dimension you can group a bill by is a separate act, performed once per tag key, in Billing and Cost Management, and — in an AWS Organization — from the management account. Nobody on the workload team can do it, which is precisely why it is the step that goes missing: the people who care about the answer are not the people who hold the switch.

A tagging scheme can therefore be 100 % applied, policy-enforced, and passing every audit of resource tags, while Cost Explorer still shows you nothing but service names. Nothing is broken. The second act has not happened.

2. What AWS states, read at source

All of the following is from AWS, Activating user-defined cost allocation tags (docs.aws.amazon.com → awsaccountbilling → activating-tags), read by us on 2026-08-22. Check it yourself; it is short, and it is the page the argument rests on.

Tags do not appear on billing reports unless you activate them. AWS's own sentence is For tags to appear on your billing reports, you must activate them.
You activate the tag key, not a key/value pair. Activating Team affects every value that key carries. This is good news operationally and it is why the activation list is short even when the tag cardinality is enormous.
There are two separate delays, and they add. After you apply a tag it can take up to 24 hours for the key to even appear in the cost allocation tags page so that you can activate it. After you activate it, it can take up to a further 24 hours to become active. So the honest planning number is up to 48 hours from applying a new tag key to it being usable, and the first 24 of those look identical to a broken tagging pipeline.
Activation can be done in bulk through the API rather than by clicking, via UpdateCostAllocationTagsStatus. If you are activating more than a handful of keys, or want the activation set itself in version control, this is the mechanism.
There is a tag AWS manages for you: awsApplication is added automatically to resources associated with applications set up in Service Catalog AppRegistry, is activated for you, and does not count against the cost allocation tag quota. You can deactivate it — and AWS states that if you do, it will not be automatically activated again.

3. What that page does not say, and why we are pointing at the hole rather than filling it

The question every finance team asks within a minute of learning about activation is: what happens to the cost data from before I activated?

The AWS page above does not answer it. We read the page for this article and it addresses what activation is, how to perform it, and how long it takes. It does not make a statement about the treatment of historical periods, and we are not going to supply one from memory, from a forum post, or from what was true the last time we looked. This is the single most expensive assumption in the whole area and it deserves a primary source, not a confident paragraph from a consultancy's blog.

The useful move is not to find out the answer from us. It is to stop treating the activation date as an administrative detail and start treating it as the start of your evidence. Whatever the retroactivity rule turns out to be for your account and your report type, the date you activated a key is a fact you will be asked for, and almost nobody records it.

If you need a defensible answer for your own estate, get it from AWS Support or from the current documentation on the day you need it, and write the answer down with the date you got it. That sentence is worth more to you than anything we could assert here.

4. Six ways a tagging scheme looks finished and reports nothing — our opinion, from our own work

Everything in this section is operational opinion. It is not a claim about your estate, which we have not seen.

What it looks like	What is actually happening
Tag coverage dashboards are green; the cost report has one untagged bucket holding most of the spend.	The keys were never activated, or were activated for some keys and not the one the report groups by. Coverage measures the first act; the report needs the second.
The tag works in one account and not in another.	Activation is an organization-level act performed from the management account. A tag applied diligently in a member account by a team with no access to Billing will never surface on its own.
The tag appeared, then a large slice of spend stayed untagged anyway.	A significant share of an AWS bill attaches to things that are not taggable resources at all — data transfer, support, some marketplace and shared charges. A tag cannot allocate a charge that has no resource to hang on. Decide the split rule deliberately; do not let it show up as a mystery.
`Team`, `team` and `TEAM` all appear in the console.	Keys are distinct strings. Three keys means three activations, three columns and a permanently split report. This is the cheapest failure to prevent and the most tedious to reverse.
Someone renamed a tag key to something clearer.	A rename is a new key. It needs its own activation, it starts its own history, and the old key's history does not move with it. Renaming a cost allocation tag is a data event, not a cosmetic one.
Everything is correct and the numbers still do not reconcile to the invoice.	Cost Explorer, the Cost and Usage Report and the invoice answer slightly different questions about amortisation, credits, refunds and tax. Pick which one is your source of truth before the meeting, and reconcile to that one deliberately. Most "the tags are wrong" arguments are actually this.

5. The order to do it in

Opinion, and it is the order we use because each step makes the next one cheap rather than the other way round.

Decide what question the tag has to answer before choosing keys. "Which team spends what" and "which customer costs what" produce different schemes, and a scheme that tries to do both usually does neither.
Fix the key names first, in writing, including case. Fewer keys than you want. Every key you add is an activation, a column and a thing that can drift.
Activate the keys before the rollout, not after. The delay is up to 48 hours and it runs in the background while you do the work. Doing this last is the standard way a project ends with a fortnight of blind data at exactly the moment everyone starts looking.
Record the activation date for every key somewhere that outlives the project. You will be asked what your numbers mean before that date.
Only then enforce. Tag policies and preventative controls are the right tool and the wrong first tool — enforcing a key you have not yet activated produces perfect compliance and an empty report.
Check the untagged residue on purpose, monthly. Its size is the honest measure of whether the scheme works. Coverage percentage on resources is not, because the untaggable charges never enter that denominator.

6. If you only do one thing this week

Open Billing and Cost Management in your management account, go to Cost allocation tags, and compare the list of active keys against the list of keys your Terraform or tag policy actually applies. Our opinion, from doing this repeatedly: the two lists disagree far more often than anyone expects, and the disagreement is usually in the direction of "we are applying a key nobody activated" rather than the reverse. It takes about ten minutes and it either finds the problem or rules it out, which are both good outcomes.

What this page does not claim

It does not claim your estate has any of these problems — we have not seen it. It quotes no cost figures, no savings percentage and no quota number, and it deliberately does not state a retroactivity rule, because the AWS page we read for this article does not state one and we will not invent it. Section 2 is AWS's, read at the URL and on the date given there; sections 1, 3, 4, 5 and 6 are our own operational opinion, offered as opinion. This is not legal, audit, tax or accounting advice, and it is not a statement about what any certification or regulation requires of you; confirm those with your auditor. AWS documentation changes — if this page and AWS disagree, AWS is right and we would be glad to be told.

If you want the activation-versus-application audit run against your own accounts, that is the work we do: what we do and what it costs. There is a form on the front page and a person reads it. Related: four AWS line items that look like waste and are usually a decision — the report this page is about is what you need before that argument is worth having. And your RTO and RPO are guesses until someone outside your team has restored from them.