In most organisations, Azure cost is simultaneously everybody’s responsibility and nobody’s. Engineering owns the architecture. Finance owns the budget. Operations owns the infrastructure. Procurement owns the contracts. Nobody owns the number that comes out of all four.
The result is predictable. When costs rise, the question of who is responsible produces a conversation rather than an answer. The conversation tends to resolve into an agreement to investigate — which is another way of saying that nobody owns it.
Three Patterns of Cost Accountability Failure
These are the patterns that produce that outcome, and they repeat across organisations of every size.
The shared tenancy problem. Multiple teams share a subscription, or a set of subscriptions, with no workload-level tagging or cost allocation. Each team knows it contributes to the total. No team is solely accountable for any part of it. When the total is questioned, every team can point to the others, and they are not wrong to do so. Shared tenancy without explicit ownership is a structural guarantee of shared non-accountability.
The delivery incentive problem. Engineers are measured on speed, reliability, and feature delivery. Cost is not a metric in their performance framework. This is not a failure of character — it is rational behaviour in response to the incentives that exist. A team deploying a service will make the choices that get the service deployed and running well. If cost is not part of how they are evaluated, they will not optimise for it. The incentive structure is the policy, whether or not anyone has stated it explicitly.
The one-time decision problem. A technology decision is made at deployment: the VM size, the tier, the replication setting, the retention period. The workload runs, and the decision runs with it — indefinitely. The team that made the decision may no longer exist. The project may have closed. The costs continue regardless. One-time decisions are the primary source of Azure spend that nobody can explain, because the context for explaining it left the organisation months or years ago.
A Simple Model for Establishing Ownership
The fix is simpler to state than it is to implement, but it is not complicated in principle.
Every workload needs a named owner — not a team, a person — who is accountable for its cost. Teams diffuse accountability; individuals cannot. The owner does not need to be a technical person. They need to be the person best positioned to answer the question: is what this workload costs still justified by what it delivers?
Cost is reported to workload owners monthly, in business terms. Not in Azure service categories — in terms they can evaluate and be held to account for. If an owner cannot explain their workload’s cost in business terms, that is the first problem to solve.
Owners review with their architect quarterly: is this workload’s cost still justified by its business value? That review produces a recommendation — continue, optimise, or sunset — and that recommendation goes somewhere with authority to act on it.
In practice, I have tied workload ownership to an existing role rather than creating a new accountability structure. The resistance is lower when ownership is added to someone who already has a relationship with the workload — a product manager, a service owner, a business lead. The hardest part is not the model; it is the first conversation where a named individual realises they are now accountable for a number they had previously been able to ignore. That conversation is worth having early, and worth having with architecture in the room to explain what the options actually are.
What This Is Not
This is not a FinOps hire. A FinOps function without workload ownership accountability produces reports. Reports without owners produce nothing. The FinOps discipline is valuable — but it works when it is operating within a structure that has already established who is accountable. Without that structure, FinOps is a very sophisticated way of producing cost data that nobody acts on.
This is not a cost-cutting exercise. The goal is not to spend less — it is to spend with visibility and intent. Some workloads will be reviewed and found to be good value. Others will not. That distinction cannot be made without the structure to make it in.
And this is not a one-time governance project. Ownership without review atrophies. The model needs to be maintained — owners change, workloads change, the business context changes. The quarterly review is not overhead; it is the mechanism that keeps ownership meaningful rather than nominal.
Cloud cost becomes someone else’s problem because it was never explicitly made anyone’s problem. The structural conditions that produce diffuse accountability are not accidents — they are the natural result of how cloud platforms are adopted and how organisations are structured. They can be changed, but they will not change themselves.
If cost accountability is diffuse in your organisation, the architecture conversation about how to fix it is the right place to start. Get in touch.
