Cloud Waste in UK DevOps: The 29% You Pay For and Never Use

Roughly three in ten pounds of your cloud spend buys nothing. The cause is in your pipelines and not in your billing console. The industry has spent five years fixing the billing layer while the delivery layer kept generating the bill. 

Cloud waste has been falling since 2022. Then it reversed. It reversed during the same period that FinOps adoption hit record levels and cloud centres of excellence became standard. More people are watching the bill than ever before, and the bill is getting worse.

Below are the seven delivery failures that manufacture waste, four cost multipliers specific to UK organisations, and a four-week diagnostic you can run without buying anything. 

Cloud Waste Statistics 2026: How Much Cloud Spend Is Wasted

Cloud waste is spent on provisioned capacity that carries no workload, or on capacity materially larger than the workload requires. It is not the same as overspending against the budget. An accurate budget can be fully spent and still be a third waste. 

Flexera surveyed 753 cloud decision-makers for its 2026 report. Estimated waste on infrastructure and platform services came in at 29%. 

Waste peaked at 32% in 2022, fell to 28% in 2023, then held flat at 27% through 2024 and 2025.  Flexera attributes the reversal to cost complexity from AI workloads and newer service types.

Effort is not the problem. The same report found 85% of organisations naming cloud spend management as a top challenge, the third year running. IDC’s Cloud Pulse survey found close to half of cloud buyers overspent against expectations in 2023, and 59% expected the same again the year after. 

The UK public sector gives the clearest local figure. The National Audit Office reported annual government spending on digital programmes and technology at £14bn or more. Separately, across five digital change programmes, costs rose by over £3bn, a 26% overrun, to reset those programmes and keep legacy systems running longer than planned. The NAO put the resulting delay at 29 years of lost modernisation. That is the price of delivery systems that could not deliver.

Most global cloud waste totals quoted in billions are the Flexera percentage multiplied by a market forecast. Don’t treat them as evidence.

Why FinOps Dashboards Do Not Reduce Cloud Waste

A cost dashboard tells you an instance is idle. It cannot tell you why your teams keep creating idle instances.

The 2025 DORA report explains the mechanism. It drew on responses from nearly 5,000 technology professionals. AI adoption correlates with higher delivery throughput. It also correlates with higher instability, more change failures, more rework and longer resolution times.

Rework is waste with a compute bill attached. Every failed change burns build minutes, test environments and engineer attention. Then it burns them again.

The same research found that the platform decides the outcome. AI amplifies what a team already is. Strong platforms get stronger. Inconsistent ones have their existing dysfunctions magnified. With 90% of organisations now using AI in software development, the gap between those two groups is widening quickly.

A weak delivery system increases the rate at which you generate waste. Our comparison of platform engineering versus traditional cloud delivery covers what separates the two models in practice.

What Causes Cloud Waste? Eight DevOps Failures That Inflate Your Bill

None of these looks like waste at the time. Each is a reasonable decision taken under a deadline. All eight bill monthly, indefinitely.

1. Environments that never sleep. Staging, UAT, demo, and the one spun up for a client pilot two years ago. A workload that needs 40 hours a week runs for 168. The cause is a pipeline that cannot create and destroy environments on demand, so teams keep permanent ones instead.
2. Rework loops. The same change ships three times because the first two broke. Deployments per merged change is the metric that exposes it, and almost nobody tracks it.
3. Drift and orphaned resources. Resources created by hand during an incident, never added to any state file, owned by nobody who still works there. They survive because deleting them requires proving they are unused, and nobody can.
4. Over-provisioning instead of observability. Instances are sized for a peak that may never arrive because nobody can see real utilisation. Capacity buys confidence. Measurement buys the same confidence for less.
5. Idle accelerators. GPU capacity reserved for a training run that finished, or an inference endpoint sized for a launch that never scaled. Statically provisioned GPU fleets commonly run well below half utilisation, and the hourly rate makes an idle accelerator the most expensive unused resource in the estate. This is the newest mechanism on the list and the one least likely to be covered by the existing tagging policy. 
6. Accidental egress. Services chatting across availability zones. Cross-region replication left from a disaster recovery design that nobody has revisited. Observability pipelines are shipping every log line out of the network. None of it appears on an architecture diagram.
7. Licence-driven architecture. The workload belongs on one platform. The licence makes another cheaper. The licence usually wins, and the architecture inherits a constraint that outlives the contract that caused it.
8. Duplicate platforms. Two toolchains, two estates, one product. Common after acquisitions, and after repatriation projects that never switched off the original.

