The bill goes up. That is the normal outcome.
A data centre has no meter. The servers were bought three years ago, the capital is sunk, and nobody is charged for the sixteen hours a day those machines sit near idle. Move the same workloads to a cloud and a meter goes on all of it. Nothing became less efficient during the migration — the inefficiency that was always there became visible and billable for the first time.
On top of that, a lift-and-shift copies the on-premise sizing. Those sizes were chosen for peak load three years into the future, with headroom on top, because adding memory to a rack meant a purchase order and a maintenance window. In a cloud that logic inverts completely — you can resize in minutes — but the sizing came across anyway, because the migration plan was about moving things safely, not about rethinking them.
So a higher bill is not evidence of a failed migration. It is evidence of an unfinished one. The optimisation work was always part of the project; it got scheduled after go-live, and after go-live the team was busy.
What the numbers say
Flexera's 2026 State of the Cloud Report, based on 753 cloud decision-makers surveyed in winter 2025, puts wasted cloud spend at 29% of IaaS and PaaS spend. Seventeen per cent of respondents exceeded their public cloud budget over the previous year, and cost is the top cloud challenge at 85%, ahead of security at 82%.
Two things are worth drawing out. First, 29% is what organisations admit to, which makes it a floor rather than an estimate. Second, that figure went up after five consecutive years of improvement — the discipline did not get worse, but AI workloads arrived faster than the cost controls around them.
The line items that did not exist on-premise
These are the ones that genuinely surprise people, because there was no equivalent to budget against. Nobody had a line for them last year.
| Charge | What it was on-premise | Why it grows quietly |
|---|---|---|
| Data transfer cross-AZ, egress, inter-region | Free. Moving a terabyte between two racks cost nothing | A chatty application that was fine in one building now pays per gigabyte to talk to itself across availability zones |
| NAT gateway data processing | No equivalent | Billed per hour and per gigabyte processed, separately from the transfer charge itself |
| Observability ingest | Logs wrote to a local disk you already owned | Per-GB ingest plus per-GB retention. Debug logging left on in production is a recurring cause |
| Snapshots and backups | Tape, or a fixed array you had already paid for | Trivial to create, nothing prompts a review, and the storage line grows month over month |
| Managed service premium | A person who ran the database | Costs more per unit than self-managing — frequently worth it, but it should be a decision rather than a default |
A managed NAT gateway charges an hourly rate and a per-gigabyte data processing fee that sits on top of normal data transfer costs. Traffic from a private subnet to object storage routed through it pays that fee on every gigabyte — and a gateway endpoint for object storage removes the charge entirely, but is not configured by default. Corey Quinn's write-up is the standard reference for the mechanics, though his figures date from 2021, so take the mechanism from it and the current rate from your provider's pricing page. In estates moving serious volume this single item has been known to dominate the networking bill.
What nobody switched off
The second category is simpler and usually larger: things that run continuously because on-premise there was no reason to stop them.
- → Dev, test, staging and UAT at full size, every night and all weekend
- → A working week is roughly a quarter of the hours in a week. The rest is paid for and unused
- → The fix is a schedule that stops and starts them — a scheduled job, not a project
- → For most teams this is the single largest saving available in week one
- → Unattached volumes left behind when instances were replaced
- → Reserved IP addresses associated with nothing
- → Load balancers with no healthy targets behind them
- → Old machine images and snapshots nobody will ever restore, kept because deleting feels riskier than paying
Disaster recovery running hot
This one deserves its own paragraph because it is expensive and rarely questioned. A warm standby environment, sized identically to production, running continuously, supporting a recovery time objective that has never been tested — and in many cases never agreed with the business in writing.
Pilot-light and warm-standby patterns exist precisely so that you can meet a stated RTO without paying for a second production estate. The engineering question is cheap to answer. The question that actually needs asking is what recovery time the business genuinely requires for each application, because "everything must fail over in minutes" is usually an assumption rather than a requirement, and it is the most expensive assumption on this page. Tiering applications by real RTO, then matching each tier to the cheapest pattern that meets it, is where the saving lives.
Licences that moved badly
Flexera puts software licence management third on the challenge list at 78%, and migration is exactly where it bites. Windows Server, SQL Server, Oracle and commercial middleware all price differently depending on whether you bring an existing licence or buy an instance with the licence included — and the rules for counting cores and vCPUs on cloud hosts are not the rules that applied to your own hardware.
Two failure modes are common, and they are opposites. A team lifts and shifts onto licence-included instances while holding perpetual licences they were entitled to bring, and pays twice. Or a team brings licences across that turn out not to be portable under the terms of their agreement, and finds out during an audit. Neither is an engineering problem. Both need someone to read the agreement before the migration, and the person who can do that is in procurement.
Commitments, and the trap in them
Reserved instances, savings plans and committed-use discounts are real money — Flexera found fewer than half of organisations use even a single commitment discount type with any provider, which is a large amount left on the table.
But the sequencing matters more than the discount, and most teams get it backwards. Buying a one or three-year commitment against a freshly lifted-and-shifted footprint locks in the wrong shape. You are committing to the over-provisioned, never-right-sized version of the estate. Then right-sizing happens, usage drops below the commitment, and the team discovers that the saving they bought is now partly unused capacity they are contractually obliged to pay for — which in practice means right-sizing gets quietly abandoned to protect the commitment.
Commit after right-sizing, not before. Run the resized estate for at least a month, find the floor you are confident will still be there next quarter, and commit to that floor rather than to the peak. A smaller commitment with high utilisation beats a larger one you cannot fill, and it leaves you free to keep optimising rather than defending a contract.
The order to do this in
Sequence is most of the value here. Each step makes the next one measurable, and doing them out of order wastes the ones that follow.
Containerised and AI workloads have their own lanes on top of this. For clusters, the levers are different enough to warrant their own treatment — see Kubernetes cost optimisation. For GPU-backed workloads, where utilisation matters far more than the hourly rate, see running AI workloads in the cloud.
A bill nobody owns is a bill nobody reduces
Everything above is a one-off clean-up, and a one-off clean-up decays. Estates that were optimised in March are back where they started by September, because the conditions that produced the waste were never changed.
Three things make it stick, and none of them are technical. Tagging enforced at creation rather than retro-fitted later, so every resource has an owner from the moment it exists. Showback by team, so the number lands in front of the people who can actually change it, rather than only in front of finance. And one named owner for the total, because a shared responsibility for the cloud bill reliably becomes nobody's.
The first ninety days
See the bill properly
Cost broken down by service, by environment and by team — which usually means fixing tagging before any of it is answerable. Identify your five largest line items. The answer is often not compute, and that surprise is the point of the exercise.
Days 1–15Delete and schedule
Steps one and two from the list above. Low risk, fast, and they fund the rest of the programme politically — a visible drop on the next invoice buys the attention needed for the harder changes.
Days 16–30Right-size and re-wire
Resize against observed utilisation, add gateway endpoints, tier storage, cut log volume, and have the disaster recovery conversation with the business. This is the bulk of the engineering work and where the durable saving is.
Days 31–70Commit, and make it stick
Buy commitments against the now-stable floor. Put showback in place, set a monthly review with a named owner, and add a budget alert that fires on anomaly rather than on month-end, by which point the money is already spent.
Days 71–90Frequently asked questions
Bill Higher Than the Data Centre You Left?
We run post-migration cost reviews on AWS and Azure estates — the breakdown first, then the list in order, with the savings attributed so you can see what each change actually returned. Book a free 30-minute call with our cloud team. NDA first, no obligation.