The 12-point AWS cost checklist we run in the first fortnight.

Every AWS cost engagement we start looks different and produces roughly the same list. This is that list, in the order we work through it, with what goes wrong at each step.

A caveat worth stating up front: the percentages below overlap. Rightsizing reduces the base that commitments then apply to. You cannot add them up and expect the total.

Phase one — things with no architectural risk

Do all of these before touching anything that could affect availability. They buy the credibility for the harder conversations later.

1. Orphaned and idle resources

Unattached EBS volumes, unassociated Elastic IPs, idle load balancers, old snapshots, NAT gateways in subnets nothing uses any more. Every estate has these; most have more than anyone expects.

The trap: deleting a snapshot that turns out to be the only copy of something. Check retention obligations before, not after — in regulated sectors this is not recoverable.

2. Non-production running out of hours

Development and test environments running 168 hours a week to serve about 45. Scheduled shutdown typically saves 60–70% of non-production compute.

The trap: a schedule that engineers work around because the restart is slow or unreliable. Make it fast and self-serve or it will be disabled within a month — and you will not be told.

3. Forgotten environments

Distinct from the above: whole environments cloned for a migration test, a proof of concept or an acquisition and never torn down. We have found several running production-sized infrastructure for over a year.

The trap: assuming nobody is using it. Check CloudTrail and flow logs for thirty days first. Occasionally something quietly depends on it.

4. Log and metric retention

CloudWatch Logs retention set to Never Expire is the default failure mode. Debug logs from 2019 cost real money. So do high-cardinality custom metrics nobody queries.

The trap: your retention obligation is probably shorter than you think for application logs and longer than you think for audit logs. They are different policies and should be different log groups.

Phase two — rightsizing

5. Compute rightsizing

Against p95 over at least thirty days, not against the peak from a load test eighteen months ago. Include memory, which Compute Optimizer needs the agent to see and which is the binding constraint more often than CPU.

The trap: rightsizing something that is over-provisioned for a reason — a quarterly batch run, a failover capacity requirement, a licensing constraint tied to core count. Ask before you resize.

6. Graviton migration

Typically 20–40% better price-performance on supported workloads. Managed services — RDS, ElastiCache, OpenSearch — are often a configuration change rather than a project.

The trap: assuming your container images are multi-arch. Check the build pipeline first, and check any vendored binaries and agents.

7. Storage tiering

S3 Intelligent-Tiering where access is unpredictable, explicit lifecycle policies where it is not. EBS gp2 to gp3 is almost always worth it and is a live change.

The trap: Intelligent-Tiering has a per-object monitoring charge. On buckets with hundreds of millions of small objects it can cost more than it saves. Model it.

8. Database rightsizing and modernisation

Over-provisioned RDS instances, Multi-AZ on environments that do not need it, and self-managed databases on EC2 that would be cheaper and safer as managed services.

The trap: removing Multi-AZ from something the business believes is highly available. That is an availability decision, not a cost decision, and it needs the business to make it in writing.

Phase three — commitments

Only now. This is the step most organisations do first, and it is why so many are still paying for a baseline they no longer run.

9. Savings Plans and Reserved Instances

Target 75–85% coverage of steady-state usage. Compute Savings Plans for flexibility, EC2 Instance Savings Plans where the workload is genuinely stable, reservations for RDS, ElastiCache and OpenSearch.

The trap: the expiry cliff. Buying everything at once means renewing everything at once, which hands your future self a single high-stakes decision. Ladder purchases across quarters.

Phase four — architecture and measurement

10. Data transfer and NAT

Cross-AZ chatter between services that could be zone-aware, NAT gateway egress that should be a VPC endpoint, and inter-region replication nobody has reviewed since it was configured.

The trap: making services zone-aware in a way that reduces resilience. There is a genuine trade-off here and it should be a deliberate decision.

11. Observability spend

Frequently 5–10% of a total bill and rarely examined by anyone. Log ingestion, metric cardinality, trace sampling rates, and third-party platform pricing that scales on a dimension you are not watching.

The trap: cutting sampling to a level where you can no longer investigate an incident. Reduce retention before you reduce fidelity.

12. Attribution — which should really be first

We list it last because it is where most people stop reading, and first in every engagement we actually run. Enforced tag policy, account structure aligned to the business, showback to engineering leads, anomaly detection routed to the team that caused it.

Items 1 through 11 are a one-off saving. Item 12 is what stops you needing them again in eighteen months.

On percentage-of-savings providers

A share-of-savings model pays a provider more for finding waste slowly, rewards leaving some behind for next quarter, and offers no incentive whatsoever to do item 12 — because attribution reduces next year's fee.

It is attractive because it appears risk-free. The risk is real; it is simply deferred and structural. We charge a fixed fee, and we would suggest you ask any provider to explain how their model rewards prevention.