AWS Savings Plans: How to Actually Save Money on Cloud Computing

AWS Savings Plans have gotten complicated with all the pricing tiers, commitment types, and calculator tools flying around. As someone who’s managed cloud budgets ranging from a few hundred bucks to millions of dollars a year, I learned everything there is to know about not overpaying for AWS. Today, I will share it all with you.

I’ll never forget the first time I got an AWS bill that made my stomach drop. We were running a proof of concept, nobody was watching the spend, and one month later we had a five-figure bill for what should have been a simple test environment. That experience turned me into an obsessive cost optimizer, and honestly, it’s saved every company I’ve worked for a small fortune since.

Understanding AWS Savings Plans

At its core, an AWS Savings Plan is a commitment to spend a certain dollar amount per hour on compute for 1 or 3 years. In exchange, AWS gives you a significant discount — up to 72% off On-Demand pricing. It’s the same principle as buying in bulk: commit to more, pay less.

There are three types of Savings Plans, and understanding the differences matters:

Compute Savings Plans

These are the most flexible option. Your discount applies to any EC2 instance, regardless of family, size, OS, tenancy, or region. It also covers Fargate and Lambda usage. I recommend these for most organizations because they give you room to change your infrastructure without losing your discount.

EC2 Instance Savings Plans

More restrictive but deeper discounts. You commit to a specific instance family in a specific region (like M5 in us-east-1). You still get flexibility on size, OS, and tenancy. I use these when I’m confident a workload will stay on the same instance family for the commitment period.

SageMaker Savings Plans

Same concept but for SageMaker ML workloads. If you’re running steady-state ML training or inference, these can save a lot.

How Much Can You Actually Save?

Probably should have led with this section, honestly, because the savings are the whole point. Here’s what I typically see:

• 1-year, no upfront: Around 20-30% savings versus On-Demand. Lowest commitment, lowest risk.
• 1-year, all upfront: Around 30-40% savings. Pay everything upfront for a bigger discount.
• 3-year, no upfront: Around 40-50% savings. Bigger commitment, bigger reward.
• 3-year, all upfront: Up to 72% savings. Maximum commitment, maximum savings.

For a company spending $10,000/month on EC2, a 3-year Compute Savings Plan can save roughly $4,000-$5,000 per month. That’s real money that can fund new projects, hire people, or just improve your bottom line.

Savings Plans vs. Reserved Instances

This is the question I get asked most. Reserved Instances (RIs) were the original commitment-based discount, and they still exist. But Savings Plans are almost always the better choice now because they’re more flexible.

With RIs, you commit to a specific instance type in a specific Availability Zone. If you need to change anything, you’re stuck converting or selling the RI. With Savings Plans, your commitment is a dollar amount, and AWS automatically applies it to whatever you’re running. I’ve migrated teams from RIs to Savings Plans and the flexibility improvement alone was worth it, even when the discount percentage was similar.

How to Right-Size Before Committing

Here’s a mistake I see all the time: organizations buy Savings Plans based on their current usage without first optimizing their infrastructure. You could be committing to pay for waste.

Before buying any commitment:

1. Review AWS Compute Optimizer recommendations. It analyzes your actual usage patterns and suggests right-sized instances. I’ve seen teams cut 30% of their compute just by right-sizing.
2. Check for idle resources. Instances running at 5% CPU, unattached EBS volumes, unused Elastic IPs — clean all of this up first.
3. Consider Graviton instances. They’re 20% cheaper than x86 equivalents. Migrating to Graviton before buying a Savings Plan amplifies your savings.
4. Evaluate Spot for eligible workloads. Batch processing, CI/CD builds, and dev environments can often use Spot instances at 60-90% savings with no commitment needed.

Setting Up Your First Savings Plan

The AWS Cost Explorer has a Savings Plans recommendation engine that analyzes your past usage and suggests the right commitment level. It’s genuinely good — I’ve compared its recommendations to my own analysis, and they’re usually within a few percentage points.

Here’s my process:

1. Go to the Savings Plans section in Cost Explorer
2. Review the recommendations based on your last 7, 30, or 60 days of usage
3. Choose your plan type (Compute for flexibility, EC2 Instance for deeper savings)
4. Pick your term (1 year to start if you’re nervous, 3 years if you’re confident)
5. Choose your payment option (no upfront is the safest starting point)
6. Purchase the plan

That’s what makes AWS Savings Plans endearing to us cloud engineers — they’re straightforward once you understand the options, and the savings start immediately.

Building a Comprehensive Cost Strategy

Savings Plans are just one piece of the puzzle. A complete AWS cost optimization strategy looks something like this:

• Base layer (Savings Plans): Cover your steady-state, always-on production workloads with 1 or 3 year commitments.
• Variable layer (On-Demand): Keep some capacity on On-Demand for workloads that fluctuate or are temporary.
• Opportunistic layer (Spot): Use Spot instances for fault-tolerant workloads like batch jobs, testing, and dev environments.
• Storage optimization: S3 Intelligent-Tiering, EBS volume right-sizing, and lifecycle policies for data you rarely access.
• Monitoring: AWS Budgets alerts, Cost Anomaly Detection, and monthly cost reviews to catch problems early.

Common Mistakes to Avoid

• Over-committing: Don’t buy a Savings Plan for 100% of your current usage. Leave room for optimization and fluctuation. I usually commit to 60-80% of steady-state usage.
• Ignoring utilization reports: Check your Savings Plan utilization monthly. If it’s consistently below 90%, you may have over-committed.
• Forgetting about other regions: Compute Savings Plans apply across regions. EC2 Instance Savings Plans don’t. Choose accordingly.
• Not reviewing annually: Your infrastructure changes over time. Review and adjust your Savings Plans at each renewal.

The Bottom Line

If you’re running workloads on AWS that you know will be there next year, you should be using Savings Plans. It’s essentially free money — same infrastructure, lower bill. Start with a conservative 1-year Compute Savings Plan covering your baseline usage, get comfortable with how it works, and expand from there.

The teams that take cloud cost optimization seriously aren’t the ones pinching pennies. They’re the ones who free up budget for the projects that actually matter. And in my experience, it all starts with understanding and properly using Savings Plans.