Cost Attribution

Cost attribution is the mapping from a line on an invoice to a person who can change it. Without it, cloud spend is a single number owned by finance, describing decisions made by engineers who never see it.

Every other cost control depends on this one. Budgets need an owner. Unit economics need a denominator per service. Waste reclamation needs someone to confirm a resource is unused. Design review needs a comparison against a team's actual spend. None of these is possible against an unattributed total.

Why it must be enforced at creation

Retroactive tagging never fully happens. Resources are created by automation, by templates, by people who have left, and by processes nobody remembers. Each unattributed resource is permanently unattributable in practice, and the untagged fraction grows.

Enforcement at creation — blocking untagged resources, or automatically flagging them for deletion — is the only mechanism that keeps coverage high. It is also cheap, because it costs one policy rather than a continuous cleanup programme.

Implementation patterns

• A small, mandatory tag set: owning team, product or service, environment, cost centre. Long tag taxonomies are applied inconsistently and become unusable.
• Applied by the platform, not by people. Service templates and infrastructure modules set tags automatically, so compliance is the default rather than a discipline.
• Shared costs apportioned by a documented driver — database cost by query time, cluster cost by CPU seconds, cache cost by key share. The driver should be what causes the cost, and the choice must be written down, because it will be argued about and an undocumented apportionment is indefensible.
• Fixed platform costs reported separately, rather than smeared across teams. A per-team number inflated by an arbitrary share of overhead is not decision-useful.
• Delivered daily into the team's own dashboards, next to latency and error rate — not in a monthly finance report in a separate tool.

Industry example

Platforms whose spend grows faster than traffic over several quarters almost always share one root cause: nobody owns any part of the number. The individual decisions producing the growth — instances sized for a peak that has moved, environments outliving projects, retention set to maximum, redundancy added after different incidents — are each defensible and collectively unowned.

The consistent finding is that most reduction comes from engineers seeing a number they did not expect, not from a central optimisation programme. That makes attribution the highest-leverage intervention available, and it is why mature practices treat tagging enforcement as infrastructure rather than as housekeeping.

The second-order benefit is that attribution turns cost into a design input. A team that can see its cost per request will notice a design change that doubles it; a team that cannot will not.

Failure scenarios

• Retroactive tagging programmes, which reach a plateau well short of complete and then decay.
• Tag taxonomies with twenty fields, applied inconsistently, producing data nobody trusts.
• Attribution without delivery — accurate data in a system engineers never open.
• Shared-cost apportionment invented per report, so numbers change between reports and credibility is lost.
• Attribution used punitively, which turns the practice into an audit and ends cooperation.

Trade-offs

Enforcement adds friction to resource creation and will occasionally block legitimate work — mitigated by making the tagged path the easy path through templates and modules.

Apportioning shared costs is inherently approximate, and precision is unattainable. The correct posture is a model that is consistently applied and openly approximate, because a model that is argued about every month delivers nothing regardless of its accuracy.

Interview question

"Your cloud bill has doubled in eighteen months and nobody can say which team caused it. What is the first thing you build, and what do you do about the resources that already exist untagged?"