Your Cloud Bill Is Not a Finance Problem

TL;DR - Your cloud bill is not a finance problem. It is a feedback problem, and finance cannot repair a feedback loop they are not standing in. The invoice arrives monthly, aggregated, six weeks after the decision that caused it, addressed to somebody who cannot change a single line of it. The people who can change it - the ones who picked the instance size, the log retention, the always-on staging environment, the chatty cross-zone call between two services - never see a number at all. So the organisation does the only thing left available to it: an annual panic sprint that rightsizes everything, claws back twenty percent, and gives it all back within two quarters, because nothing structural changed. The alternative is to treat cost the way you treat every other platform capability. Attribution as a default of the paved road, not a tagging campaign. Unit cost, not total spend. The number shown where the work happens. Defaults that are cheap by construction. Showback before chargeback. Cost is a property the platform ships, not a spreadsheet somebody emails around in Q4.

I build and run platforms for a living, and cloud cost reaches me in exactly two ways. Either it is quiet and nobody has thought about it in a year, or it is an emergency and somebody senior wants a plan by Friday. There is rarely anything in between, which is itself the diagnosis. Cost in most engineering organisations is not a practice. It is a weather event.

The scene when it becomes an emergency is always the same. Finance has noticed the bill grew forty percent year on year. A spreadsheet gets exported from the billing console, sorted descending, and the top ten line items are circled. Somebody asks who owns the second one. Nobody knows. It is a resource group named prod-2, created in 2023 by someone who has since left, and the honest answer is that the company is paying a five-figure annual sum for a thing no living person can describe. That single unanswerable question tells you more about your platform than any maturity assessment will.

The bill is a feedback loop with every wire cut

Strip away the accounting and cloud spend is a control system. Someone makes a decision, the decision has a cost, and the cost should come back to the person who made it so the next decision is better informed. That is the entire mechanism. Everything else is bookkeeping.

Now look at how the loop is actually wired in a typical org, because every wire in it is cut:

• It reaches the wrong person. The invoice goes to finance and to a VP. Neither of them chose an r6i.4xlarge for a service that idles at eight percent CPU. The people who did are three levels away and were never in the conversation.
• It arrives too late to teach anything. The decision was made in a pull request in March. The signal shows up in an April invoice, discussed in May. By then the engineer has shipped four other things and could not reconstruct their reasoning if you asked. Feedback delayed past the point of memory is not feedback, it is history.
• It has no resolution. “Compute: $412,000” is not actionable at any level. It is the sum of thousands of decisions with the labels removed. You cannot act on an aggregate, you can only panic about it.
• Nobody owns the number. Every service has an owning team. The bill does not. It is a company-level total that belongs to everyone, which in practice means it belongs to no one, and unowned numbers only ever move in one direction.

This is the same failure I keep meeting in other guises. It is what I mean when I write about monitoring that produces a wall of green while the users are suffering: a signal that is technically correct and structurally useless, because it is measured somewhere convenient rather than somewhere it can change a decision. Cost is exactly that. It is real, it is measured with impressive precision, and it lands on a desk with no hands attached.

There is a test I like here, borrowed openly from the error-budget question of whether a number has ever changed what a team did next: pick a service, ask the team that owns it what it costs to run per month, and time the answer. If they can tell you inside a minute without asking anyone, you have a cost practice. If the answer requires a ticket to the cloud team, or a person in finance, or a caveat about shared resources, you do not have one - you have an invoice, which is a different thing entirely.

The cost sprint proves the point

Watch what happens when the emergency lands, because the standard response is a beautiful demonstration of why this is a platform problem and not a finance one.

A tiger team forms. Two or three good engineers spend three weeks in the billing console. They find genuinely embarrassing things, because there are always genuinely embarrassing things: the staging cluster that runs at production size around the clock, seven terabytes of logs retained for two years because that was the default, a decommissioned service’s database still running because nobody was certain, the load balancer from the migration that finished in 2024. They rightsize, they delete, they buy some commitments. The bill drops eighteen percent. There is a slide. Everyone is pleased.

Eighteen months later the bill is higher than when they started.

None of that work was wasted, and none of it was a practice. It was incident response applied to spending, and it failed for the same reason a postmortem that produces a document and no change fails: the team fixed the instances but not the mechanism that produced them. Every one of those wasteful resources was created by a person acting reasonably inside a system that gave them no cost signal and no cheaper default. Clear the waste without changing the system and the system simply manufactures more, at roughly the rate it did before, while everybody congratulates themselves on the eighteen percent.

The reframe is the whole post: cost is not a cleanup job, it is a property of the paved road. An internal developer platform is a thin layer of opinions over the building blocks your teams already use, and what a default costs to run is one of those opinions, whether or not anyone expressed it deliberately. Every wasteful resource in that spreadsheet is a place where the platform’s opinion was expensive, or where there was no default at all and an engineer had to guess. Guesses are conservative, because nobody ever got in trouble for overprovisioning. They got in trouble for the outage.

