Why the bill rises after a lift and shift
A rehosted estate is usually more expensive than the business case assumed, and that is normal rather than a failure. The migration prioritised getting workloads across safely. Servers kept their old specifications, disks were copied as they were, both environments ran in parallel, and everything is billed at on-demand rates. The cost work comes next, and it is a planned stage of our cloud migration service, not a rescue.
If you run Kubernetes on the target platform, our guide to EKS cost optimisation covers the container-specific levers. This page covers the broader estate that a migration produces.
What good looks like
- Spend is attributable: every resource carries an owner, environment and cost centre tag.
- Instance sizes reflect observed use, with headroom chosen on purpose.
- Steady workloads are covered by commitments at a cautious level, and variable ones are not.
- Storage sits in the right tier for how often it is read.
- Leftovers from the migration are gone.
- Someone reviews the bill monthly and anomalies alert automatically.
Start with leftovers
The cheapest savings are things that serve no purpose. After a migration we routinely look for:
- Source-side replication resources, staging volumes and test instances that were never removed.
- Snapshots and images created during rehearsals.
- Unattached volumes and unused addresses.
- The old environment still billed in parallel, past the agreed run period. This is a planning point for the roadmap as well.
- Non-production environments running overnight and at weekends.
A short query shows the shape of the problem, for example unattached EBS volumes:
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[].{ID:VolumeId,SizeGiB:Size,Created:CreateTime,Tags:Tags}' \
--output table
Check ownership before deleting anything. A volume marked available may be a deliberate backup, so the report flags candidates and the owner decides.
Right-sizing from evidence
Sizing begins at the assessment but is refined here with real cloud data. We look at CPU, memory, disk and network over a period that includes the busy times, and compare against instance families. Tools such as AWS Compute Optimizer and Azure Advisor give a starting list. They are inputs, not instructions: they can recommend a smaller instance that would fail at month end, so we sanity-check against known peaks.
Changes are staged. Non-production first, then low-risk production, with monitoring and a way back. Newer instance generations often give the same performance for less, and storage volume types may be changed in place on some platforms.
Commitments, once you know your baseline
Commitment discounts trade flexibility for lower prices. Compute Savings Plans on AWS and reservations or savings plans on Azure reward steady usage. The order of operations matters: remove waste, right-size, then commit to a share of what remains. Committing first locks in spending on resources you are about to shrink.
| Approach | Good for | Risk |
|---|---|---|
| On demand | New, uncertain or short-lived workloads | Highest unit price |
| Savings Plan or reservation | Stable baseline usage | Paying for unused commitment if usage falls |
| Spot or low-priority capacity | Fault-tolerant batch, CI runners | Interruption |
We model commitment levels from at least a few weeks of stable data and recommend a level below the minimum observed usage. You can add more later, and it is much harder to give it back.
Storage, transfer and licences
Storage tiering follows access patterns, as set out in storage migration planning. Data transfer charges are the other classic surprise: traffic between regions or availability zones, outbound internet traffic and NAT gateway processing can be significant. Sometimes a design change, such as placing chatty components in the same zone or adding a VPC endpoint, removes a surprising share of it. Licences deserve a look too, particularly where bring-your-own licence terms or hybrid benefits could apply.
Governance so it stays fixed
An optimisation report is a snapshot. Without governance, cost drifts back. We set up budgets with alerts, anomaly detection, mandatory tags enforced through policy in the landing zone, and a monthly review with a short agenda. Cost estimates in pull requests, using a tool such as Infracost, let reviewers see the price of a change before it merges. For teams wanting continuing oversight, this overlaps with the cost reviews in our Managed DevOps service.
A worked example: ranking the report
Each recommendation in the report is scored on three simple axes: expected saving, effort and risk. Deleting a confirmed orphaned snapshot is high on certainty and trivial in effort, so it goes first. Shutting non-production environments overnight is moderate effort with low risk. Resizing a production database is the opposite, with real risk and a need for a maintenance window, so it waits until the cheaper wins are banked and monitoring has proven stable. Presenting the list in this order lets you stop at any point and still have taken the best actions available.
Decisions and trade-offs
Aggressive or cautious. Squeezing every instance saves most and risks incidents. We recommend a measured approach, accepting some headroom in exchange for reliability.
Commit or stay flexible. If you are likely to refactor or move workloads soon, a large commitment may be wrong. Shorter terms and compute-flexible plans reduce that risk.
When the effort is not worth it. A small bill with a few servers may not justify a detailed project. A quick pass on waste and tagging will capture most of the benefit.
Common failure modes
- Reservations bought on instances later resized.
- Recommendations applied without checking peak behaviour.
- No tag discipline, making savings impossible to attribute.
- Treating optimisation as a one-time event.
- Ignoring data transfer until the bill arrives.
Delivery and handover
The report ranks each action by estimated effect, effort and risk, using your actual billing data. We can apply the changes in code or hand them to your team with instructions. The monthly review and dashboards carry on into your operations runbook.
How to tell it is working
Cost per unit of business activity trends down or stays flat as the business grows. Unallocated spend approaches zero. Surprises are caught by alerts within days, not at month end. To have your post-migration spend reviewed, contact us.