The Phone Call That Started This
A Series B SaaS company called us in a panic. Their AWS bill had grown from $8K/month 18 months ago to $67K/month. Revenue had grown 3x. Their AWS bill had grown 8x. Their CTO wanted to understand why, and their CFO wanted it fixed before the next board meeting.
Over 6 weeks, we reduced their bill to $24K/month - a 64% reduction - without touching a single product feature.
Here are the 8 changes, in order of impact.
Change 1: Right-size EC2 instances - Saved $14,200/month
Their production environment had 47 EC2 instances. After analyzing 30 days of CloudWatch metrics, we found:
- 23 instances were running at under 15% CPU utilization on average
- 8 instances had peak CPU usage under 30%
- 4 instances were running on r5.4xlarge (memory-optimized) for workloads that were CPU-bound
We downsized the underutilized instances and switched the mismatched instances to the correct family. Result: same performance, 40% fewer compute dollars.
How to do it yourself: Pull 30-day CPU, memory, and network utilization from CloudWatch for every instance. Any instance consistently below 20% CPU is a candidate for downsizing. Use AWS Compute Optimizer - it does this analysis automatically, but it takes 14+ days to generate recommendations for new workloads.
Change 2: Switch to Reserved Instances and Savings Plans - Saved $9,800/month
Every EC2 instance in their production environment was running On-Demand. For workloads that run continuously (databases, app servers, background workers), On-Demand is the most expensive option.
We purchased 1-year Savings Plans for their baseline compute (the minimum they need 24/7) and kept burst capacity On-Demand. Reserved Instances on their RDS databases added another layer of savings.
On-Demand vs Reserved: up to 40% cheaper for 1-year no-upfront, up to 60% for 3-year all-upfront.
Change 3: Kill idle resources - Saved $6,100/month
This one always surprises clients. A scan of their AWS account found:
- 14 unattached EBS volumes (snapshots kept, volumes never deleted after instance termination)
- 3 Elastic IPs not associated with any instance (charged at $0.005/hour each)
- 2 load balancers with no targets behind them
- 1 NAT Gateway in a VPC that had no private subnets using it
- 6 RDS snapshots from a database that was decommissioned 8 months ago
- 2 Elasticsearch domains used for a feature that was removed from the product
Total monthly waste from idle resources: $6,100.
How to find yours: AWS Cost Explorer > Filter by "No tag" shows untagged resources, which are often orphaned. Tools like Cloud Custodian or Infracost can automate idle resource detection.
Change 4: S3 storage tiering - Saved $4,400/month
They had 380TB in S3. All of it in S3 Standard ($0.023/GB). After analyzing access patterns:
- 290TB hadn't been accessed in over 90 days
- 80TB hadn't been accessed in over 180 days
- Only 10TB was accessed regularly
We set up S3 Intelligent-Tiering for the infrequently accessed data and moved the cold data to S3 Glacier Instant Retrieval.
S3 Standard: $0.023/GB. S3 Intelligent-Tiering infrequent access tier: $0.0125/GB. S3 Glacier: $0.004/GB.
Change 5: CloudFront for egress costs - Saved $3,900/month
Data transfer out of AWS to the internet is one of the most overlooked costs. They were serving images and assets directly from S3 and EC2, paying $0.09/GB in egress fees.
CloudFront's egress rate is $0.0085–$0.02/GB depending on region, and data transfer from S3 to CloudFront is free. Moving all static assets behind CloudFront reduced their egress bill by 80%.
Bonus: latency dropped 30–50% for international users.
Change 6: Database query optimization - Saved $2,800/month
This one required application-level work. Their RDS PostgreSQL instance was an r5.4xlarge - 16 vCPUs, 128GB RAM - because queries were running slowly and the previous team's solution was to add more hardware.
After adding PG Stat Statements and analyzing slow query logs:
- 3 queries were missing indexes on foreign keys used in JOINs
- 1 query was doing a sequential scan on a 50M-row table
- Several N+1 query patterns were generating thousands of queries per page load
After adding the missing indexes and fixing the N+1s, the database CPU dropped from 60% average to 18%. We downsized to r5.xlarge.
Change 7: Lambda and container consolidation - Saved $1,600/month
They had 34 Lambda functions handling background tasks, some of which ran every 5 minutes. A significant portion of their Lambda cost was from function cold starts and idle invocations.
We consolidated related background tasks into a single ECS task running on Fargate Spot (up to 70% cheaper than regular Fargate), which was more cost-effective for their usage pattern.
Change 8: Tag everything and set budget alerts - Saved $200/month ongoing (plus prevented future waste)
Before our engagement, less than 30% of their resources were tagged. Without tags, you can't attribute costs to teams, features, or environments. Development and production costs were combined in a single account.
We implemented a mandatory tagging policy via AWS Config, created separate accounts for dev/staging/prod in an AWS Organizations structure, and set budget alerts at 80% and 100% of monthly targets for each account.
This didn't generate immediate savings but has prevented several instances of unchecked resource growth since.
The Total
| Change | Monthly Savings |
|---|---|
| Right-sizing EC2 | $14,200 |
| Reserved Instances | $9,800 |
| Kill idle resources | $6,100 |
| S3 tiering | $4,400 |
| CloudFront egress | $3,900 |
| DB optimization | $2,800 |
| Lambda/container | $1,600 |
| Tagging + alerts | $200+ |
| Total | $43,000 |
What You Should Do This Week
1. Enable AWS Cost Explorer and look at the top 5 services by cost
2. Run AWS Compute Optimizer on your EC2 instances
3. Search for resources with no tags (these are almost always forgotten)
4. Check S3 access patterns - anything not accessed in 90 days should be tiered
5. Set a monthly budget alert at 110% of your current average
The average AWS bill has 20–30% waste that can be eliminated without any product changes. Start there before scaling up.