Glossary
Tagging strategy
Also: Cost allocation tags · Resource tagging
A binding scheme that assigns every resource to its team, its environment and its cost centre.
Tags are key-value pairs on a resource. Technically trivial, organizationally the point where cost work succeeds or fails. Without attribution you cannot say which team causes which cost, and without that attribution every saving measure becomes a management topic instead of a team decision.
A workable scheme is small. Four mandatory fields are enough in most organizations: team, environment, application and cost centre. Prescribe twenty tags and you do not get twenty maintained tags, you get none. Optional extra tags may exist alongside, but they are not part of the obligation.
The values have to be standardized. "prod", "Prod", "production" and "PROD" are four different environments as far as reporting is concerned. A fixed value list, checked in the pipeline, is the difference between a report and a guessing game.
Enforcement is decisive. A tag that is voluntary is missing on a third of resources after six months, and then every report is worthless. Enforcement means concretely: a deployment without mandatory tags fails, checked in the infrastructure pipeline, complemented by tag policies at organization level.
For tags to appear on the bill they additionally have to be activated as cost allocation tags. That is often forgotten. And activation is not retroactive: cost from before stays unattributed.
Not every resource can be tagged. Data transfer, some managed services and shared infrastructure such as NAT gateways carry no meaningful tags or are used jointly. That remainder needs a deliberate allocation rule, otherwise it lands as an unexplained block in the report.
How you notice it
- A substantial part of the bill cannot be attributed to any team.
- There is a documented tagging concept but no check in the pipeline.
- The same environment is named differently in different places.
- Tags exist but do not appear as filters in Cost Explorer.
Not to be confused with
- Separate AWS accounts
- The harder separation: one account per team or environment attributes cost without tags. More work to set up, but impossible to bypass. In larger organizations the better foundation.
- Cost categories
- Rules that group cost after the fact, for example several accounts into one area. They complement tags rather than replacing them, because they resolve nothing inside an account.
- Cost allocation tags
- Not a concept of its own but the switch that enables an existing tag for cost reporting. Without it the best tagging never shows up on the bill.
When it fits
- Several teams or applications share one account.
- Before starting any cost work, because nothing can be steered without attribution.
- When cost is to be charged back internally.
When it does not
- As a replacement for account separation in large organizations. Tags are softer and can be bypassed.
- With more than four or five mandatory fields. An overloaded scheme is not maintained.
- Without enforcement. Voluntary tagging produces data you cannot rely on, and that is worse than none.
How to approach it
- Define the scheme, keep it smallTeam, environment, application, cost centre. A fixed value list per field. More fields mean less maintenance, not more information.
- Enforce it in the pipelineA check in the infrastructure code that rejects a deployment without mandatory tags. That is the point where an intention becomes a fact.
- Add tag policies at organization levelThey standardize spelling and prevent resources created outside the pipeline from deviating.
- Activate them as cost allocation tagsWithout this step the tags do not appear in Cost Explorer and the CUR. It is not retroactive, so do it early.
- Tag the existing estateVia the Resource Groups Tag Editor or a script. Work by cost share: the twenty most expensive resources bring more than two hundred small ones.
- Allocate the unattributable remainder deliberatelyDistribute shared infrastructure by a fixed key and document it. An unexplained block otherwise makes every report contestable.
Frequently asked
How many mandatory tags make sense?
Four to five. Team, environment, application and cost centre cover the usual reports. Every further mandatory field lowers the likelihood that anything is maintained at all. Additional voluntary tags may exist alongside, they are simply not part of the check.
Is tagging enough or do we need separate accounts?
For two or three teams tagging is enough. Beyond a certain size, account separation is the better foundation, because it cannot be bypassed and separates permissions and blast radius at the same time. The two are not mutually exclusive: separate accounts for the coarse split, tags for the fine one.
How do you handle cost that cannot be attributed?
Allocate it deliberately and document the rule, for example by share of attributable usage. What matters is that the rule is named. An unexplained remainder makes every report contestable, and the first number someone doubts costs more credibility than three correct ones build.
Do newly activated tags apply retroactively?
No. Cost allocation tags apply from the moment of activation. Cost from before stays unattributed. That is why it pays to define and activate the scheme early, even when no report is pending.