The 2026 Cloud Cost Reckoning: Where the Waste Hides and How to Get It Back

Ask a finance director what their cloud spend buys and you will usually get a number rather than an answer. That is not a criticism of finance. It is a structural property of how cloud infrastructure gets provisioned: a great many small, individually sensible decisions, made by different people over several years, none of which were ever revisited, aggregating into a single monthly figure that nobody can decompose.

When we audit an estate that has never been through a cost exercise, we typically find between thirty and fifty percent of the bill is recoverable without touching reliability, performance, or the ability of the team to ship. That range has been remarkably stable across engagements. It is not caused by incompetence. It is caused by an asymmetry in incentives that every engineer will recognise immediately.

Under provisioning causes an incident at three in the morning, a customer complaint, and a difficult conversation. Over provisioning causes a slightly larger invoice that arrives in a department nobody in engineering reports to. Faced with that asymmetry, every reasonable person rounds up. Multiply that reasonable caution across every service, every environment, and every engineer, sustained for three years, and you get a bill containing a great deal of insurance that nobody has ever claimed on.

Where the money actually is

Cloud waste is not evenly distributed. It concentrates in a handful of places, and in almost every audit we run, the same categories account for the overwhelming majority of the recoverable spend.

Non production environments running around the clock

This is consistently the largest single win and the easiest to take. Development, staging, testing, and demo environments typically run continuously for a team that works roughly forty hours a week across one or two time zones. That is around seventy five percent idle time on infrastructure that is frequently sized to mirror production.

Scheduled shutdown outside working hours takes an afternoon to implement and pays back permanently. The objection is always that someone might need the environment at an unusual hour, which is solved by a self service button that starts it again, not by leaving everything running forever. In estates where non production is a meaningful share of the total, this single change routinely recovers fifteen to twenty percent of the whole bill.

Compute sized for a peak that never arrived

Instance sizes are chosen at launch, based on an estimate, under uncertainty, and then never revisited. We routinely find production databases and application servers running at single digit average utilisation with a peak that never exceeds a quarter of capacity. The original decision was reasonable. Nobody scheduled the review.

Right sizing from measured utilisation, with headroom for genuine peaks rather than imagined ones, is straightforward once someone owns it. The important discipline is measuring over a period long enough to include the real cycles: month end, seasonal peaks, and the batch job that runs on the last Friday of the quarter.

Storage that accumulates because deletion is nobody's job

Snapshots from a migration in 2023. Volumes detached from instances that were terminated long ago. Log data on high performance storage that nobody has queried since the week it was written. Object storage in the hot tier holding archives that are read once a year, if ever.

Individually these are small and that is exactly why they persist. Nobody is going to open a ticket about eighty dollars a month. Collectively, across three years of accumulation, they are frequently five to ten percent of the bill. Lifecycle policies that move data down through storage tiers automatically fix this permanently and remove the need for anyone to remember.

Data transfer, the line nobody reads

Egress and cross zone traffic is the category that most often produces genuine surprise, because it is architectural rather than a resource anyone provisioned. A chatty service pair split across availability zones for redundancy pays a transfer charge on every call. A media heavy application serving directly from object storage rather than through a content delivery network pays full egress on every byte.

These are not fixed by turning something off. They are fixed by placement decisions and by putting a cache in front of the right thing, which is why they need someone who reads the architecture rather than only the billing console.

On demand rates on entirely predictable workloads

Most estates have a stable baseline that has been running for years and will keep running for years, paying the flexible rate for the privilege of a flexibility nobody is exercising. Committed use discounts against that baseline are free money in the most literal sense: no engineering, no risk to reliability, just a purchasing decision somebody has to be authorised to make.

The reason it goes unclaimed is rarely ignorance. It is that committing requires a forecast, a budget approval, and a person willing to be accountable if usage drops. That is an organisational problem wearing a technical costume, and it is solved by giving someone the authority rather than by more analysis.

The sequence that works

Order matters here, because credibility is the scarce resource. A cost programme that starts with a controversial architectural change and causes an incident is over. One that starts by removing obviously idle resources builds the trust required to do the harder work later.

