Reserved Instances vs Savings Plans vs Spot — Which and When

On-demand is the price you pay for not deciding anything. Every other AWS commitment model is you trading some flexibility for a discount, and the whole game is figuring out how much flexibility you can afford to give up on which slice of your fleet. Get that split right and you knock 30-50% off compute without touching a single workload. Get it wrong and you either overspend or lock yourself into instance families you outgrow in six months.

Here is how the four models actually behave, and the order we reach for them.

The models, plainly#

On-demand. Full price, zero commitment, cancel anytime. This is the baseline everything else is measured against. It exists to absorb spikes and to run things you can't predict. If a big chunk of your steady-state fleet is on-demand, you're leaving money on the table.

Reserved Instances. The old-school commitment. You promise to run a specific instance type in a specific region (or AZ) for one or three years, and AWS discounts it.

• Standard RIs give the deepest cut, roughly 40% for one year and up to about 72% for three. The catch: they're locked to an instance family. You can resize within the family and sell unused ones on the Marketplace, but you can't convert an m5 reservation into a c6i.
• Convertible RIs let you swap instance families, OS, and tenancy during the term. You pay for that with a shallower discount, closer to 45-54% at three years.

RIs still matter, but for plain EC2 most teams no longer buy them. Savings Plans do the same job with less rigidity.

Savings Plans. You commit to a dollar-per-hour spend rather than to specific instances. Two flavors:

• Compute Savings Plans apply across EC2, Fargate, and Lambda, in any region, any instance family, any size. Maximum flexibility, discount up to roughly 66% at three years.
• EC2 Instance Savings Plans lock you to one instance family in one region but let you move across size, OS, and AZ. Less flexible, deeper cut, up to about 72% at three years.

The pattern repeats: the more you pin down, the more AWS pays you for the certainty.

Spot. Spare capacity, sold at 60-90% off on-demand, and AWS can reclaim it with a two-minute warning. No commitment, no term. The discount is enormous and the string attached is real: your workload has to tolerate being killed mid-run. For the mechanics of bidding, diversification, and draining nodes, we wrote a separate piece on spot instances.

Term and payment: the two dials#

Every RI and Savings Plan has two knobs.

Term: one year or three. Three-year commitments deepen the discount by roughly 15-20 percentage points, but three years is a long time in infrastructure. Graviton alone rewrote a lot of fleets. Our rule: three-year only on workloads whose shape is stable, even if the code isn't. Databases, core services, anything you'd bet still exists in 2029. One-year for everything else.

Payment: all-upfront, partial-upfront, or no-upfront. All-upfront squeezes out a few extra points, usually 1-3%, in exchange for handing AWS the cash now. Unless your finance team specifically wants to spend the capital, no-upfront captures almost the entire discount while keeping the money in your account. We default to no-upfront and only go all-upfront when someone with a budget cycle asks for it.

Coverage vs utilization#

Two numbers tell you whether your commitments are healthy, and people constantly confuse them.

• Coverage is what fraction of your eligible usage is sitting under a discount instead of on-demand. Low coverage means you're overpaying.
• Utilization is what fraction of the commitment you actually consumed. Low utilization means you over-committed and are paying for hours you didn't use.

You want high coverage and high utilization, and they pull against each other. Buy aggressively and utilization drops the first time usage dips. Buy timidly and coverage stays low. The sweet spot: commit to your reliable floor, the usage you're confident you'll run 24/7 for the whole term, and let everything above it ride on-demand or Spot. Target something like 80% coverage of steady-state and near-100% utilization. Chasing 100% coverage is how you end up stranded on a reservation for a service you deleted.

How to layer them#

We think of the fleet as a stack, bottom to top:

1. Savings Plans for the baseline. Whatever runs around the clock, cover it with a Compute Savings Plan. Start there for the flexibility; move the truly stable core to EC2 Instance Savings Plans or Standard RIs later to squeeze the last few points once you trust the shape.
2. Spot for the interruptible middle. Batch jobs, CI runners, stateless web tiers behind an ASG, big-data workers, dev and staging. Anything that can lose a node and shrug.
3. On-demand for the spiky top. Traffic surges, launches, the unpredictable. This is what on-demand is for. Don't feel bad about it.

Do it in that order. Commitments are cheapest to get right when they sit under known, flat demand.

A decision framework#

Run each workload through three questions:

• Can it survive a two-minute eviction? Yes, and it's not trivially small, then Spot. This is the biggest lever, so start here.
• Is the remaining usage steady 24/7 for at least a year? Yes, then cover it with a Savings Plan. Flexible needs, Compute plan; rock-solid and single-family, EC2 Instance plan or Standard RI for the extra points.
• Is it spiky or short-lived? On-demand, and stop optimizing it.

That is most of the job. The rest is watching coverage and utilization drift and topping up quarterly.

A worked example#

Say you run a steady 100 vCPU baseline plus a 60 vCPU batch tier that runs nightly and tolerates interruption, on-demand list around $0.04/vCPU-hour.

• Batch tier on Spot at ~70% off: 60 vCPU that would cost ~$1,730/mo drops to ~$520.
• Baseline 100 vCPU on a 1-year no-upfront Compute Savings Plan at ~40%: ~$2,880 falls to ~$1,730.
• Keep ~20 vCPU of headroom on-demand for spikes: ~$576.

All-on-demand for the same work runs about $5,180/mo. Layered, you land near $2,830 — roughly a 45% cut, with the flexible Compute Savings Plan meaning you can move families as Graviton or newer generations land. Nothing here is locked for three years, and nothing critical is riding Spot.

If you want the field-tested version of this same split, with real percentages and the mistakes made getting there, see AWS Reserved Instances vs Savings Plans vs Spot — when each fits.

For the wider picture of where the rest of your bill hides, we keep a running cloud cost optimization guide.

The call we'd make#

Cover your 24/7 floor with a one-year no-upfront Compute Savings Plan, push everything interruptible onto Spot, and leave the spiky top on on-demand without apology. Only reach for three-year terms or EC2 Instance plans on the handful of workloads whose shape you'd bet your job on. Flexibility is worth more than the last few discount points almost every time, because the thing that kills these deals is not a bad price — it's committing hard to a fleet that no longer exists a year later.