Attribution is a default, not a campaign

You cannot give anyone a signal you cannot compute, so this starts with attribution - being able to say which team and which service caused which spend. This is where most efforts begin and where most of them die.

They die because attribution gets run as a campaign. An email goes out asking every team to tag their resources by the end of the quarter. Compliance reaches sixty percent, then stalls, then decays, because tagging is unrewarding work for the people asked to do it and nothing enforces it. Six months later somebody sends the same email. This is the identical shape as the security failure where a rule gets shipped without the road that satisfies it, and it fails identically. You asked developers to pay a tax to solve your problem.

The platform version is not a request. It is a default:

• The tags come from the module, not the human. If services are provisioned through shared Terraform modules and a golden-path template, then owner, service, environment and cost-centre are applied by the code that creates the resource. The developer supplies the service name once, at scaffold time, and the attribution comes free forever after. Nobody tags anything, and everything is tagged.
• Untagged is a platform bug, not a team failure. When an unattributed resource appears, the interesting question is which creation path lacks the default. Fix that path and the entire class disappears. Chase the individual resource and you will be chasing it again next month.
• Enforce at provision time, gently and in that order. Warn on untagged resources, then block new ones, then go back for the old. This is the observe-warn-enforce rollout that makes any control land without a riot, and it applies to cost hygiene as much as it does to security policy.
• Accept that some of it will never attribute. The NAT gateway, the shared cluster’s control plane, the observability backend, the data transfer nobody can trace. Split shared cost by a simple, published, slightly unfair rule and move on. Do not chase perfect allocation, because the last fifteen percent costs more to argue about than it does to waste. Eighty percent attributed and acted on beats a hundred percent attributed and disputed.

The prize for getting this right is that cost stops being one number and becomes several hundred, each with a name on it. That is the point at which the conversation can move from the VP’s inbox to the teams who can actually do something.

Unit cost is the only number that says anything

Here is where most cost dashboards go wrong even after the attribution works: they show total spend, and total spend is close to meaningless on its own.

If a service’s monthly cost doubled, is that bad? You cannot possibly know. If it doubled while traffic tripled, that service got cheaper and somebody deserves a nice message. If it doubled while traffic was flat, something is wrong and it is worth an afternoon. The absolute number carries neither of those facts. Total spend rising in a healthy growing company is a symptom of the company working, which is exactly why “the bill went up” triggers so much unproductive alarm, and also why nobody can tell a real problem from a good quarter.

What you want is unit cost: spend divided by something the business actually does. Cost per thousand requests. Cost per tenant. Cost per completed order, per processed video, per indexed document, per active user. Pick the denominator that matches how the service creates value, and track the ratio.

This is the same instinct as insisting a reliability indicator be measured on the user’s journey rather than on a host’s uptime. Measure the thing that carries meaning, not the thing that is convenient to collect. Unit cost gives you three properties that total spend never will:

• It survives growth. A team can triple its footprint and still be improving, and the number says so. This matters enormously for the politics, because it means a growing team is not automatically on the defensive.
• It exposes the shape of your economics. Cost per tenant is the number that tells you whether your enterprise tier is profitable, whether your free plan is a marketing expense or a slow leak, and whether that one customer with the unusual usage pattern is being subsidised by everyone else. That is a genuinely strategic number that most engineering orgs cannot produce, and it belongs in the same conversation as where you draw your build-versus-buy line.
• It makes efficiency a normal engineering result. Latency went down, unit cost went down, error rate went down. Same category, same review, no special ceremony.

Two or three unit-cost metrics on the services that dominate the bill are worth more than a per-service breakdown of everything. Resist the wall of numbers, for the same reason you resist a dashboard nobody reads and nobody acts on. A number becomes a practice when someone looks at it on a normal day, and people only look at a handful.

Put the number where the work happens, and make the default cheap

Now the delivery, which is the part that separates a platform capability from a reporting exercise. Two moves, and the second matters more.

Move the number to where the decision is made. The billing console is a place people visit during an emergency. That is not where cost decisions happen; cost decisions happen in a pull request that changes an instance type, in a Helm values file, in the retention setting nobody thought about. So put the signal there. An estimated cost delta commented on infrastructure pull requests is the highest-value cost tooling I have seen anywhere: it turns an invisible consequence into a visible one at the exact moment a human is deciding, and it costs a day to wire up. Put monthly cost on the service dashboard next to latency and error rate, so it reads as one of the service’s vital signs rather than a finance artefact. Send a small weekly digest per team - your spend, your unit cost, what moved and why - rather than a monthly spreadsheet with forty tabs. The signal has to reach the person with their hands on the thing, while their hands are still on it.

Then make the default cheap, because defaults beat diligence every time. This is where the real money is, and it is unglamorous:

