AI Unit Economics, FinOps & Infrastructure Cost ModelingPlaybook3 min readUpdated September 2026

Building a Cloud Tagging Taxonomy That Actually Sticks

A tagging policy that lives in a wiki page and nowhere else is a policy that decays within a quarter. The resources that get tagged are the ones someone remembered to tag by hand at creation time, and that share shrinks every time a new engineer joins or a deploy script gets copied from an old one.

The fix isn't a better wiki page. It's making an untagged resource something your pipeline actually rejects.

Which tags belong in a cloud tagging taxonomy?

Keep it to a small, mandatory set: team or cost center, environment, and product or feature. Anything beyond that becomes optional metadata people skip under deadline pressure, and an optional tag is functionally the same as no tag once you're trying to allocate a bill. Three enforced fields beat fifteen suggested ones every time. Add a fourth field only if you have a specific, recurring reporting need the first three genuinely can't answer, a customer-level cost allocation requirement, say, not because more data feels safer.

How do you enforce tagging in CI/CD?

The taxonomy only survives if a deploy or a Terraform apply without the required tags fails the pipeline, not if it merely triggers a Slack reminder someone can dismiss. Most infrastructure-as-code tools support a policy check step for exactly this; wiring it in once is a smaller project than most teams expect, and it's the single most effective step in this whole process. This works whether your infrastructure is provisioned through Terraform, CloudFormation, or a homegrown script, since the enforcement point is the pipeline step itself, not the provisioning tool.

Backfilling what's already untagged

New resources are the easy part once enforcement exists. Existing untagged resources need a one-time sweep, usually a script matching resource names or owning accounts against a lookup table you build by hand for the resources that predate the policy. Prioritize the backfill by dollar amount, not by how easy a resource is to fix, since a handful of large, expensive, untagged resources matter more to your total unallocated number than a long tail of small ones.

Budget for this taking longer than the enforcement rule itself, since it's manual reconciliation work against old naming conventions and half-remembered ownership, not a rule you write once and let run. Treat it as its own small project with a start and end date, rather than an open-ended cleanup that competes for attention with everyone's actual roadmap work.

What to do with the resources you can't attribute

  • Give shared infrastructure, a load balancer used by five teams, its own explicit shared-cost tag rather than leaving it blank
  • Route genuinely unattributable spend into a named overhead bucket that shows up on someone's report, instead of letting it vanish into an unlabeled total
  • Review that overhead bucket monthly, since a shrinking unattributable total is the actual sign the taxonomy is working

Common mistakes that undo the whole effort

  • Making the mandatory field list too granular, so people start leaving it blank the way they would an optional one anyway
  • Enforcing tags on new resources but never backfilling the old ones, so a large share of the historical bill stays unattributable
  • Letting the taxonomy be owned by whichever team wrote the original wiki page instead of whoever owns the pipeline where enforcement actually lives
  • Treating a passing enforcement check as proof the tags are accurate, when a bot can satisfy the rule with the wrong value just as easily as the right one

Keeping it from decaying again

Review tag compliance as its own number in your monthly infrastructure review, the percentage of spend correctly tagged, not just whether the policy document was updated recently. Put a specific target on that number too, ninety-five percent tagged spend within two quarters of launching enforcement, for example, so the review has a goal to measure against rather than just a trend to watch. A number that's tracked gets defended; a policy that's merely written down gets forgotten the next time someone's under a deadline.

Rotate ownership of that monthly check rather than leaving it permanently with whoever built the original enforcement rule, so it survives that person changing teams. A process that depends on one specific engineer remembering to run a report is not meaningfully more durable than the wiki page it replaced.

Executive Capability Standard

What Good Looks Like

The standard is that a defined, small set of tags is enforced at deploy time, not merely documented, and the share of spend correctly tagged is tracked as its own number every month.

Building The Capability (5-Stage Skill Ladder)

1. Learn:Pull last month's cloud bill and check what share of spend already carries your intended tags, by hand, to see how big the gap actually is.
2. Do Manually:Write the three-field tagging policy in a shared doc and start requiring it in code review before you build any automated enforcement.
3. Delegate:Assign a platform engineer to wire a tag-enforcement check into your deploy pipeline as a scoped, time-boxed project.
4. Automate:Add a scheduled job that reports the percentage of tagged spend to your finance and engineering leads every month automatically.
5. Buy:If backfilling historical untagged resources is a large one-time project, bring in a contractor to run that sweep rather than pulling your own engineers off other work for it.

How to Get Started

Frequently Asked Questions

How many tags should we actually require?

Three: team or cost center, environment, and product or feature. Anything beyond that turns into optional metadata people skip under deadline pressure, which defeats the purpose of making tags mandatory in the first place. Add a fourth only for a specific, recurring reporting need you can name.

What do we do about resources we genuinely can't attribute to one team?

Give them an explicit shared-cost tag rather than leaving the field blank, and route that spend into a named overhead bucket someone reviews monthly. The goal isn't zero unattributable spend, it's making sure what remains is a known, shrinking, and named quantity rather than an invisible one.

Is a CI/CD enforcement rule really necessary, or does a policy document work?

A policy document works right up until the first deadline crunch, when someone copies an old deploy script and the tags quietly go missing. A pipeline check that fails the deploy without required tags is what actually holds the line, because it doesn't depend on anyone remembering under pressure.

About the numbers

This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.

Related Guides