AWS Reserved Instances reach the deepest discount, up to 72 percent off on-demand for 3-year all-upfront Standard RIs, while Compute Savings Plans top out near 66 percent but apply across any instance family, region, and operating system. Reserved Instances win on price for stable, known workloads; Savings Plans win on flexibility for changing ones. The right choice depends entirely on how predictable your instance mix is over the commitment term, and most enterprises end up using both in a deliberate coverage stack rather than choosing one outright.
What each commitment actually is
A Reserved Instance is a billing commitment to a specific instance configuration, instance family, region, operating system, and tenancy, for a one-year or three-year term, in exchange for a discount against on-demand pricing. Standard RIs deliver the deepest discount but lock the configuration for the full term. Convertible RIs allow you to exchange for a different configuration during the term, at a lower discount and with the friction of managing the exchange. An RI is not a reservation of physical capacity in the common case; it is a billing instrument that applies a discounted rate to matching usage.
A Savings Plan is a commitment to a steady amount of compute spend, measured in dollars per hour, for one or three years. Compute Savings Plans apply automatically across EC2, Fargate, and Lambda regardless of family, region, or operating system. EC2 Instance Savings Plans commit to a family in a region for a deeper discount than Compute Savings Plans but less than the freedom of the Compute variant. Both Savings Plan types apply their discount automatically to the highest-rate eligible usage first, then cascade down, which removes the manual matching that RIs once required. The wider commercial structure these sit inside is documented in our AWS Enterprise Agreement and EDP pillar.
The historical context matters. AWS introduced Savings Plans in 2019 specifically to address the operational burden of Reserved Instances, the constant rebalancing, exchanging, and Marketplace selling that RI management demanded. Savings Plans were the answer to RI complexity, which is why for most new commitments the real question is which Savings Plan type to use, with Standard RIs reserved for the narrow cases where their deeper discount or capacity reservation genuinely matters.
Discount depth compared
The discount ladder is consistent across both instruments: the more you lock down, the deeper the discount. Standard RIs at three-year all-upfront sit at the bottom of the price ladder and the top of the savings ladder. Compute Savings Plans sit higher on price because they buy flexibility. Payment option also moves the number: all-upfront beats partial-upfront beats no-upfront, with a few points of spread between them.
| Commitment | Max discount (3yr, all upfront) | Flexibility | Exchange / cancel |
|---|---|---|---|
| Standard Reserved Instance | up to 72% | Locked family, region, OS | Sell on RI Marketplace only |
| Convertible Reserved Instance | up to 66% | Exchange for equal-or-higher value | Exchange, no cancel |
| EC2 Instance Savings Plan | up to 72% | Within a family and region | No exchange or cancel |
| Compute Savings Plan | up to 66% | Any family, region, OS, Fargate, Lambda | No exchange or cancel |
The 6-point gap between Standard RIs and Compute Savings Plans is the price of flexibility, and it is almost always worth paying for a changing estate. A Standard RI locked to a machine family you abandon mid-term is a stranded commitment that delivers zero value, while a Compute Savings Plan follows your workload across families and regions. The deeper RI discount only wins when the instance mix is genuinely stable for the full term, which fewer estates can honestly claim than commit to.
The numbers above are ceilings, not typical outcomes. The realized discount depends on the machine family, the region, the payment option, and how well the commitment matches actual usage. A commitment that covers 100 percent of a workload at a 60 percent rate beats one that covers 70 percent at a 72 percent rate, because the uncovered portion runs at full on-demand. Coverage and utilization, not the headline rate, decide the effective saving.
Flexibility and stranded-commitment risk
The core risk with Reserved Instances is stranded commitment. A Standard RI bound to a specific family cannot follow a workload that re-architects onto a newer instance generation or migrates to a different region. The commitment continues to bill while delivering no coverage, and the only escape is the RI Marketplace, where a buyer sells unwanted RIs at a discount to the remaining value, often recovering only part of the outlay. Convertible RIs mitigate this through exchange, but at a lower discount and with the administrative friction of managing exchanges across an estate.
Savings Plans remove the stranding risk for compute by committing to spend rather than configuration. As workloads move across families and regions, the Savings Plan discount follows automatically with no exchange to manage. The trade-off is that neither Savings Plans nor most RIs can be cancelled, so over-committing to a baseline that later shrinks leaves unused commitment in both models. The discipline is to commit only the spend floor you are confident will persist for the full term, and to cover the variable layer with shorter or more flexible instruments. See AWS Savings Plans for the full mechanics.
One genuine RI advantage survives the flexibility argument: zonal Reserved Instances can reserve capacity in a specific Availability Zone, which Savings Plans do not. For workloads that must guarantee capacity for scaling events or disaster recovery in a constrained instance type, a zonal RI buys an insurance that no Savings Plan offers. This is a narrow case, but where it applies it is decisive.
A worked coverage example
Consider an estate spending $1,000,000 per year on EC2 across a mix of always-on production, steady-state batch, and spiky development workloads. A naive approach commits the full $1,000,000 to a three-year Standard RI portfolio at 72 percent, but development load that disappears in month eight strands a quarter of that commitment, dragging the effective discount down sharply.
The disciplined approach segments the spend. The $600,000 always-on production floor goes to a three-year Compute Savings Plan at roughly 60 percent, following the workload as families evolve. The $250,000 steady batch on a mature family goes to a three-year EC2 Instance Savings Plan or Standard RI near 70 percent. The remaining $150,000 of spiky development stays on on-demand, where paying full rate on transient load beats stranding a commitment. The blended outcome captures most of the available discount while carrying almost no stranded-commitment risk, which a single-instrument approach cannot match.
Layering with EDP and on-demand
Both commitments layer beneath an AWS Enterprise Discount Programme. The EDP discount applies to net spend after RI or Savings Plan discounts, so the reductions compound rather than add. A 20 percent EDP discount on top of a 55 percent Savings Plan produces roughly a 64 percent effective reduction, not 75 percent. The compounding math is the same for RIs and Savings Plans and is detailed in the EDP pillar.
The practical approach for a large estate is the coverage stack from the worked example: commit the stable, always-on baseline with the deepest instrument it tolerates, cover the variable middle with Compute Savings Plans, and leave the spiky top on on-demand. The buyer-side discipline is to size each layer against real utilization data, not against a sales projection, and to revisit the stack each quarter as the workload mix shifts. This is core to our AWS optimization work, where commitment coverage is modeled from billing data rather than forecast.
Common commitment mistakes
Four mistakes recur. The first is over-committing on a forecast that includes growth which has not yet materialized, stranding commitment when the growth slips. The second is buying Standard RIs on a family the estate is actively migrating away from, the classic stranded-commitment trap. The third is ignoring payment-option economics, paying no-upfront when the cash position would have supported all-upfront and captured several more points of discount.
The fourth, and most common in practice, is treating commitment as a one-time annual purchase rather than a continuous coverage discipline. Workloads change weekly; a commitment portfolio reviewed once a year drifts out of alignment and leaves both uncovered on-demand spend and stranded commitment at the same time. The estates that capture the most discount review coverage monthly and adjust the variable layer accordingly.
Term length and payment options
Both instruments come in one-year and three-year terms, and the term choice is its own discount lever. The three-year term roughly doubles the one-year discount on the same commitment, but it doubles the exposure to workload change, instance-generation refreshes, and AWS pricing moves. For a stable production floor the three-year term is the clear economic choice; for anything uncertain, the one-year term preserves optionality at a known cost. Many estates ladder their commitments, buying a mix of one-year and three-year terms that expire on a staggered schedule so no single renewal forces a large all-or-nothing decision.
Payment option moves the number again. All-upfront captures the deepest discount, partial-upfront a little less, and no-upfront the least, with a few points of spread between them. The right choice is a treasury decision as much as a procurement one: an estate with the cash and a stable baseline captures the extra points with all-upfront, while one that prefers to preserve cash flow accepts a slightly shallower discount for monthly billing. The discount differential should be weighed against the internal cost of capital, not taken automatically.
The interaction of term and payment with coverage is where most savings are won or lost. A three-year all-upfront commitment sized to a baseline that proves too aggressive strands cash that cannot be recovered, while a conservative one-year no-upfront commitment leaves discount on the table on spend that was always going to persist. Modeling the floor from at least twelve months of billing data, then committing to it with the deepest term and payment the floor can safely bear, is the discipline that separates a well-run commitment portfolio from a guessed one.
The verdict: choose RIs or Savings Plans
Choose Reserved Instances when your instance mix is stable and well understood for the full term, the workload runs on a mature instance family you will not abandon, you want the absolute deepest discount, you can manage the configuration lock, or you need the zonal capacity reservation only an RI provides. Standard RIs at three-year all-upfront are the cheapest compute AWS sells for a workload that genuinely will not change.
Choose Compute Savings Plans when your estate is migrating, re-architecting, or otherwise changing, you value the freedom to move across families and regions, and you accept a few points of discount in exchange for eliminating stranded-commitment risk and the operational burden of RI management. For most enterprises with evolving estates, Compute Savings Plans are the safer default, with EC2 Instance Savings Plans or Standard RIs reserved for the stable baseline and zonal capacity needs. The honest answer for a large estate is rarely one or the other; it is a deliberate stack that uses each instrument where its economics are strongest.
For the surrounding framework, see the AWS EDP pillar, AWS Savings Plans, GCP CUD vs AWS Savings Plan, AWS vs Azure vs GCP pricing, and the AWS vendor hub. For help structuring a coverage stack, see AWS optimization or cloud contract negotiation.