• Non-production does not run at production size, and does not run at night. Scale-to-zero or a scheduled shutdown on development and staging environments is often a double-digit percentage of the entire bill, applied once, in the template, forever.
• Ephemeral environments expire. A preview environment per pull request is a wonderful thing and a liability if it outlives the branch by four months. Give it a time-to-live at creation. Expiry is a property of the paved road, not a cleanup rota.
• Retention defaults are a decision, so make it once. Thirty days of logs hot and the rest in cold storage is the right answer for almost everybody, and “whatever the tool shipped with” is the wrong answer for almost everybody. One default, set centrally, moves more money than a year of nagging.
• Right-sized templates with autoscaling. If the golden-path template ships a sensible small default that scales up under load, the overprovisioning problem mostly stops being created. The engineer who picked the enormous instance was not careless. They were guessing, alone, at 6pm, with an outage as the only visible downside.

Every one of these is a change to the paved road rather than a change to a person’s behaviour, which is why they hold. Behaviour regresses when the campaign ends. Defaults do not.

Showback before chargeback, and who owns this

Two organisational questions come up immediately, and both have a boring answer.

Showback, not chargeback, at least at first. Showback means each team can see what it spends. Chargeback means it lands in their budget and they answer for it. Chargeback sounds more rigorous and is usually a mistake early on: it needs an internal accounting apparatus most companies should not build, and it starts producing decisions that are locally rational and globally stupid - a team refusing to adopt the shared platform because the cross-charge looks worse than their untracked spend, or engineering effort redirected into gaming an allocation formula instead of reducing actual cost. Visibility recovers most of the value with none of that. The number being seen, by name, by people with pride in their work, does an astonishing amount on its own. Move to chargeback later, if you have a genuine reason and an accounting function that wants it.

Ownership splits cleanly, along the same lines as every other cross-cutting capability, and the Team Topologies interaction modes name it precisely. The platform team runs cost visibility as a service: the tagging defaults, the pipeline, the dashboards, the pull-request estimates, the cheap templates. Finance is an enabling team and a stakeholder, not the operator, because they own the contract and the forecast but cannot change an instance type. The team that owns a service owns its unit cost, the same way they own its error rate. Nobody needs a FinOps department to start; they need one default, one dashboard, and one owner per number.

When this is the wrong answer

The honest off-ramps, because a cost capability has a scale below which it is pure ceremony, and I have watched teams build the apparatus at the wrong moment.

• Your bill is small enough that the apparatus costs more than the waste. At eight thousand a month, the correct cost practice is one person spending half a day per quarter in the billing console, and a habit of deleting things. Building attribution pipelines and unit-cost dashboards for that is the same category error as running Kubernetes for three services: infrastructure sized for a problem you do not have.
• You are pre-product-market-fit and burning runway deliberately. Speed is worth more than efficiency when the risk of dying is “nobody wanted it” rather than “we could not afford it”. Overprovision, ship, and come back when there is a business to make efficient. Optimising the cost of a product that fails is the most complete waste available.
• Your spend is dominated by one thing you cannot move. If seventy percent of the bill is a committed contract or a single data platform, this is a project with a named owner, not a distributed capability. Do that project. Do not build a company-wide showback culture to address one line item.
• Your cloud already sells you the whole capability. Native cost allocation tags, per-team budgets and alerts, anomaly detection: if the provider has it, adopt it and spend your effort on the defaults instead. Keep the stack boring and the opinion layer thin.
• There is nowhere to put the defaults yet. With no service template and no shared modules, cost work has nothing to attach to and decays into a tagging campaign, which is where we came in. Build the paved road first, then hang cost off it. The order matters more than the tooling.

And one guardrail that applies even when all of this is right: engineering time is more expensive than compute. A senior engineer spending a week to save three hundred a month has destroyed value with impeccable diligence. Cost visibility exists so people can make cheap decisions cheaply, not so the org acquires a new form of theatre in which everybody performs frugality. When cost becomes a virtue rather than a variable, you have swapped one dysfunction for a more tiring one. The opportunity cost of your best engineers’ attention is real, and it does not appear on any invoice.

The bottom line

The bill is not the problem. The bill is a report, arriving monthly, about decisions made weeks ago by people who never saw its contents. Handing that report to finance and asking them to reduce it is asking the smoke alarm to put out the fire.

Treat cost as what it actually is: a feedback signal that belongs inside the platform, alongside latency and error rate and deploy frequency. Attribute automatically through the templates, so nobody runs a tagging campaign again. Report unit cost rather than total spend, so growth and waste stop looking identical. Show the number in the pull request and the service dashboard, where hands are still on the work. Make the default cheap, because the default is what ninety percent of your estate will inherit. Show teams their spend before you charge them for it, and let ownership follow the service.

The question to ask is not “how do we cut the bill?” It is: when this number moves next month, who sees it, and what will they do differently? If the answer is a spreadsheet, a VP, and a panic in Q4, you do not have a cost problem. You have a platform gap, and it happens to be denominated in currency.

If your cloud bill is growing faster than your traffic and nobody can tell you which services are responsible - or you have run the cost sprint twice and watched the savings evaporate both times - that is exactly the kind of thing I help teams fix properly. Let’s talk.