A lift-and-shift migration produced a cloud bill 2.5 times the data-centre cost it replaced. What do you examine first and what is the fastest meaningful reduction?
Show the full answer Hide the answer
What is being tested
Whether you can diagnose cloud cost systematically, and whether you know which reductions are fast and which are projects.
Why this happens
On-premises, over-provisioning is a sunk cost — the hardware was bought and idle capacity is free. In the cloud it is a recurring cost. Moving a VM sized for the 2019 peak means paying hourly, forever, for capacity that was already paid for once.
Three compounding factors follow:
- Instances sized for peaks that no longer exist, running 24/7 at 8% utilisation.
- Data transfer charges for flows that were previously free — cross-availability-zone traffic on every request from a chatty application that never had to care, and egress for anything leaving.
- Storage provisioned at peak rather than consumed, with premium tiers chosen by default.
Where to look, in order
1. Utilisation against provisioned size. Almost always the largest and fastest win. Right-sizing against two weeks of real measurement typically removes 30–50% with no architectural change and minimal risk.
2. Non-production environments running out of hours. Development and test fleets running nights and weekends are pure waste. Scheduled shutdown is a configuration change and often removes 60–70% of non-production spend.
3. Data transfer. Look for a workload in a private subnet reading large volumes from object storage through a NAT gateway, which charges per gigabyte processed on traffic that never needed to leave the provider's network. Adding a private endpoint routinely removes a large fraction of an unexplained networking bill and is one of the highest-return, lowest-risk changes available. Then check for cross-zone chatter and cross-region calls introduced by careless placement.
4. Commitment discounts. Once sizes are stable, reserved or committed-use pricing removes a substantial percentage for workloads that will run for a year. Do this after right-sizing, or you commit to the wrong sizes.
5. Storage tiering. Snapshots retained indefinitely, orphaned volumes from terminated instances, logs with no retention policy, and premium storage where standard would do.
6. Orphans. Unattached volumes, idle load balancers, unused addresses, forgotten environments. Every large estate has them, and nobody can identify their owner without tags.
The fastest meaningful reduction
Right-sizing plus non-production scheduling. Both are configuration changes, both are reversible, and together they routinely halve the bill within weeks — before any architectural work begins.
What to do about the strategic framing
The bad bill discredits the migration politically even when the strategic reasons for it were sound. Get ahead of that: present the reduction plan with timeline and expected savings, and state plainly that lift-and-shift was a deliberate first step to move quickly, with optimisation as the planned second phase. Selective replatforming — right-sizing, appropriate storage tiers, managed services for the components that dominate operational time, and fixing the two or three data flows generating transfer charges — captures most of the benefit without refactoring everything.
What a strong answer adds
Naming what should have been done first: cost allocation tags from day one. Without them, none of this analysis can attribute spend to a team or a workload, and every conversation becomes an argument about whose costs these are. Retrofitting attribution across thousands of untagged resources is a project nobody funds.