We have now assessed 84 client cloud estates. The spread in cost efficiency is enormous — the best run at roughly a third the unit cost of the worst, with broadly similar workloads.
The strongest predictor is not architecture. It is not instance choice, or commitment coverage, or whether they use Kubernetes. It is whether anyone can be named as the owner of a given line item.
Unowned cost only grows
A cost with an owner gets questioned. Someone sees it in their team's number, asks what it is, and either justifies it or kills it. That loop takes minutes and happens naturally.
A cost with no owner gets noticed by finance three quarters later, at which point nobody remembers what created it and everyone is afraid to turn it off. It becomes permanent, and it compounds.
The classic example: a staging environment provisioned identically to production for a load test in 2023. Nobody deleted it. Nobody could say whose it was. It ran for twenty-six months and cost the client about $340,000.
Allocation before optimisation
The instinct is to start with savings: right-size the instances, buy the commitments, tier the storage. These work, and they are almost always the wrong first move.
Without attribution you are optimising blind. You will right-size something load-bearing, cause an incident, and lose the political capital to do the rest. And you will not notice new waste appearing behind you at the same rate you are removing it.
Attribution first. A tagging policy, enforced at provision time — resources without an owner tag simply do not get created — plus a monthly report that lands in each team's inbox with their own number at the top.
That report alone typically removes 10–15% of spend before anyone does any engineering. People turn things off when they can see them.
Where the money actually is
Once attributed, the distribution is remarkably consistent:
Idle non-production. Development and staging environments running 24/7 to serve a nine-hour working day. Scheduled shutdown is trivial and typically removes 60% of non-production cost.
Over-provisioned databases. Almost always the largest single line. Provisioned for a peak that was estimated, never measured, and never revisited.
Data transfer. Invisible until you look, then frequently the second-largest item. Usually a chatty service pair across availability zones that could be co-located.
Orphaned storage. Snapshots, unattached volumes, old backups with no lifecycle policy. Individually small, collectively substantial, and completely safe to remove.
Log volume. Everything at debug level, retained for a year, in the most expensive tier available.
None of these are clever. That is the point. The interesting architectural optimisations are usually worth less than turning off the staging environment overnight.
Unit economics, not totals
The final step, and the one that changes the conversation permanently: express cost per unit of business value. Cost per transaction, per tenant, per active user.
A total that grows is alarming. A total that grows while cost-per-transaction falls is a company scaling well. Only one of those is actionable information, and finance teams almost never have the second.
Once a client has that number, the discussion stops being "why is the bill up 20%" and becomes "our unit cost fell 9% while volume grew 31%" — which is both more accurate and considerably more pleasant.
The honest caveat
We have talked more clients out of migrations than into them. Cloud is not automatically cheaper, and for stable, predictable, high-utilisation workloads it frequently is not cheaper at all.
What it buys is elasticity and speed. If your workload is flat and your release cadence is quarterly, you may be paying a substantial premium for optionality you will never exercise. That is a legitimate answer, and it is one worth reaching before the migration rather than after.