Reserved Instances and Savings Plans are both AWS commitments that discount compute against on demand for a one or three year term, and both leave the buyer carrying utilization risk. The difference is what you lock to. A Savings Plan commits to a steady dollar per hour of compute spend and applies automatically across instance families, sizes, and regions, so it keeps discounting even as you change what you run. A Reserved Instance commits to a specific instance configuration for a slightly deeper discount, but it stops fitting the moment you rightsize or migrate away from that configuration. For most estates the right default is Compute Savings Plans for the flexible core, with Reserved Instances reserved for genuinely stable, specific workloads and for services Savings Plans do not cover. The metric to optimise is effective savings rate without stranded commitment, not the deepest discount on any one line.
Here is how each instrument works, the precise tradeoff, and a decision framework you can apply to your own estate.
How does each instrument actually work?
A Compute Savings Plan asks you to commit to a baseline of compute spend per hour. AWS then applies the discounted rate to any matching usage up to that commitment, regardless of instance family, size, operating system, tenancy, or region. If you migrate from one instance family to a newer one, or rightsize a fleet, the plan keeps applying its discount to whatever you now run. A Reserved Instance, by contrast, attaches to a specific family and size in a region. Standard Reserved Instances offer the deepest Reserved Instance discount but are the least flexible, while Convertible Reserved Instances allow exchanges for a smaller discount. Reserved Instances also remain the commitment mechanism for some services beyond plain compute. Both instruments offer no upfront, partial upfront, and all upfront payment options, with deeper discounts for more money paid sooner.
What is the real tradeoff?
The tradeoff is flexibility against a thin slice of extra discount. The table lays it out.
| Dimension | Compute Savings Plan | Reserved Instance |
|---|---|---|
| Flexibility | Applies across families, sizes, and regions automatically | Locked to a specific configuration unless Convertible |
| Discount depth | Strong; slightly below a Standard Reserved Instance | Deepest for Standard, in exchange for rigidity |
| Survives rightsizing | Yes, the plan reapplies to the new shape | No for Standard, partially for Convertible |
| Management overhead | Low, one commitment covers a moving fleet | Higher, configurations must be tracked and exchanged |
| Best for | The flexible core of steady compute | Very stable, specific workloads and some services |
The reason flexibility usually wins is behavioural: estates change. You will adopt a newer, cheaper instance generation such as Graviton, you will rightsize after a load shift, and you will migrate services. A Savings Plan rides through all of that; a Standard Reserved Instance can be left stranded against capacity you no longer run, turning a discount into dead weight. Paying a fraction less in discount to avoid that outcome is usually the better risk adjusted trade.
Which should you use for each workload?
Default to a Compute Savings Plan for the steady, defensible baseline of your general compute, because it gives you discount and freedom at once. Reach for a Standard Reserved Instance only where a workload is genuinely fixed in configuration and you are highly confident it will not move for the term, and where the extra discount justifies the rigidity. Use Convertible Reserved Instances or Reserved Instances for the handful of services that Savings Plans do not cover. And keep a layer of usage on demand for anything variable or uncertain, because no commitment is the right answer for load you cannot defend. The result is a portfolio, not a single bet.
Ask of any proposed Reserved Instance: am I confident this exact configuration will still be running in three years? If the honest answer is no, a Compute Savings Plan captures almost the same discount without the stranding risk, and it is the safer buy.
How do you build a commitment portfolio?
Start from a rightsized estate and a defensible baseline, then layer the instruments. Cover the broad, moving core of compute with Compute Savings Plans sized to the floor of usage you are sure of. Add Reserved Instances only for the stable, specific exceptions and uncovered services. Keep the variable top of the load on demand, and use Spot for fault tolerant work. Review the portfolio on a regular cadence, because effective savings rate drifts as usage and prices change, and because expiring commitments are a chance to resize coverage to the current forecast. The aim throughout is a high blended discount with little or no commitment sitting idle, which is a different and better target than maximising the discount on any single purchase.
A scaling fintech had loaded up on Standard Reserved Instances for the deepest paper discount, then migrated much of its fleet to a newer instance generation, leaving those Reserved Instances stranded against retired capacity. We shifted the core to Compute Savings Plans that follow the fleet, kept Reserved Instances only for a stable database tier, and sized coverage to a defensible baseline. Effective savings rate rose and stranded commitment fell, and the rebuilt portfolio was part of the work that left the fintech 41 percent lighter. Figures are verified against billing data and anonymized.
Where this fits in your AWS cost program
The instrument choice follows the decision to commit at all. Read on demand versus commitment on AWS for that prior step, and commitment coverage targets that make sense for sizing. For the full estate picture see the AWS cost optimization guide, and for how this generalises across providers, the cloud cost optimization guide.
Frequently asked questions
What is the difference between Reserved Instances and Savings Plans?
Are Savings Plans better than Reserved Instances?
Can you mix Reserved Instances and Savings Plans?
Build a commitment portfolio that holds up
We design AWS commitment portfolios that capture the discount without the stranding risk, sized to a defensible forecast, independent of any provider and taking zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk. Start with our playbook.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.