The AWS cost optimization audit checklist

The short version

An AWS cost audit is four phases and they only work in one order: make the bill readable, delete what nobody owns, right-size what is left, then commit to the baseline. The order is the whole method. Most teams start at commitments because Savings Plans feel like the lever finance understands, and they end up locked into a baseline full of waste they were three days away from deleting.

The checklist below is what I run on an engagement. It is grounded in a three-client audit where the findings were, as usual, unglamorous: idle instances, an oversized database from an old load test, and no lifecycle policy anywhere. Work like that is what adds up to the portfolio-wide figure on this site: ₹50L+/year in AWS waste removed for clients (~$60K+/year), from cost and reliability audits.

The order matters more than the list

Every item below appears on every vendor's cost checklist. What separates an audit that holds from one that unwinds in a quarter is sequence. Cleanup before right-sizing, because there is no point sizing an instance you are about to terminate. Right-sizing before commitments, because a commitment is a bet on your baseline and you want to place it after the baseline has shrunk, not before. Visibility before all of it, because you cannot get anyone to delete a resource they cannot attribute to a team.

1. Visibility: make the bill readable

Start with three days of discovery: pull Cost Explorer data, Trusted Advisor findings, and CloudWatch utilization metrics across every region, not just the one you think you use. Untagged spend is the first thing to quantify, because it sets a ceiling on everything else. If half the bill cannot be attributed to a team or a service, half the conversation ends in a shrug.

• Enable Cost and Usage Reports, and check every region, including ones nobody claims to use.
• Define a tagging standard: team, environment, service, cost centre.
• Enforce it with AWS Config rules rather than a wiki page nobody reads.
• Build per-team and per-service dashboards so engineering and finance see the same number.
• Set budget alerts with thresholds that fire before the invoice, not with it.

On the three-client engagement this phase replaced a monthly PDF from finance with real-time per-team dashboards. That change alone moved the conversation from arguing about the total to fixing specific line items.

2. Cleanup: delete what nobody owns

This is the highest-return, lowest-risk phase, and it is always the most boring. Script the detection instead of clicking through the console, and use thresholds you can defend. The ones I use as a starting point: EC2 sitting under 5% CPU, RDS under 8% utilization, EBS volumes attached to nothing, and Elastic IPs allocated to nothing.

• Idle compute: EC2 under 5% CPU sustained, and anything running that no team claims.
• Orphaned storage: unattached EBS volumes and the snapshots nobody has pruned.
• Unused Elastic IPs, idle load balancers, and NAT gateways serving nothing.
• S3 with no lifecycle policy: 30 days to Infrequent Access, 90 days to Glacier is a sane default.
• Non-production environments running nights and weekends for no reason.
• Old snapshots and AMIs kept indefinitely because deletion felt risky.

On that engagement the idle EC2 count went from 47 to zero. Nobody had launched them maliciously; they were just invisible. Automate the non-production shutdown with a scheduler, not on anyone remembering, and the savings stay gone.

3. Right-sizing: match capacity to load

Now size what survived cleanup, against measured utilization rather than the number someone picked during a launch. Compute Optimizer is a reasonable starting point, but read its recommendations against your own latency and headroom requirements before applying them; it does not know about your traffic spikes.

• Right-size EC2 and RDS against sustained utilization, not peak-of-peak.
• Check for oversizing left over from load tests and migrations.
• Move fault-tolerant and interruptible work to Spot where the workload genuinely tolerates it.
• Match storage class and database engine to the access pattern.
• Look at data transfer and NAT gateway charges, which hide in plain sight.
• Check log retention: indefinite CloudWatch retention is a slow, permanent bill.

4. Commitments: buy the baseline, last

Only now, with a smaller and better-understood baseline, do commitments make sense. Model the scenarios before buying: one-year against three-year, All Upfront against No Upfront, across the instance families you actually run, not the ones you ran last year.

This is where careless advice gets expensive. On one of those three clients the modelling caught them about to commit to a three-year All Upfront plan on the wrong instance family. That is a mistake you live inside for three years. Done properly, coverage on that engagement went from 0% to 78% of eligible compute, which is a very different number from 100%, deliberately: you commit to the stable floor of your usage, not to all of it.

Track unit cost, not just the bill

A lower total bill is not the only test of a good audit. If usage grows, the bill may rise while cost per order, request, or active tenant falls. Choose a unit that matches the business, track it by team and service, and compare it with the baseline after each change. That is how you tell healthy growth from new waste instead of cutting capacity blindly.

Making the savings stay saved

A cost audit that ends with a spreadsheet is a cost audit you will repeat next year. The savings drift back because the conditions that produced them drift back. Enforce tagging in CI and with Config rules so new resources cannot arrive unattributed. Keep the dashboards in front of the teams who create the spend, not only in front of finance. Keep the non-production schedulers running. Put budget alerts on the services that grow quietly.

The goal is that the next audit finds less, because the estate now resists accumulating waste on its own.

What I will not promise

I will not quote a savings percentage before seeing billing and utilization data. What is available depends entirely on how much waste exists, and nobody can know that from the outside. Reductions on documented work have run up to 55%, with 30 to 40% more typical, but those are results of specific estates and not a rate card. A consultant who commits to a number before discovery is either guessing or planning to cut something you need.

Where teams get this wrong

• Buying Savings Plans before cleanup, locking in a baseline full of waste.
• Committing three-year All Upfront on an instance family you are migrating off.
• Right-sizing against peak-of-peak, which sizes for one spike and pays for it all year.
• Treating untagged spend as someone else's problem, so nothing can be attributed.
• Leaving S3 with no lifecycle policy and CloudWatch with indefinite retention.
• Reporting savings as a one-off win with nothing enforcing them afterwards.
• Cutting capacity far enough to make reliability the next quarter's problem.