AWS cost audit checklist: 20 checks we run in the first week

Guides · 28 October 2026 · 9 minute read

An AWS bill rarely hides its waste in one place. It sits in a dozen small defaults that nobody revisited after launch: instances sized for a peak that never came, volumes nobody owns, traffic paying a NAT gateway for no reason. This is the checklist we work through in the first week of an AWS cost audit, in the order that makes each later check easier.

It is written for CTOs, engineering leads and founders of SaaS companies spending a few thousand dollars a month on AWS or more. To use it, run the checks in order, note the monthly saving and the effort for each (an hour, a day or a sprint), and fix the cheap, valuable ones first.

Checks 1–5: visibility and billing

You can’t cut what you can’t attribute. These five checks make every later number trustworthy.

• 1. Cost and Usage Report export is on. Turn on a CUR 2.0 export (Billing → Data Exports) to S3 and query it with Athena. Cost Explorer is fine for a first look, but only the CUR shows line items per resource and per hour.
• 2. Spend is broken down by account and service. Look at the last three months in Cost Explorer, grouped by linked account, then by service. Write down the top five services; they usually hold most of the bill and decide where the audit spends its time.
• 3. Tags cover most of the spend. Activate cost allocation tags such as team, service and env, then check what share of spend carries them. Below about 70% coverage, every later conversation about who owns a cost becomes guesswork.
• 4. Cost Anomaly Detection and Budgets are set. Anomaly Detection is free and catches a runaway job within a day. Add an AWS Budget per account with an alert at 80% of forecast.
• 5. Non-production runs on a schedule. List dev, staging and test environments that run 24/7. Running them only in working hours (roughly 50 of 168 hours a week) removes about 70% of their compute cost.

Checks 6–11: compute and commitments

Compute is usually the largest line, and the one where commitments and right-sizing compound.

• 6. Instances are right-sized. Open AWS Compute Optimizer and list every EC2 instance flagged as over-provisioned. Average CPU under 20% over 14 days is a strong signal to drop one size.
• 7. Current-generation instance families are in use. Move m4, c4 and r4 to m7, c7 and r7. Newer families cost the same or less for more performance.
• 8. Graviton has been evaluated. AWS cites up to 40% better price-performance for Graviton (Arm) over comparable x86 instances. Most containerised and interpreted workloads (Node, Python, Java, Go) move with a rebuild.
• 9. Savings Plans coverage matches steady usage. In Cost Explorer, check Savings Plans coverage and utilisation. Cover the stable baseline, often 60–80% of compute, and leave the rest on demand. Coverage near 100% usually means paying for commitments you may not use.
• 10. Spot is used where interruption is acceptable. CI runners, batch jobs and stateless workers can usually run on Spot at a large discount to on-demand. Mix several instance types so one shortage doesn’t stop the fleet.
• 11. Idle and orphaned compute is gone. Look for stopped instances still carrying EBS volumes, load balancers with no healthy targets, and public IPv4 addresses not in use. AWS charges for every public IPv4 address, attached or not.

Checks 12–16: storage and data transfer

Storage and network costs grow quietly, because nothing breaks when they do.

• 12. EBS volumes are gp3, not gp2. gp3 costs about 20% less per GB than gp2 and lets you set IOPS separately. The change is online, with no downtime.
• 13. Unattached volumes and old snapshots are cleaned up. List EBS volumes in the available state and snapshots older than your retention policy. Data Lifecycle Manager can enforce retention from then on.
• 14. S3 has lifecycle rules. Use Intelligent-Tiering for data with unknown access patterns, and expire old versions and incomplete multipart uploads. S3 Storage Lens shows which buckets matter.
• 15. NAT Gateway traffic is checked. NAT Gateways charge for every gigabyte they process. Traffic to S3 and DynamoDB can go through gateway VPC endpoints instead, which have no charge.
• 16. Cross-AZ and internet egress are understood. Traffic between Availability Zones is billed in both directions. Chatty services split across zones, and logs or backups shipped out of the region, are common sources. Put a CDN in front of public downloads.

Checks 17–20: databases, Kubernetes and governance

The last four checks catch costs that come from versions and defaults rather than size.

• 17. Databases are sized and versioned well. Check RDS instances for low CPU, Multi-AZ on non-production, and older engine versions. AWS charges extra for RDS Extended Support once a MySQL or PostgreSQL major version passes standard support. Reserved Instances still apply to RDS, where Savings Plans do not.
• 18. Kubernetes requests match real usage. On EKS, compare pod CPU and memory requests with actual usage; over-sized requests keep nodes half empty. Clusters on a Kubernetes version past standard support also pay a much higher hourly control-plane fee. Our Kubernetes cost optimisation checklist covers this in depth.
• 19. Logs have a retention period. CloudWatch log groups keep data forever by default. Set retention per group (for example 30 days for debug logs, longer only where compliance needs it) and check ingestion volume per service.
• 20. Someone owns the bill. Name an owner per account or team, review costs monthly, and track one unit metric such as cost per customer or per 1,000 requests. Without an owner, savings tend to drift back as new services ship.

What to fix first

Start with the changes that take an hour and need no code. They build trust in the audit and fund the harder work.

Two rules keep the savings safe. Buy Savings Plans only after right-sizing (checks 6–8), or you lock in waste for one to three years. And change one thing per service at a time, so a performance dip is easy to trace.

If you would rather have someone run this against your accounts with read-only access and hand you the evidence, that is what our AWS Cost Optimisation engagement does. It starts with a free cloud cost audit; see what a report looks like.