The migration finished, the data centre contract ended, and the monthly bill exceeds what the hardware cost. This is a normal outcome of lift-and-shift, and it is not evidence the migration was wrong. It reflects a straightforward mismatch: cloud pricing rewards workloads that scale with demand, and a copied on-premise architecture does not.
01Owned hardware and rented capacity price differently
A purchased server has an up-front cost and then runs at any utilisation for no additional charge. Idle capacity is already paid for, so nobody optimises it. In the cloud that same idle capacity is billed hourly, and the habits formed around owned hardware become directly expensive.
On-premise sizing also assumes peak plus headroom, because adding capacity took weeks. Cloud instances sized the same way run at low average utilisation permanently, paying peak prices around the clock for capacity used a few hours a day.
| Habit from on-premise | Cloud consequence |
|---|---|
| Size for peak plus headroom | Paying peak capacity continuously |
| Environments left running | Billed hourly regardless of use |
| Local storage assumed free | Storage, IOPS and snapshots all billed |
| Internal network free | Cross-zone transfer charged |
| Backups to local disk | Snapshot storage accumulates |
| No per-team cost visibility | Nobody sees what they provision |
02Right-size against measured usage
Instances copied from on-premise specifications are typically far larger than needed. Measure actual CPU and memory utilisation over a representative fortnight and resize to fit observed peaks with sensible headroom rather than to match the previous hardware.
This is normally the largest single saving available and carries low risk, because it is reversible in minutes. Teams routinely find average utilisation in the low teens across their fleet, which means most of the spend produces nothing.
03Turn off what nobody uses
Non-production environments commonly run continuously while being used during working hours on weekdays - roughly a quarter of the week. Scheduling them off outside those hours removes most of their cost with no risk to production.
Orphaned resources are the other half: unattached volumes, idle load balancers, unassociated addresses and old snapshots. These accumulate through normal work and are invisible unless someone looks for them deliberately.
| Action | Effort | Typical return |
|---|---|---|
| Delete orphaned resources | Low | Small but immediate |
| Schedule non-production off-hours | Low | Large on those environments |
| Right-size instances | Low | Large |
| Storage lifecycle policies | Low | Grows over time |
| Commitments after stabilising | Medium | Significant on steady baseline |
| Re-architect for elasticity | High | Largest, but slowest |
04Commit only after usage is stable
Reserved capacity and savings plans offer meaningful discounts in exchange for committing to a level of usage over one or three years. Committing before right-sizing locks in the oversized footprint you were about to reduce, which is a common and expensive sequencing error.
Right-size first, observe the stable baseline, then commit to that baseline while leaving variable load on demand. Committing to peak rather than baseline removes the flexibility the commitment was meant to complement.
05The structural fix is visibility
Cost grows when no team sees the consequence of what it provisions. Tagging by team and service, with a monthly figure each team can see, changes provisioning behaviour more reliably than any centralised optimisation effort.
Without that, a cleanup buys perhaps six months before the same accumulation recurs, because the mechanism that produced it is untouched. The organisational change is what makes the technical work durable.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer