AWS Savings Plans vs RIs: Which Wins in 2026?
By Rostyslav Myronenko, holder of 14 active AWS certifications.
. 8 min read
AWS Savings Plans are usually the biggest single lever on an AWS bill, and one of the easiest to get wrong. Commit too little and your steady workloads keep paying On-Demand rates. Commit too much and you pay for capacity you no longer use, for up to three years.
Below is how Savings Plans work, the four types AWS sells, where Reserved Instances are still the better buy, and how I size a commitment.
Before you buy anything, open the Savings Plans utilization and coverage reports in Cost Explorer and look at what you already have. The problems usually fall into one of three groups: no plans at all, so steady workloads pay full On-Demand rates; plans sized for a bigger estate than you run today, so part of the commitment goes unused every hour; or EC2 Instance plans left over from before a migration, still tied to a family you've moved off.
How AWS Savings Plans work
A Savings Plan is a commitment to spend a fixed amount per hour on eligible usage for one or three years. Usage up to that amount is billed at a lower rate than On-Demand.
The mechanics, from the AWS Savings Plans documentation:
- You commit in dollars per hour, not in instances. For example, $10/hour of compute.
- Every hour, eligible usage is discounted up to the commitment. Anything above it is billed On-Demand.
- Unused commitment is still charged. If an hour's eligible usage comes in below the commitment, you pay the full commitment for that hour anyway.
- You can pay All Upfront, Partial Upfront or No Upfront. More upfront earns a slightly better rate.
- A plan can't be cancelled or changed after purchase. You can only buy more.
- Spot usage and usage already covered by Reserved Instances don't get the discount.
The four types of Savings Plans
AWS currently offers four Savings Plans types. The more flexible the plan, the smaller its maximum discount.
| Type | Max discount vs On-Demand | Applies to | Flexibility |
|---|---|---|---|
| Compute Savings Plans | up to 66% | EC2, Fargate, Lambda | Any instance family, size, OS, tenancy, Region |
| EC2 Instance Savings Plans | up to 72% | EC2 | One instance family in one Region; any size, OS, tenancy |
| Database Savings Plans | up to 35% | Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, OpenSearch and others | Engine, instance family, size, AZ and Region, on the latest instance generations |
| SageMaker AI Savings Plans | up to 64% | SageMaker AI instances | Instance family, size, Region, component |
Compute Savings Plans
For most teams I'd make this the default. The plan follows your workload when you change instance families, move to Graviton, switch Regions or move containers from EC2 to Fargate. The discount is smaller than with EC2 Instance Savings Plans, but you almost never end up paying for commitment stuck on an instance family you've already left.
EC2 Instance Savings Plans
The deepest discount, tied to one instance family in one Region. Size, OS and tenancy can still change inside that family. It makes sense for large, stable workloads where you're confident the family won't change for the whole term.
My rule of thumb: put EC2 Instance plans only on the slice of the baseline you'd bet on for the whole term. That means a fleet already on a current-generation family, with no Graviton move, re-platforming or container migration on the roadmap. Keep the rest on Compute Savings Plans. And take the three-year term only if you're as sure about year three as about next month.
Database Savings Plans
The newest type. It covers most managed database services, serverless usage included, and tops out at 35%, well below the compute plans. In exchange you get flexibility across engines and services: you can modernize from RDS for Oracle to Aurora PostgreSQL, or move a workload from RDS to DynamoDB, and keep the discounted rate.
Take a common setup: a few RDS PostgreSQL instances and an ElastiCache cluster. If you expect to change engine, move to Aurora or serverless, or resize during the term, Database Savings Plans are the safer buy, because the discount follows you. If the fleet is stable and already on current-generation instances, price RDS Reserved Instances and ElastiCache reserved nodes for the same term first; they can be the cheaper option for a setup that won't change. Instances on older generations don't qualify for Database Savings Plans at all, so for those the choice is reservations or an upgrade.
Savings Plans vs Reserved Instances
Reserved Instances (RIs) are the older commitment model. For EC2, Savings Plans have mostly replaced them, but RIs still matter in a few cases. AWS's own comparison lines them up like this:
| Compute Savings Plans | EC2 Instance Savings Plans | Convertible RIs | Standard RIs | |
|---|---|---|---|---|
| Max savings | up to 66% | up to 72% | up to 66% | up to 72% |
| Commitment | $/hour | $/hour | Specific instance config | Specific instance config |
| Any instance family | ✓ | – | via manual exchange | – |
| Any Region | ✓ | – | – | – |
| Fargate and Lambda | ✓ | – | – | – |
| Terms | 1 or 3 years | 1 or 3 years | 1 or 3 years | 1 or 3 years |
When Reserved Instances still win
- You need a capacity guarantee. Zonal RIs reserve capacity and Savings Plans don't, though you can pair a Savings Plan with an On-Demand Capacity Reservation and get both.
- The service has no Savings Plan at all. Redshift and MemoryDB, for example, only have reservations.
- The RI rate is deeper for your case. For databases, compare the RI rate with the Database Savings Plans rate for your exact engine and instance before you choose.
- You want a way out. Standard EC2 RIs can be sold on the Reserved Instance Marketplace. A Savings Plan can't be resold.
A typical example of the capacity case is a workload pinned to one Availability Zone that must be able to restart on the same instance type at any time, such as a self-managed database or a licensed application tied to specific hardware. A zonal Standard RI covers the price and the capacity in one purchase. The alternative is an On-Demand Capacity Reservation with a Savings Plan applied to it. That keeps the Savings Plan's flexibility, at the cost of two things to manage instead of one.
How to size a Savings Plans commitment
Cost Explorer gives you purchase recommendations. They're a reasonable starting point, but they look backwards and assume the next one to three years will look like your recent usage.
The way I do it:
- Optimize first. Right-size, delete what's idle and decide on Graviton before you commit, otherwise you're committing to waste. The AWS cost optimization guide covers what to check.
- Find the floor. Look at hourly eligible spend over recent months and find the level you never drop below, even in the quietest hours.
- Commit below that floor. Usage above the commitment runs On-Demand, which costs a bit more. An unused hour of commitment is paid in full.
- Buy in tranches, monthly or quarterly, instead of one big purchase. The plans then expire at different times, and each expiry is a chance to adjust.
- Mix types on purpose: Compute Savings Plans for the flexible core, EC2 Instance or Database plans only where you're sure.
- Check utilization and coverage every month. Utilization under 100% means you over-committed. Low coverage means you're paying On-Demand for usage you could have covered.
Utilization should sit close to 100%. If it stays noticeably below that month after month, the next tranche should be smaller, or skipped. Coverage is where people reach for a benchmark, and I'd rather they didn't. The right coverage for your bill is your floor as a share of eligible spend. A flat, always-on estate can cover most of its usage. A spiky one with big nightly batch jobs should cover much less, and that's fine. Look at both again before any plan expires, so an expiry never takes you back to On-Demand by surprise.
Account structure matters
In an AWS Organization, Savings Plans are shared across linked accounts by default. That usually keeps utilization high, but it makes cost allocation messy, because the discount lands wherever the eligible usage happens to run. Decide how you'll show commitment cost and savings to each team before you buy.
Common Savings Plans mistakes
- Buying the whole recommendation in one go, right before a planned migration or re-architecture.
- Picking EC2 Instance Savings Plans for the extra discount, then moving to Graviton or a new instance family.
- Forgetting that commitments outlive projects. A three-year plan bought for a workload that shuts down next year keeps charging for two more.
- Buying, then never looking at utilization again.
FAQ
Are AWS Savings Plans worth it?
For steady workloads that will run for the whole term, almost always. The risk is in the size of the commitment, so commit to your baseline and let the peaks run On-Demand.
What is the difference between Compute Savings Plans and EC2 Instance Savings Plans?
Compute Savings Plans apply across instance families, Regions, Fargate and Lambda, with discounts up to 66%. EC2 Instance Savings Plans are locked to one instance family in one Region, with discounts up to 72%.
Can you cancel an AWS Savings Plan?
No. A Savings Plan can't be cancelled or modified after purchase, and unlike Standard Reserved Instances it can't be resold either. Size it carefully and buy in tranches.
Do Savings Plans apply to RDS?
Compute and EC2 Instance Savings Plans don't. Database Savings Plans cover RDS, Aurora and several other managed database services. RDS Reserved Instances are the alternative, so compare the rates for your engine and instance type.
Do Savings Plans work with an EDP?
Yes. A private pricing agreement and Savings Plans can both apply to your bill. Model the combined effect before you sign either one. More in the AWS Enterprise Discount Program guide, and the EDP eligibility checklist shows whether you are in range.
Managing Savings Plans continuously
Most of the long-term savings come after the purchase, from keeping coverage and utilization right while your architecture changes, for as long as you're on AWS.
I do this in my async AWS advisory retainer. Each month you get a written review of architecture and spend, which includes where your Savings Plans and Reserved Instances stand and what to buy or let expire next. The retainer and my fixed-scope packages are all on the FinOps consulting page.