1. 01Attribute before you optimise. Tagging discipline first, so every resource has an owner, an environment, and a service. Without this you are guessing, and you cannot hand the practice over afterwards.
2. 02Delete the obvious. Unattached volumes, orphaned load balancers, ancient snapshots, environments belonging to projects that ended. Zero risk, immediate saving, and it demonstrates progress in week one.
3. 03Schedule non production. The single largest safe win in most estates.
4. 04Right size from measurement. Compute and databases, using real utilisation over a full cycle, with genuine headroom.
5. 05Apply lifecycle policies to storage. Automatic tiering means nobody has to remember.
6. 06Buy commitments against the proven baseline, once right sizing has settled so you are not committing to capacity you are about to remove.
7. 07Then the architectural work: autoscaling that actually scales down, transfer path redesign, and managed services replacing hand operated infrastructure.

Step one is the one teams want to skip and the one that determines whether any of this lasts. Without attribution you can run a cleanup, but you cannot hand the practice to the people who create the spend, and within eighteen months the bill returns to where it started. We have been called back to estates we optimised two years earlier for exactly this reason, and in every case the tagging discipline had lapsed first.

“The cleanup recovers the money once. The attribution is what stops you paying us to do it again in two years.”

Kubernetes deserves its own paragraph

Container platforms hide waste unusually well, because the cluster looks busy at the node level while the workloads inside it are barely using what they reserved. Resource requests get set once from a guess, usually generously, and the scheduler dutifully reserves that capacity whether or not anything uses it. A cluster running at eighty percent reserved and twelve percent actual utilisation is entirely normal and entirely invisible unless somebody goes looking.

The fix is requests tuned from observed usage rather than from caution, cluster autoscaling configured to remove nodes as well as add them, and spot capacity for workloads that tolerate interruption. Namespace level cost attribution makes the whole thing visible to the teams who set the numbers, which is the only durable fix. This is standard practice in any well run platform engineering practice and it is skipped remarkably often, because the cluster appears to be working and nothing forces the question.

Managed services: the calculation people get backwards

There is a persistent belief that running your own database on a virtual machine is cheaper than paying for the managed equivalent, and on the line item it usually is. The comparison is wrong because it counts only one side of the ledger.

A self operated database carries patching, backup verification, failover testing, version upgrades, monitoring setup, and the engineer hours consumed when any of those goes wrong at an inconvenient hour. Price those hours at what your engineers actually cost and the managed option is frequently cheaper in total, before you account for the incidents it prevents. We have moved clients onto managed services as a cost reduction and had the invoice go up while total spend went down, which is a conversation worth preparing finance for in advance.

The reverse also holds, and honesty requires stating it. At high sustained scale, on a workload your team genuinely understands, self operating can be materially cheaper and the operational burden is amortised across enough volume to justify it. The point is not that managed always wins. It is that the comparison has to include the engineering time, and it almost never does.

The same reasoning applies to serverless. Per request pricing looks expensive next to an always on instance until you account for the instance sitting idle most of the day, and it looks cheap right up until sustained high volume makes the always on option obviously better. Both models are correct for different traffic shapes, and the mistake is picking one as a philosophy rather than per workload.

The savings that are not worth taking

A credible cost programme has to be willing to leave money on the table, otherwise nobody will trust its recommendations. Several popular optimisations are worse than they look.

• Removing redundancy. Single zone deployment is cheaper right up until the zone has a bad day. If the business needs the availability, the cost is not waste, it is the price.
• Right sizing to the mean. Capacity has to cover the peak that matters, not the average. A database that is comfortable on Tuesday and falls over at month end has not been optimised, it has been broken slightly more cheaply.
• Migrating provider for headline pricing. The engineering effort almost always exceeds the saving, and the estate you arrive with is the same badly sized estate you left with.
• Consolidating everything onto fewer larger instances. It looks efficient and it enlarges the blast radius of any single failure.
• Deleting logs and traces to save on ingestion. Sample and set retention deliberately instead. The first serious incident you cannot diagnose will cost more than three years of log storage.

What an audit week actually involves

Because cost work has a reputation for being either a spreadsheet exercise or a vendor tool subscription, it is worth describing what a serious audit actually consists of. It is a week, it is mostly reading, and it produces a ranked list rather than a report.

The first two days are billing data. Not the console summary, the detailed usage export, joined to whatever tagging exists and grouped by service, environment, and account. This is where the shape of the estate becomes visible, and it is usually the first time anyone has seen it decomposed. Roughly half the eventual savings are identifiable from this alone.