Individually, each is a configuration fix that a competent engineer clears within a week. They rarely arrive individually because they share a cause. Nobody owns the delivery system as a system. That is why one-off clean-ups decay within a quarter, and why the same findings reappear in next year’s audit.

One item here is money already on the table. Flexera found that fewer than half of organisations use any single commitment discount per provider. It is the cheapest saving available and the one most likely to backfire, because a commitment fixes whatever you are running on the day you sign. Do the other six first. 

The Hidden Cost of Cloud Waste: Engineering Time You Already Paid For

The compute you pay for is the smaller number. The larger one is salaried.

Count what your engineers wait for. Builds. Flaky tests. A free environment. Reproducing an incident on a machine that will not reproduce it. Every one of those hours is capacity you have already bought and did not receive.

It never surfaces in a cost review because it arrives as payroll.

Model it directly:

Engineers affected × hours lost per person each week × working weeks per year × fully loaded hourly cost

Worked at a plausible UK scale: 40 engineers, 6 hours lost each per week, 46 working weeks, £75 fully loaded hourly cost. That is £828,000 a year. Run it with your own headcount and rates, then compare it against the cloud bill for the same teams. For most organisations, the comparison is uncomfortable, which is precisely why it is worth doing before someone else does it for you.

This is also the version of the argument that survives a board meeting. Cost programmes framed as a percentage off the cloud bill compete against every other cost programme. Framed as recovered engineering capacity, the same work competes for the growth budget instead.

Four UK-Specific Cloud Cost Multipliers

Licensing and a closing window of leverage. The Competition and Markets Authority found that AWS and Microsoft each hold up to 40% of the UK cloud market by value. On 31 March 2026, it closed the cloud services investigation without designating either provider, accepting voluntary commitments on egress fees and interoperability instead. The CMA Board reviews progress on those commitments six months on, which places the next checkpoint in the current quarter.  

On 14 May 2026, the CMA opened a strategic market status investigation into Microsoft’s business software ecosystem, examining whether licensing for products such as Windows Server and SQL Server makes hosting on rival platforms more expensive or harder. A designation decision is due by mid-February 2027. Until then, treat any multi-year renewal as provisional and insist on portability and exit terms.

Sources: CMA case page for Microsoft’s business software ecosystem and Microsoft’s Windows Server 2016 lifecycle page. 

The 2027 deadline. Windows Server 2016 leaves extended support on 12 January 2027. Broadcom’s VMware changes have reset renewal quotes across the UK market. Both pull migration timelines forward, and deadline pressure is the worst condition in which to build a delivery platform. Decisions taken to hit a date become the permanent environments and undocumented resources described above.

Sovereignty and duplication. Research commissioned by Pulsant and run by Vanson Bourne, 250 UK respondents, found 87% planning to move some or all workloads off the public cloud within two years. Vendor-commissioned and small, so treat it as direction rather than a market census.  The waste is specific and avoidable. Firms build the destination, then hesitate to switch off the source in case something depends on it. Two estates run in parallel for eighteen months, and the decommissioning work never gets a budget line.

Platforms nobody documented. IR35 reshaped how UK firms staff build phases, pushing much of the work through contractors. The platforms remain. The people who understood them do not. This is why so many resources survive audits: deleting them requires knowledge that is left with the contract, so they are renewed by default.

How to Calculate Your Cloud Waste Rate: A Four-Week Audit

Four checks take a day each. The fifth sets the timetable.

Week One: From Data You Already Hold

1. Tag coverage. What share of spend maps to a named service and a named owner? Anything unattributed is unmanaged by definition.
2. Idle ratio. Weekend spend as a proportion of weekday spend, per environment. A ratio near 1.0 on a non-production environment is a permanent environment doing part-time work.
3. Drift audit. Run a plan against live infrastructure and count what appears. Every difference is a resource nobody can safely delete.
4. Commitment coverage. What share of a genuinely steady workload sits on a discount? Note “genuinely steady” because committing to the rest is the trap covered above.

