A client came to us last year with a simple problem: their AWS bill had grown from $800/month to $3,200/month over 18 months, and they had no idea why. Their product hadn’t grown 4x. Their user base had grown by maybe 50%. Something was seriously wrong.
Within 2 weeks of our AWS audit, we had reduced their bill to $1,900/month — a 40% reduction that persisted. This post documents exactly what we found and fixed, because it’s the same set of issues we see in almost every audit we do.
The Client Context
Mid-sized SaaS company, about 5,000 active users. AWS stack: EC2 instances for application servers, RDS PostgreSQL for the database, S3 for file storage, CloudFront CDN, ElastiCache Redis, and SES for email. Running in us-east-1. Original infrastructure set up 2.5 years earlier by a developer who’d since left the company.
Finding 1: Massively Overprovisioned EC2 Instances
The application was running on 4 × m5.2xlarge instances (8 vCPU, 32GB RAM each) behind a load balancer. Average CPU utilization: 4–8%. Average memory utilization: 15–20%. These instances were sized for a traffic spike that never happened.
Fix: Downgraded to m5.xlarge instances (4 vCPU, 16GB RAM each). Added auto-scaling to handle actual traffic spikes. Went from 4 large instances running 24/7 to 2 medium instances with auto-scaling up to 6 during peak hours.
Saving: ~$800/month. This single change covered 32% of the total saving.
Finding 2: RDS Over-Provisioned and No Reserved Instance
The database was running on a db.r5.2xlarge (8 vCPU, 64GB RAM). Average CPU: 6%. Average memory: 12%. Plus: they were paying on-demand pricing despite running this instance continuously for 2 years.
Fix: Downgraded to db.r5.large (2 vCPU, 16GB RAM). Purchased a 1-year Reserved Instance for the new size. Reserved Instances for predictable workloads typically save 30–45% over on-demand pricing.
Saving: ~$580/month.
Finding 3: Zombie Resources — Stopped Instances Still Billing for EBS
We found 11 EC2 instances in stopped state from old development and testing activities. When an EC2 instance is stopped, you don’t pay for compute — but you still pay for the attached EBS (Elastic Block Store) volumes. These 11 stopped instances had a combined 2.2TB of EBS storage from snapshots and volumes that nobody had thought to clean up.
We also found 47 unattached EBS volumes (volumes from terminated instances where somebody forgot to tick “delete on termination”) and 340GB of old EBS snapshots from 2+ years ago that served no current purpose.
Fix: Terminated stopped instances (after confirming nothing useful was on them), deleted unattached EBS volumes, purged old snapshots.
Saving: ~$180/month.
Finding 4: Data Transfer Costs from Missing CloudFront Configuration
CloudFront was set up for the main website but not for the application’s API responses or media files. Every API response and image served directly from S3 or EC2 via the internet was incurring data transfer charges. AWS charges for data transferred OUT from EC2 and S3 to the internet at $0.09/GB.
Fix: Extended CloudFront to cover the application’s media files. Configured appropriate cache headers for API responses that could be cached. Enabled S3 Transfer Acceleration only where actually needed (it was turned on globally, unnecessarily).
Saving: ~$210/month.
Finding 5: ElastiCache Using Multi-AZ for a Dev-Level Cache
The Redis cluster was configured as Multi-AZ (two nodes across availability zones) with automatic failover. For a Redis cache used primarily for session storage and some query caching, this was significant over-engineering. Redis cache can be rebuilt in seconds from the database — it doesn’t need Multi-AZ high availability.
Fix: Switched to a single-AZ cache.r6g.medium instance with a snapshot backup policy. This is sufficient for a cache that can be rebuilt. Multi-AZ reserved for actual persistent data stores.
Saving: ~$130/month.
What We Didn’t Change
Equally important: what we left alone. We didn’t touch the RDS Multi-AZ setup (databases should be Multi-AZ — data loss is catastrophic). We didn’t reduce the backup retention policy (data compliance requirements). We didn’t switch to Spot Instances for the application servers (they need to be available when users need them). Good cost optimization is surgical — cutting what doesn’t matter, preserving what does.
Total Savings Summary
- EC2 right-sizing + auto-scaling: ~$800/month
- RDS right-sizing + Reserved Instance: ~$580/month
- Zombie resource cleanup: ~$180/month
- CloudFront optimization: ~$210/month
- ElastiCache right-sizing: ~$130/month
- Total saving: ~$1,900/month (40% reduction)
Lessons for Your AWS Bill
These are not unusual findings. Almost every AWS account we audit has at least 3 of these 5 issues. The pattern is consistent: infrastructure gets set up for a traffic scenario that never materialised, nobody reviews it as the months pass, and the bill compounds quietly.
Simple habits that prevent this:
- Monthly cost review: 30 minutes looking at your Cost Explorer report every month.
- CloudWatch utilization alerts: Alert when any instance runs below 10% utilization for 7 days.
- Resource tagging: Tag every resource with environment (prod/staging/dev) and owner. Makes cleanup obvious.
- Delete on termination: Always tick “delete EBS on termination” when launching EC2 instances.
- Annual Reserved Instance review: Any workload that runs continuously is a candidate for Reserved pricing.