AWS Savings Plans and Reserved Instances are both ways to trade a one or three year commitment for a lower rate on compute. Picked well, either can take 40 to 70 percent off the relevant line. Picked badly, either can lock waste in for years. The deciding question is rarely which instrument has the bigger headline discount; it is how much your fleet will change over the commitment term, and whether you have cleaned the baseline first.
This article sits in our AWS cluster. For the full program it belongs to, start with the complete guide to AWS cost optimization, the pillar this links up to. Buying commitment is the rate part of the Cut step in our See, Cut, Lock, Run method, and it is the second half of where our 31 percent average reduction comes from.
Rightsize before you commit. A Savings Plan or Reserved Instance bought on an oversized or older-generation fleet locks the waste in for the whole term. Clean the baseline first with EC2 rightsizing, then buy the rate against the smaller, true footprint.
What each instrument actually is
A Reserved Instance is a billing commitment to a specific instance configuration. Standard RIs give the deepest discount but lock you to an instance family, and Convertible RIs trade some discount for the ability to exchange into other families over time. RIs apply to EC2, and the RI concept also exists for RDS, ElastiCache, OpenSearch and Redshift.
A Savings Plan is a commitment to a steady dollar-per-hour of compute spend rather than to a specific instance. Compute Savings Plans are the most flexible: the discount applies automatically across EC2 instance families, sizes, regions, operating systems and tenancy, and also covers Fargate and Lambda. EC2 Instance Savings Plans commit you to a specific instance family in a region in exchange for a deeper discount, while still flexing across size, OS and tenancy within that family. We compare those two head to head in Compute Savings Plans vs EC2 Instance Savings Plans.
Savings Plans vs Reserved Instances, side by side
| Dimension | Compute Savings Plan | Standard Reserved Instance |
|---|---|---|
| Flexibility | Across family, size, region, OS, tenancy; covers Fargate and Lambda | Locked to instance family; Convertible RIs can be exchanged |
| Discount depth | Up to roughly 66% off on-demand | Up to roughly 72% off on-demand for Standard RIs |
| Commitment unit | Dollars per hour of compute | A specific instance configuration |
| Capacity reservation | No capacity guarantee | Zonal RIs can reserve capacity |
| Terms | 1 or 3 year; No, Partial or All Upfront | 1 or 3 year; No, Partial or All Upfront |
| Best for | Changing fleets, mixed services, most teams | Very stable, long-lived, single-family workloads |
Discount ranges and coverage above reflect AWS pricing structure as of May 2026. Confirm the exact rate for your region, term and payment option in the AWS Pricing Calculator or the Cost Management console before purchasing, as rates change.
Which to buy
For most teams, Compute Savings Plans should be the default. The few percentage points of extra discount that Standard RIs offer rarely outweigh the cost of being locked to a family that your architecture outgrows in twelve months. The flexibility of a Compute Savings Plan means the commitment keeps applying as you change instance types, adopt Graviton, move regions, or shift work to Fargate and Lambda, so the discount follows your real usage instead of stranding on a configuration you abandoned.
Reserved Instances still earn their place in two situations. First, genuinely stable, long-lived workloads on a single instance family, where the deeper Standard RI discount is worth the lock-in. Second, when you need a zonal capacity reservation for a critical workload, which Savings Plans do not provide. For the RDS, ElastiCache and other service families, reservations remain the primary commitment tool; the RDS version is covered in RDS cost optimization.
Want the commitment math done for you?
Our AWS cost audit models your ideal Savings Plan and Reserved Instance mix against your real usage, sizes the ladder, and tells you the dollar impact before you buy. On the performance model, you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →When to buy, and how much to cover
Timing and coverage matter as much as the instrument. Three principles keep commitment from becoming its own form of waste.
Buy after rightsizing, never before. Commit against the footprint you will actually run, not the one you have today. This is the difference between a discount that lands on real usage and one that subsidizes oversized instances for three years.
Cover the steady core, not the peak. Aim to commit to the stable baseline of usage that runs around the clock, and leave the variable layer on on-demand or Spot. Over-committing to peak capacity that only appears occasionally produces unused commitment, which is pure waste. Track this through coverage and utilization reporting in Cost Explorer.
Ladder the terms. Rather than buying one large commitment that all expires on the same day, stagger purchases so they renew in tranches. Laddering smooths renewal risk, lets you re-rate as prices and your fleet change, and avoids a cliff where a third of your discount disappears at once. This is exactly the approach behind our SaaS on AWS case study, where laddered Savings Plans on a clean baseline helped deliver a 33 percent reduction.
The AWS Cost Optimization Field Guide includes the coverage targets and the laddering model we use to size commitments by workload stability. It is the downloadable companion to this comparison.
The short version
Default to Compute Savings Plans for their flexibility, reach for Standard Reserved Instances only on very stable single-family workloads or when you need a capacity reservation, and use service-specific reservations for RDS and friends. Whichever you buy, rightsize first, cover the steady core rather than the peak, and ladder the terms. When you want the whole commitment strategy modeled and bought correctly across your estate, that is what our AWS cost optimization service delivers.