You can't optimize what you can't attribute: a tagging playbook

There’s a question that decides whether cost optimization works in an organization: “who owns this spend?” If you can answer it for any line on the bill, optimization has a home — a team, a budget, a person who feels it. If you can’t, every saving is somebody else’s job, which means it’s nobody’s.

Attribution is that answer, and tagging is how you build it. It’s the least glamorous part of FinOps and quietly the most important, because everything downstream — chargeback, unit economics, even just “email the right team about their oversized instance” — depends on it.

Untagged is unownable

An untagged resource isn’t just missing metadata; it’s cost with no owner. It can’t be charged back, can’t be budgeted, can’t be questioned. And untagged spend has a way of being exactly the spend that’s wasted — because the resources nobody labeled are usually the resources nobody’s watching.

The goal isn’t 100% tag coverage as a compliance metric. The goal is that every dollar can be traced to a team and a purpose. Those sound the same and aren’t: the second one tolerates a good fallback for the long tail, and focuses effort where the dollars are.

A tag schema people will actually use

Tag sprawl kills tagging. Forty optional tags, inconsistently applied, is the same as no tags. Pick a small mandatory set and enforce it:

• owner — the team, not an individual who’ll leave.
• service — the application or system.
• environment — prod / staging / dev.
• cost-center — for finance, if you do chargeback.

Four tags, mandatory, is worth more than forty optional ones. Keep the values controlled — a fixed list, not free text — or team-a, TeamA, and team_a will fragment your reports into nonsense.

Enforce at creation, not in a quarterly cleanup

Retroactive tagging is a losing game — you’re always behind, and the untagged resources are the ones nobody remembers enough about to tag correctly. Move enforcement to creation time: policy that rejects or flags untagged resources, tags inherited from the account or namespace, defaults baked into your infrastructure-as-code modules so a resource is born attributed.

Fallback attribution for the long tail

You will never tag everything, and chasing the last 5% by hand isn’t worth it. That’s where account structure, namespace, and resource lineage become a fallback — spend that isn’t explicitly tagged can still be attributed by where it lives and what it’s connected to. A volume attached to a tagged instance inherits that instance’s owner. Perfect tags are the goal; structural inference is what covers the gap while you get there.

Attribution is the foundation everything sits on

Rightsizing, commitments, unit economics, cleanup — every optimization in this series assumes you can point a saving at an owner. Without attribution you’re optimizing a single anonymous number and hoping the right team notices. With it, every recommendation has a name attached.

That’s why Lizrd treats attribution as the base layer, not an afterthought: it reads your tags and your resource topology, attributes spend to owners even where tags are thin by following the connections in your infrastructure, and routes each optimization to the team that actually owns it. You can’t optimize what you can’t attribute — so we make attribution the thing that just works.