How to Audit Your AWS Bill: A Step-by-Step Guide to Finding Waste

Most AWS bills have 20 to 30 percent of easy waste in them

If you have never audited your AWS bill, there is a good chance a meaningful slice of it is going to resources nobody uses, instances that are twice as big as they need to be, and data quietly accumulating in storage. The good news: a first audit rarely requires deep expertise, and the biggest wins are usually the simplest. This guide walks through a repeatable process, from setup to quick wins to the harder structural savings.

Before you start: turn on the tools

You cannot audit what you cannot see. Enable these first; most are free.

• AWS Cost Explorer. Your primary lens. Turn it on and let it gather a few days of data if it is not already active.
• Cost and Usage Report (CUR). The most detailed billing data AWS offers, useful for deeper analysis later.
• AWS Budgets. Set a budget with alerts so you are warned before spend spikes again.
• Cost Anomaly Detection. Free, and it flags unexpected jumps automatically.
• Tagging. If resources are not tagged by team, service, or environment, start now. Untagged spend is invisible spend.

Step 1: Understand the shape of the bill

Open Cost Explorer and group by service, then by usage type. You are looking for the answer to one question: where does the money actually go? For most teams the top offenders are a familiar set:

• Compute (EC2, Fargate, Lambda)
• Databases (RDS, DynamoDB, ElastiCache)
• Storage (S3, EBS volumes, snapshots)
• Data transfer (often surprisingly large and easy to miss)
• Managed services and NAT gateways

Sort by cost and focus your effort on the top three or four line items. Chasing a 12 USD service while a 4,000 USD one sits unexamined is a common mistake. Also compare month over month to spot what is growing, not just what is big.

Step 2: Hunt the most common sources of waste

Work through this list in order. It is roughly sorted by how often each one hides real money.

Idle and orphaned resources

• Unattached EBS volumes. Volumes left behind after instances are terminated, still billed every month.
• Old snapshots. EBS and RDS snapshots that pile up forever. Set a retention policy.
• Unused Elastic IPs. AWS charges for allocated but unattached IP addresses.
• Idle load balancers. Load balancers with no healthy targets, still billing hourly.
• Forgotten dev and test environments. Staging that runs 24/7 but is only used during business hours.

Over-provisioned compute

• Oversized instances. Check CPU and memory utilization in CloudWatch. Instances averaging under 10 percent CPU are candidates to downsize.
• Old-generation instance types. Newer generations are often cheaper and faster for the same workload.
• Always-on non-production. Schedule dev and staging to shut down nights and weekends. This alone can cut a non-prod bill by more than half.

Storage sprawl

• S3 in the wrong storage class. Infrequently accessed data sitting in Standard. Lifecycle policies to move it to Infrequent Access or Glacier can slash storage cost.
• Incomplete multipart uploads. Failed uploads that never clean themselves up and quietly accrue charges.
• Log retention set to forever. CloudWatch Logs with no expiry policy grow without limit.

Data transfer

• Cross-AZ and cross-region traffic. Often avoidable with better placement.
• NAT gateway data processing. Can be a large hidden line item; VPC endpoints for AWS services often reduce it.

Step 3: Bank the quick wins

After one pass through the list above, you will usually have a set of no-regret actions you can take immediately:

1. Delete unattached volumes, orphaned snapshots, and unused Elastic IPs
2. Add S3 lifecycle rules and set CloudWatch Logs retention
3. Schedule non-production environments to stop outside working hours
4. Downsize the most obviously over-provisioned instances
5. Turn on Cost Anomaly Detection and a budget alert so waste does not silently return

You can find idle resources quickly with a few CLI checks. For example, listing unattached EBS volumes:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[].{ID:VolumeId,Size:Size,AZ:AvailabilityZone}" \
  --output table

And unused Elastic IPs:

aws ec2 describe-addresses \
  --query "Addresses[?AssociationId==null].PublicIp" \
  --output table

Step 4: Tackle the structural savings

Once the easy waste is gone, the bigger, more durable savings come from commitment-based pricing and architecture. These require more care because they involve lock-in.

• Savings Plans and Reserved Instances. For steady, predictable compute, a 1-year commitment commonly saves 30 to 50 percent versus on-demand. Only commit to your reliable baseline, not your peaks.
• Graviton (ARM) instances. Often 20 percent cheaper for equivalent performance if your workload runs on ARM.
• Spot instances. For fault-tolerant, interruptible workloads, dramatic discounts.
• Right-sizing databases. RDS is frequently over-provisioned; check utilization before committing to reservations.

Do the deletion and right-sizing before buying Savings Plans, so you do not commit to paying for capacity you are about to eliminate.

Helpful tools beyond the console

• AWS Compute Optimizer. Free right-sizing recommendations based on real utilization.
• AWS Trusted Advisor. Flags idle resources and cost opportunities (fuller checks require a support plan).
• Third-party platforms. Tools that add cross-account visibility and automated recommendations, worth it at larger scale.

Make it a habit, not a one-time panic

The reason bills balloon is that nobody looks until it hurts. Bake in a lightweight recurring review:

• Monthly: skim Cost Explorer for anything new or growing
• Quarterly: a full pass through the waste checklist above
• Always on: anomaly detection and budget alerts running in the background

When to bring in help

A first audit is very doable yourself, and honestly, if you have someone comfortable in the AWS console, you should start there and capture the easy wins before paying anyone. The picture changes when spend is large, when the architecture is complex across many accounts, or when the remaining savings require deeper re-architecture that your team does not have bandwidth for. At that point the savings from expert help often exceed its cost several times over. Our AWS cost optimization page covers what a deeper engagement looks like, and if the need is ongoing rather than a one-time cleanup, a DevOps monthly retainer keeps costs in check continuously.

If you would like a second pair of eyes on your bill, InstaDevOps offers senior DevOps on a monthly retainer as one option: Startup at 2,999 USD per month, Business at 4,999 USD per month, roughly 48-hour turnaround, pause anytime. It is one path among several, and if your team can capture the quick wins alone, we will tell you so. Book a free 15-minute call at calendly.com/instadevops/15min.