The short answer
The largest AWS savings almost always come from four places: right-sizing over-provisioned compute, shutting down non-production environments outside working hours, deleting unattached storage and stale snapshots, and buying Savings Plans against a measured steady-state baseline. Together these typically account for 25–35% of a first-time optimisation.
Key takeaways
- Right-size against 30 days of real utilisation, never against the original spec
- Non-production schedules alone typically remove 15–20% of non-prod spend
- Buy commitments only after right-sizing, or you commit to the waste
- Tag enforcement is what stops the savings eroding again
Every first AWS cost review we run turns up the same findings in roughly the same proportions. This is the checklist, in the order we work it — cheapest and least risky first, because early wins buy the political capital for the structural work.
Before you change anything
Turn on Cost Explorer with hourly granularity and enable AWS Compute Optimizer. Both need time to accumulate data, and right-sizing against fewer than 14 days of utilisation produces recommendations you will regret. Two weeks is the minimum; 30 days is better, because it catches month-end batch load.
1. Delete what nobody owns
Unattached EBS volumes, snapshots older than your retention policy, unassociated Elastic IPs, idle load balancers, old AMIs. This is pure waste with no performance implication. In a mid-sized estate it is usually 3–6% of the bill and carries essentially no risk.
2. Schedule non-production
Development, test and staging environments running 24/7 for a team that works roughly 40 hours a week are paying for about 128 unused hours every week. An instance scheduler that stops them evenings and weekends removes 60–70% of non-production compute cost. This is usually the single largest quick win, and the objection to it — "someone might need it at 9pm" — is answered with a self-service start button.
3. Right-size compute
Take Compute Optimizer recommendations, but do not apply them blindly. Look at the p99 of CPU and memory, not the mean, and keep headroom for the peaks that matter. We generally take the recommendation one size more conservative than the tool suggests on production, and exactly as suggested on non-production.
4. Modernise instance families
Moving from an older generation to current — or to Graviton where the workload supports ARM — commonly delivers 10–20% better price-performance for a change that is often just an instance type and a rebuild. Graviton is the single most underused lever in AWS, mostly because nobody has tested whether their workload runs on it. Most managed services and most containerised applications do.
5. Fix storage tiers
S3 objects sitting in Standard that have not been read in six months belong in Infrequent Access or Glacier. S3 Intelligent-Tiering handles this automatically for a small monitoring charge and is almost always worth it above a few terabytes. On EBS, gp2 volumes should be gp3 — same performance floor, roughly 20% cheaper, and the migration is online.
6. Look at data transfer
Cross-AZ traffic and NAT gateway processing charges are invisible on most cost dashboards until you go looking. A chatty service pair split across availability zones can quietly cost more than the instances running it. Co-locating them, or replacing a NAT gateway path with a VPC endpoint for S3 and DynamoDB, often removes the line entirely.
7. Audit your databases
RDS instances provisioned for a launch that never came, Multi-AZ on a development database, provisioned IOPS nobody measured the need for. Aurora Serverless v2 is worth evaluating for genuinely variable workloads, though it is more expensive than provisioned for steady load — the marketing tends to skip that part.
8. Review log retention
CloudWatch Logs with no retention policy retain forever, at Standard pricing. Setting sensible retention and exporting long-term logs to S3 is a five-minute change that has removed five-figure annual costs in estates we have reviewed.
9. Only now, buy commitments
Savings Plans and Reserved Instances are how you capture 20–40% off the remaining compute — but only after right-sizing. Commit before you optimise and you have locked in the waste for one to three years. Cover the steady-state baseline, not the peak: we typically target 70–80% coverage and leave the rest on-demand for elasticity.
10. Enforce tagging
Without tags you cannot attribute cost to a team or product, and unattributed cost is nobody’s problem. Enforce a minimal tag set — owner, environment, product, cost-centre — through service control policies so untagged resources cannot be created at all.
11. Set budgets and anomaly detection
Budget alerts per account and AWS Cost Anomaly Detection on the whole estate. The value is time: catching an accidental deployment on day one instead of at month-end is the difference between a rounding error and a difficult conversation.
12. Put a monthly review in the calendar
Cost drifts back. A 30-minute monthly review with the engineers who provision resources — not just finance — is what keeps it from happening. Cost is an engineering decision; treating it as a procurement exercise is why it recurs.
What this adds up to
The total depends entirely on the estate. An environment that has never been reviewed usually has a great deal of headroom across most of these twelve items; one with an established FinOps practice will have already taken the top few and the remaining ceiling is lower. Work the list in order and you will know within a fortnight which of the two you are.
Everything in this guide
- AWS or Azure: how to actually make the decision The feature comparison is not the decision. Identity, licensing and the experience already in your team…