Last month, I had one of those moments that makes you pause and think "wait, did I actually do that?"
A client came to me with an AWS bill that made my eyes water - $1,900 per month for what should have been a simple web application. Six months later, that same infrastructure costs $250 per month. Same performance. Same reliability. Actually, better reliability.
Here's exactly what we did, and more importantly, why it worked.
The Starting Point: A $1,900 Monthly Bill
When I first logged into their AWS account, I saw the typical signs of infrastructure that had grown organically without much optimization:
- 15 EC2 instances running 24/7, many of them t3.mediums "just to be safe"
- 8 RDS database instances, including 3 that hadn't been touched in 6 months
- Massive S3 buckets with no lifecycle policies - storing everything in Standard tier
- No Reserved Instances or Savings Plans despite predictable workloads
- CloudWatch alarms that hadn't been reviewed in a year
Sound familiar? This is what happens when teams move fast and optimize later. The problem is, "later" rarely comes.
Step 1: Right-Sizing Instances (The Low-Hanging Fruit)
First thing we did was actually measure what the instances were doing. I pulled CloudWatch metrics for CPU, memory, and network utilization over the past 30 days.
Turns out, most of those t3.mediums were using less than 20% CPU on average. We could actually run the same workload on t3.small instances - cutting costs in half immediately.
But here's the thing: we didn't just downsize everything blindly. We:
- Set up CloudWatch dashboards to track actual usage
- Tested smaller instances during low-traffic periods first
- Enabled Auto Scaling so instances could scale up if needed
Result: Saved $600/month just by using the right instance sizes.
Step 2: Getting Rid of Zombie Resources
This is where it gets interesting. Those 8 RDS instances? Three of them were databases for projects that had been canceled. They were just sitting there, running, costing money.
We created a simple process:
- Created a backup of each database
- Terminated the instances
- Stored the backups in S3 Glacier for 90 days (just in case)
Saved another $400/month.
Step 3: Smart Storage Tiering
This client had about 2TB of data in S3. Most of it was old backups, logs, and assets that hadn't been accessed in months.
We implemented S3 Lifecycle policies:
- Data not accessed for 30 days → moves to Infrequent Access
- Data not accessed for 90 days → moves to Glacier
- Old backups automatically archived
This one move saved $300/month. And the best part? The client's application kept working exactly the same. Users didn't notice a thing.
Step 4: Reserved Instances Done Right
Now, for the workloads we knew were stable and predictable, we committed to Reserved Instances. But here's the key: we didn't just blindly buy 3-year RIs.
Instead, we:
- Started with 1-year Convertible RIs (more flexibility)
- Focused on the instances we were 100% certain about
- Used AWS Savings Plans for compute workloads (covers EC2, Lambda, Fargate)
This gave us about 40% savings on compute costs, which translated to another $300/month saved.
The Results: From $1,900 to $250
After all these changes, we ended up with:
- 87% reduction in monthly costs
- Zero downtime during the optimization process
- Better performance - Auto Scaling handles traffic spikes better than oversized static instances
- More visibility - CloudWatch dashboards help catch cost anomalies before they become problems
Lessons Learned
Here's what I tell every client now:
- Measure before you optimize. CloudWatch is your friend. Use it.
- Start with the easy wins. Right-sizing and removing unused resources are low-risk, high-reward.
- Automate cost management. Set up billing alarms. Review costs monthly. Make it a habit.
- Don't overthink Reserved Instances. If your workload is stable, RIs are a no-brainer. Start with 1-year terms.
The thing about cloud costs is that they tend to grow silently. That $1,900 bill didn't happen overnight - it grew gradually as the team added new features and services.
That's why regular optimization reviews are so important. Even spending 30 minutes a month reviewing your AWS bill can catch issues before they become expensive problems.
Your Next Steps
Want to apply these strategies to your own infrastructure? Here's where to start:
- Pull your CloudWatch metrics for the last 30 days
- Identify instances using less than 40% of their resources
- Check for unattached EBS volumes, unused load balancers, and stale snapshots
- Set up AWS Cost Explorer to track spending trends
- Enable billing alerts at 80% and 100% of your budget
Optimization isn't a one-time thing. It's an ongoing process. But the good news? Each month you optimize, you're building better habits and catching issues earlier.
Have questions about optimizing your own AWS costs? Drop us a line - we love talking about this stuff.