Weeks Two to Four: Measured Live

5. Delivery friction. One sprint of tracked waiting time on builds, environments and reproduction. This is the only number that requires elapsed time, and the only one that puts a figure on the salaried waste.

These are working thresholds, not published benchmarks. They tell you which of the five results deserves attention first.

Commitment coverage is the one where a high number is also a warning. Above 90% means you have committed to a capacity you have not yet proven is steady.

The output is a baseline you can move and a number for the next cost conversation instead of an opinion.

How to Reduce Cloud Costs in the Right Order

The right order is visibility, ownership, ephemerality, then commitments. Each stage makes the next one possible.

Visibility tells you what you are running. Ownership makes someone accountable for it. Ephemerality means that the things nobody needs stop existing on their own. Only after those three does a commitment discount attach to a number worth committing to.

Most programmes run it backwards. Reserved capacity comes first because the savings are immediate and report well. It also fixes current consumption in place for up to three years, waste included. You have bought a discount on resources you should have deleted and signed away the option to delete them.

The order matters more than the tooling because each stage is cheap once the previous one is done, and expensive when it is not. Deleting an untagged resource nobody owns requires an investigation. Deleting a tagged resource with a named owner requires an email.

None of it holds without maintenance. Tag coverage decays, ownership follows people out of the door, and environments accumulate again. That is the argument for ongoing cloud management: the sequence works, but only while someone keeps it running.

Remediate or Rebuild? Three Questions to Decide

Can the platform be described in code today? 

Not perfectly, and not everything. Enough that a new engineer could rebuild the bulk of it from the repository. If the answer is no, remediation means reverse-engineering production before you can change it safely, and that discovery work is usually the largest line in the estimate.

Is there a single accountable owner? 

One person or one team can approve a deletion. Without that, every fix stalls at the same question of who is allowed to say yes, and improvements decay as soon as the project ends.

Is your change failure rate flat or falling? 

Rising failure rates mean the platform is degrading faster than you are fixing it. Remediation under those conditions is a treadmill.

Two yes answers mean the foundations hold, and the problems are on top of them. Remediate.

Fewer than two means the archaeology will cost more than the rebuild. The exception is a hard external deadline, in which case remediate what you must and plan the rebuild for after it.

How to Start Reducing Cloud Waste This Quarter

If three or more of the eight mechanisms above sound familiar, your waste is structural. Another dashboard will not shift it.

Start with the diagnostic. It costs you nothing but attention, and it gives you a defensible number instead of an assumption.

What Remediation Looks Like in Practice

Little Journey, a paediatric eSupport platform, was creating environments ad hoc, slowly and without consistent controls. Deployflow rebuilt environment provisioning on Terraform, with each environment carrying its own security controls and full data segregation.

• Provisioning time for a new environment fell from several days to two hours
• 80% reduction in deployment time overall
• 70% less manual work, with compliance evidence produced by the platform rather than by people

Hall Hunter, a UK berry grower supplying the major supermarkets, was running an ageing on-premises estate with patchy documentation and several suppliers each holding a piece of it. We consolidated onto a single cloud platform and rebuilt the documentation and ownership alongside it.

• Around a 30% reduction in IT costs, delivered on time and within budget
• 150+ staff moved onto stable services, with support tickets down
• Documentation and ownership were established for an estate that previously had neither

In both cases, the savings followed a change in how infrastructure was created and owned. Neither started with a cost tool.

How to Stop Cloud Waste From Coming Back

Most teams can find the waste. Fewer can stop it from returning. That is the case for DevOps managed services. The goal is a platform where cost discipline is a by-product of how software ships, not a quarterly clean-up. The 2026 DevOps guide for UK businesses covers the operating model in detail.

Book a free call. It is enough to size your likely waste rate and locate it before you spend anything. Do it this quarter. Every renewal signed ahead of the CMA decision and every migration rushed at the January deadline lock in today’s costs for years. 

Cloud Waste in UK DevOps: Frequently Asked Questions