Talk to us
WhatsApp us

Free cloud cost review: we will find the waste in your AWS or Azure bill in 5 business days. Book it

Cloud & infrastructure

The AWS cost optimisation checklist we actually use

The twelve checks that account for most of the savings in a first AWS cost review, in the order we run them and with the risk attached to each.

  • Updated
  • 4 min read

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
Engineer reviewing an AWS cost breakdown on a monitor

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

Frequently asked questions

After, always. A commitment purchased against over-provisioned infrastructure locks in the waste for one to three years. Right-size first, let it settle for two to four weeks, then commit against the new baseline.

Stopping development and test environments outside working hours removes roughly 60–70% of their compute cost. Where non-production is a third of total spend — which is common — that is 15–20% off the whole bill for one automation.

For most containerised and managed-service workloads, yes: typically 20% better price-performance. The blocker is rarely technical — it is that nobody has tested it. Run your test suite on an ARM build before assuming it is a problem.

Keep reading