Savings work is easy to get wrong quietly
A downsized instance that is fine most of the month and falls over during the one weekly job that actually needs the headroom is a saving that shows up as an incident.
Cost
AWS spend reviewed and reduced, without adding operational risk.
Spend was rising faster than the customer base. The obvious moves — turning things off, downsizing instances — are also the ones most likely to cause an outage, which is why cost work done under pressure tends to get reversed under pressure.
← Some of our past work · anonymised prior delivery, no client named
Stack
AWS Compute OptimizerAmazon EC2Amazon RDSSavings PlansTerraform
Rough timeline
| Phase | Typical duration |
|---|---|
| Baseline and findings | 1–2 weeks |
| Agreed changes implemented | 2–4 weeks |
| Verification against the next bill | 1 billing cycle |
The challenge
Nobody had looked at sizing since launch.
Instances sized for a guess made a year or two earlier, never revisited as real usage patterns emerged.
Nobody could confidently say what was unused
Unused-looking resources that might be unused, or might be a dependency nobody had documented.
A cost review with no process behind it does not stay fixed
The estate would simply drift back to the same shape without a repeatable way to make and keep the changes.
What we found
Sizing that ignored its own recommendation engine, and cost that was invisible until itemised.
Sizing did not match Compute Optimizer’s own recommendations
A number of instances several sizes larger than their measured utilisation justified, unchanged since they were provisioned.
Storage had accumulated without lifecycle rules
EBS volumes attached to nothing, and S3 buckets with no lifecycle policy ageing data into a cheaper storage class or removing it.
Steady load sat entirely on-demand
Workloads with a flat, well-understood baseline running with no commitment discount applied to the part of the load that was not going to change.
Data transfer costs were invisible until itemised
NAT gateway and cross-AZ transfer charges that nobody had attributed to a specific cause, because the billing console does not make the cause obvious.
What InfraEdge changed
Right-sized against evidence, and every change made reversible.
Nothing here was turned off by hand under time pressure. Every change went through the same pull-request-and-plan process as any other infrastructure change.
| Change | What it did |
|---|---|
| Right-sizing implemented | Instances resized against Compute Optimizer’s recommendations and real utilisation, applied through Terraform. |
| Storage cleaned up | Unattached EBS volumes removed; S3 lifecycle rules added to move ageing data to cheaper storage classes or delete it on a stated schedule. |
| Commitment discounts applied | A Compute Savings Plan sized against the steady-state baseline, leaving genuinely variable load on-demand rather than over-committing. |
| Data transfer reviewed | VPC endpoints added where traffic was crossing the NAT gateway unnecessarily; cross-AZ patterns reviewed for the cases actually worth changing. |
| Environment usage reviewed | Non-production environments checked against how much they were actually used, with clear owners for anything left running. |
Outcome
A measurable reduction, and a documented, reversible reason for each change.
We are not going to quote a saving figure here — it depends on the estate, the pricing agreements already in place, and the billing cycle it is measured against.
The discipline is the same regardless of the number: size against evidence, commit against a baseline you actually have, and make every change reviewable, so it stays fixed instead of drifting back the way it came.
Book a 20-minute triage call
Twenty minutes, no charge. We work out what would actually help — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.