AWS Cost Guide
AWS Reserved Instances and Savings Plans. The 2026 guide.
Commitment discounts are the largest controllable lever on a compute bill and the easiest to get wrong. Here is how to capture the saving without stranding capacity.
Commitment discounts are the largest controllable lever on a compute bill and the easiest to get wrong. Here is how to capture the saving without stranding capacity.
Reserved Instances and Savings Plans both trade flexibility for a lower compute rate, but they reward different estates. The cost of getting the choice wrong is stranded capacity.
AWS commitment discounts are the largest controllable lever on a compute bill, and the easiest to get wrong. Reserved Instances and Savings Plans both trade flexibility for a lower rate, but they reward different estates.
Buyers lose money two ways. They under commit and pay on demand rates, or they over commit and strand capacity they cannot use. This guide covers the mechanics and the buyer side moves that hold the savings without the waste.
Reserved Instances discount specific instance families in a region, while Savings Plans discount a dollar per hour commitment across broader compute. Savings Plans are more flexible, Reserved Instances can be steeper on narrow workloads.
Reserved Instances commit to an instance family and region for one or three years. AWS documents the model on its Reserved Instances pricing page.
Savings Plans commit to a steady spend rate and apply across instance families and, for Compute Savings Plans, across regions and Fargate and Lambda. AWS describes them on its Savings Plans page.
Commit to the stable floor of usage, not the average and never the peak. The floor is the capacity you run every hour of every day across a representative period.
Analyze at least ninety days of usage and isolate the baseline that never drops. That baseline is the safe commitment target. AWS exposes this view in Cost Explorer and its recommendations.
Matching commitment to workload
| Workload pattern | Best instrument | Term |
|---|---|---|
| Stable, predictable baseline | EC2 Instance Savings Plan | Three year |
| Stable but evolving families | Compute Savings Plan | One to three year |
| Narrow, fixed, long lived | Reserved Instances | Three year |
| Spiky or uncertain | On demand or Spot | None |
Most mature estates blend instruments. A three year base covers the floor, a one year layer covers the predictable middle, and on demand or Spot absorbs the spike.
Stranded commitments come from committing above the floor or from ignoring coverage and utilization after purchase. Governance is what keeps the savings real.
Track commitment utilization and coverage monthly. Utilization below the high nineties means you are paying for unused commitment.
Give one team accountability for commitment purchasing across accounts. Decentralized buying produces overlap and waste.
The common advice is to maximize coverage by committing to as much of your usage as possible, since the discount only applies to committed spend. We disagree. In the AWS estates we optimized across 2024 and 2025, the buyers chasing maximum coverage routinely stranded commitments when teams refactored or moved regions. The reason is that cloud usage is not static, and a three year commitment outlives most architecture decisions. The buyer side move is to commit only to the demonstrable stable floor, layer shorter terms above it, and keep a deliberate slice on demand so the estate can change without writing off a contract.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Commit to the floor you can prove, layer terms above it, and keep a slice on demand. Coverage is not the goal. Net savings is.
A Reserved Instance discounts a specific instance family in a region, while a Savings Plan discounts a committed dollar per hour spend across broader compute. Savings Plans trade some discount depth for far more flexibility.
Use a Compute Savings Plan where workloads evolve across families or regions, and an EC2 Instance Savings Plan where the family is stable and you want a deeper rate. Many estates run both.
Commit to the stable usage floor, the capacity that runs every hour across a representative period. Never commit to the average, and never to the peak, because both strand capacity when usage shifts.
Use three year terms for the proven floor and one year terms for the predictable middle layer. Keep spiky or uncertain workloads on demand or Spot so no contract outlives the architecture.
Stranded commitments come from committing above the floor and from ignoring utilization after purchase. Refactors and region moves frequently leave maximized coverage buyers paying for capacity they no longer use.
Track utilization and coverage monthly. Utilization below the high nineties means you are paying for unused commitment, which is a signal to rebalance at the next purchase.
Standard Reserved Instances can be sold on the AWS Marketplace resale market, while convertible and Savings Plan commitments cannot. That resale option is one reason narrow, fixed workloads can still suit Reserved Instances.
One central team should own commitment buying across accounts. Decentralized purchasing produces overlapping commitments and waste that no single team can see.
The floor analysis template, the instrument selection matrix, and the coverage governance runbook the buyer side uses to optimize Reserved Instances and Savings Plans.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The discount is real, but so is the lock. Commit to what you can prove runs every hour, and let everything uncertain stay flexible.