The next two days are utilisation. Compute, memory, storage throughput, and connection counts over a period long enough to cover the real cycles. This is what separates a resource that is genuinely needed from one that was sized generously and never revisited, and it is the step that vendor tools handle least well because they lack the context to know which peaks matter.

The final day is architecture. Reading the topology to find the transfer paths, the redundancy that is buying nothing, and the hand operated infrastructure that a managed service would replace. These are the largest items on the list and the slowest to implement, which is exactly why they belong at the end of a sequence rather than the start.

The output is one table. Each row is a change, its projected monthly saving, the engineering effort required, and its risk to reliability. Sorted by return on effort. The client decides what to do, and the honest ones among those rows are the ones marked as not recommended despite a healthy saving, because the risk does not justify it.

Making it stick: the practice, not the project

The cleanup is the easy half. Everything above can be delivered in six to eight weeks by a competent team. What determines whether the bill is still healthy in two years is whether the organisation changed how it operates, and that requires four fairly modest things.

• Per team cost visibility, reported monthly, in a format the team can act on. Not a spreadsheet from finance, a dashboard filtered to their services.
• Budget alerts and anomaly detection at daily granularity. Finding out on the invoice is finding out three weeks late.
• Cost as a standing item in architecture review, at the same level as security and reliability rather than as an afterthought.
• A named owner. Not a committee. One person accountable for the number, with the authority to buy commitments and the standing to ask why a service doubled.

None of that is technically demanding. All of it is organisationally awkward, which is why it is the part most often quietly dropped. The technical work has a satisfying completion. The practice has to be maintained by people who have other priorities, and it survives only if somebody owns it explicitly.

The teams that hold onto their savings tend to be the ones where cost visibility was built into the delivery platform rather than bolted alongside it. When a service template provisions its own dashboards, its own alerts, and its own cost attribution at creation time, none of this requires anyone to remember. That is a platform engineering problem rather than a finance one, and solving it there is why some organisations never need a second cleanup.

What this looks like when the architecture is the problem

Sometimes the honest finding is that the estate cannot be optimised into health because it was never designed, only accumulated. A lifted and shifted data centre running on cloud virtual machines will always cost more than the hardware it replaced, because it uses none of the mechanisms that make cloud economics work: elasticity, managed services, and the ability to run nothing when nothing is needed.

In that situation the cost exercise recovers what it can and then the conversation has to change, because further savings require architectural work rather than tuning. We say this plainly when we find it, including the version where the honest recommendation is to leave a stable legacy workload exactly where it is and spend the effort somewhere with a better return.

The new line item: AI inference

Two years ago cloud cost meant compute, storage, and transfer. In a growing number of the estates we audit, model inference is now among the top three lines, and it behaves differently from everything around it in ways that catch teams out.

It scales with usage rather than with capacity, so there is no idle waste to reclaim and no instance to right size. It has no committed use discount in the conventional sense. And its cost per unit of work can vary by a factor of thirty depending on how a prompt is constructed, which means the optimisation levers sit in application code rather than in infrastructure configuration.

The practices that control it are their own discipline, covered properly in our writing on generative AI economics, but the FinOps principles transfer directly. Attribute spend per feature and per tenant. Set budget ceilings that halt runaway work rather than letting it continue. Alert daily rather than monthly. And treat cost per completed task as the metric, because cost per token tells you nothing about whether the feature makes commercial sense.

One structural warning. Inference spend frequently sits outside the tagging scheme entirely, because it arrives through a separate vendor invoice rather than through the cloud provider. Estates where that is true have a blind spot growing at the fastest rate of any line in the budget, and closing it is usually a morning of work with an outsized payoff.

The uncomfortable truth about cloud spend

The cloud providers are not overcharging you. Their pricing is public and their unit economics are competitive. The waste is on your side of the boundary, and it exists because provisioning is easy, deprovisioning is nobody's job, and the person who chooses an instance size faces no consequence for choosing generously.

Which is genuinely good news, because it means the money is recoverable by decisions you control rather than by negotiation with a vendor. The organisations that keep their cloud spend proportionate are not the ones with the cleverest architecture. They are the ones where an engineer can see what their service costs, and where somebody senior looks at that number often enough for it to matter.

Start with attribution, take the safe wins to build credibility, and only then touch the architecture. Do it in that order and the first savings appear on next month's invoice. Do it in the reverse order and you will have an incident, a suspicious finance team, and a programme that quietly stops.