If you’ve looked at your AWS compute bill and thought “we should buy some reservations,” the first question you’ll hit is: Savings Plans or Reserved Instances?
Both offer discounts of 40–72% off on-demand rates in exchange for a 1- or 3-year commitment. The mechanics are different enough that buying the wrong type can cost you flexibility — or leave savings on the table.
Here’s how they actually work, when to use each, and the mistakes I see most often in cost audits.
The quick difference
Reserved Instances (RIs) are a commitment to a specific EC2 instance type (or RDS, ElastiCache, etc.) in a specific region. Standard RIs lock in the instance family, size, OS, and tenancy. In exchange, you get the biggest discounts.
Savings Plans are a commitment to a dollar amount of compute spend per hour. They apply automatically against whatever compute you’re running, as long as it qualifies. You don’t commit to a specific instance type.
The tradeoff is flexibility vs. discount depth:
| Savings Plans | Reserved Instances | |
|---|---|---|
| Flexibility | High | Low (Standard), Medium (Convertible) |
| Max discount | ~66% (Compute SP) | ~72% (Standard RI, 3yr, all-upfront) |
| Applies to | EC2, Lambda, Fargate | EC2 (or RDS, ElastiCache, etc.) |
| Requires instance type commitment | No | Yes (Standard RI) |
Savings Plans: the three types
Compute Savings Plans apply to any EC2 usage, Lambda, and Fargate — regardless of instance family, size, region, or OS. Maximum flexibility. Discount is ~66% vs on-demand.
EC2 Instance Savings Plans commit to a specific instance family in a specific region (e.g., m5 in us-east-1). Higher discount (~72%), less flexibility than Compute SPs — but you can still change instance size within the family.
SageMaker Savings Plans apply to SageMaker ML instances. Separate from the above — only relevant if you’re spending meaningfully on SageMaker.
The practical choice is usually between Compute and EC2 Instance Savings Plans.
Reserved Instances: Standard vs Convertible
Standard RIs lock in the instance family, size, OS, region, and tenancy. In exchange, you get the maximum discount — up to 72% for 3-year, all-upfront. They’re exchangeable within the same family (size changes only) and can be sold on the RI Marketplace.
Convertible RIs allow you to exchange for a different instance type, OS, or tenancy during the term. Discount is lower (~54% vs on-demand for 3-year all-upfront). The exchange process is a manual operation through the console or CLI — not automatic.
Standard RIs are worth it when you have a stable, long-running workload you’re confident won’t change instance type for 1–3 years. Convertible RIs are a middle ground: more flexibility than Standard, less than Savings Plans, with a discount somewhere between the two.
Which to use
Default choice: Compute Savings Plans
For most organizations, Compute Savings Plans are the right starting point. They apply automatically, require no instance-level planning, and cover Lambda and Fargate in addition to EC2. The discount (~66%) is significant even if it’s not the maximum possible.
If your infrastructure changes at all over a 1–3 year horizon — new instance types, migrations, scaling changes — Compute SPs absorb those changes without requiring you to manage RI inventory.
When to use EC2 Instance Savings Plans:
If you have a specific instance family (e.g., m6i in us-east-1) that runs continuously and won’t change, EC2 Instance SPs give you a higher discount than Compute SPs for that commitment, with still-reasonable flexibility (you can change size within the family).
When to use Standard RIs:
For non-EC2 services. Savings Plans don’t cover RDS, ElastiCache, Redshift, or OpenSearch. If you’re spending significantly on any of these, Standard RIs are how you get discounts there.
Also consider Standard RIs for EC2 when you can confidently predict instance type for 3 years and want to maximize discount — but this is a narrower use case than most teams think.
The commitment traps
Trap 1: Over-committing on instance type. Standard RIs for an instance family you’re about to migrate away from are the classic example. I’ve seen accounts with $50K in active Standard RIs for c4 instances that migrated to c6i — the RIs are technically valid but generate no savings because the instances aren’t running. The RI Marketplace exists to sell them, but at a discount.
Trap 2: Buying 3-year when 1-year fits better. The discount gap between 1-year and 3-year is real (~25% vs ~40% for partial upfront EC2 Instance SP), but 3 years is a long time. If you’re not confident in your workload trajectory, 1-year terms give you a rebaseline opportunity.
Trap 3: Coverage without utilization visibility. Savings Plans and RIs generate savings only when compute is actually running. If your utilization drops (seasonal business, project ends), you’re paying for unused commitment. Before buying, look at your 90-day utilization trend in Cost Explorer, not just the current snapshot.
Trap 4: Buying all-upfront without cash flow analysis. All-upfront gives the best effective hourly rate, but it’s a larger cash outlay now. Compare the all-upfront vs no-upfront NPV over the commitment term — sometimes no-upfront is better if that cash is working harder elsewhere.
How to size your commitment
AWS Cost Explorer has a Savings Plans recommendations section that shows you the optimal hourly commitment based on your actual usage. Use it — but treat it as a starting point, not a definitive answer.
My approach for clients:
- Pull 90-day average on-demand spend in Cost Explorer, filtered to the instance types/services you’re targeting
- Subtract any existing commitments (SPs or RIs already in place)
- Start at 60–70% coverage rather than 100%. The last 20–30% of your usage often has more variance, and over-committing is worse than under-committing
- Set a calendar reminder to review quarterly and layer in more commitments as confidence grows
The goal is not maximum discount — it’s maximum discount without commitment waste.
When to bring in help
Savings Plans and RI strategy interact with your workload roadmap. The right answer depends on what instance types you’re running, what’s on the migration roadmap, and how your compute usage has trended over the past year.
If your AWS bill has a large compute line and you haven’t formally evaluated your commitment strategy, that’s a cost audit. I typically find 20–35% savings opportunities in compute alone for accounts that have been running on-demand for more than 6 months.
Contact me or email nick@coldsmokeconsulting.com.
Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.