Commitment discounts are the least glamorous cost lever and the one most often bought wrong, because the decision looks like a procurement checkbox and behaves like a leveraged bet. You are trading flexibility for a lower rate, and if the usage you bet on disappears, the commitment does not — you keep paying. Getting this right is less about picking "Savings Plans or RIs" and more about understanding how the discount is applied each hour and how much of your baseline you can honestly promise to run for one to three years.
How the discount is actually applied
Both Savings Plans (SPs) and Reserved Instances (RIs) work the same way at billing time, and it is not "these specific instances are cheaper now." Every hour, AWS's billing engine looks at all your eligible usage and applies your commitments to it, prioritizing the usage with the highest On-Demand rate first so your dollar of commitment absorbs the most expensive usage it can. RIs are matched before Savings Plans; then a Compute or EC2 Instance SP's committed dollars-per-hour are applied against remaining eligible usage at the discounted SP rate until the commitment is used up.
Two consequences fall out of this that people miss:
- The discount floats to your usage. A Compute Savings Plan does not care which instances you run; if you shut down the
c6ifleet it was covering and spin upm7ginstead, next hour the same committed dollars flow to the new usage. The commitment is to spend, not to machines. - Coverage is per hour, not per month. If you commit $10/hour and one hour only has $7/hour of eligible usage, the other $3 is simply wasted that hour — there is no monthly averaging that lets a busy hour make up for a quiet one. This is why a steady baseline matters far more than total volume.
The four instruments, by flexibility
They form a spectrum from "most flexible, smaller discount" to "most rigid, largest discount."
- Compute Savings Plans — commit to a dollars/hour of compute spend for 1 or 3 years. Applies across EC2 instance family, size, region, OS, tenancy, and Fargate and Lambda. Up to ~66% off. The most flexible instrument; almost nothing you do operationally can strand it short of using less compute overall.
- EC2 Instance Savings Plans — commit to dollars/hour within one instance family in one region (say,
minus-east-1). Flexible across size, OS, and AZ inside that scope. Up to ~72% off. More discount, but now you are betting on a specific family and region. - Standard RIs — reserve a specific instance type; flexible on AZ and, within the same family, instance size, but not across families. Up to ~72% off. Can be sold on the Reserved Instance Marketplace, and zonal RIs also grant a capacity reservation.
- Convertible RIs — like standard RIs but exchangeable for a different family, OS, or tenancy mid-term. Up to ~66%. You trade some discount back for the right to change your mind.
The trend for general fleets is toward Compute Savings Plans, precisely because they survive the two things that keep happening to modern infrastructure: migrating families (x86 to Graviton) and moving to Fargate or Lambda. RIs still earn their place when you specifically want a capacity reservation, or when you have a genuinely fixed, long-lived instance type.
Commitment and utilization risk
The risk is symmetric to the reward. Your utilization is the fraction of your committed dollars actually absorbed by eligible usage each hour, averaged over the term. Buy a commitment that sits at 100% utilization and you captured the full discount. Buy one that averages 80% and your effective discount is roughly 80% of the sticker discount, because you paid for 20% of the commitment that hit nothing.
This is why the honest sizing target is not your average usage and definitely not your peak — it is the floor you are confident you will always be running. If your compute usage over a representative month never drops below, say, $6/hour of On-Demand-equivalent, that $6 is the part you can commit with near-100% utilization. Everything above it is variable and should stay uncommitted.
Why you layer, not commit 100%
Picture your usage as a stack, from bottom to top:
- The always-on baseline at the bottom — the floor that never goes away. Cover this with a Savings Plan (or RIs) at the deepest 1-3yr rate. It runs 24/7 for years; commit it hard.
- The variable-but-predictable middle — daytime scaling, weekday load. Cover some of this with a shorter or no-upfront commitment if the pattern is stable, but keep utilization honest.
- The bursty top — spikes, batch, anything interruptible. Run this on Spot (up to ~90% off with no commitment) and On-Demand for the un-interruptible remainder. You never want a multi-year commitment sized to a spike that exists four hours a week.
Committing 100% of peak looks like maximum savings on the spreadsheet and produces the worst real outcome: months of low utilization on the commitment that covered usage which was not there. The layered approach captures the deep discount where it is safe and lets Spot and On-Demand absorb the variance for free.
A worked example
Assume a steady baseline of compute that would cost $10.00/hour at On-Demand, and illustrative Compute Savings Plan rates (real rates vary by region, family, and term — check the current numbers before you buy):
On-Demand (no commitment)
$10.00/hr x 8,760 hr = $87,600 / year
1-year, no-upfront Compute SP (~54% off -> $4.60/hr effective)
$4.60/hr x 8,760 hr = $40,296 / year
saving vs On-Demand = $47,304 / year, no cash tied up
3-year, all-upfront Compute SP (~64% off -> $3.60/hr effective)
$3.60/hr x 8,760 hr = $31,536 / year
paid once, up front = $94,608 for the 3-year term
saving vs On-Demand = $56,064 / year
The 3-year all-upfront wins by roughly $15,800/year over the 1-year no-upfront, and that gap is the real question. You are being paid about $47k extra over three years to give up two things: flexibility (you are locked for 36 months) and the time value of ~$95k in cash paid on day one instead of hourly. If you are confident the baseline survives three years, take it. If there is a real chance you re-platform, get acquired, or that team's product sunsets, the 1-year no-upfront keeps almost all the savings while letting you re-decide every twelve months. A common middle path is 3-year no-upfront, which keeps most of the discount without the cash outlay.
How a wrong commitment becomes stranded cost
The failure mode is concrete. Say you commit $10/hour to an EC2 Instance Savings Plan on the c5 family, then eight months in a team migrates half that workload to Graviton c7g. Now only $5/hour of eligible c5 usage exists, but you still owe $10/hour of commitment. That $5/hour delta bills anyway, for the remaining 28 months — roughly $102,000 of pure stranded cost, paying for a discount on usage that no longer exists. Standard RIs on a decommissioned family behave the same way.
This is the strongest practical argument for Compute Savings Plans over the narrower instruments: because a Compute SP floats across family, region, and even Fargate/Lambda, the Graviton migration above would have simply re-pointed the same commitment at the new c7g usage with zero stranding. Convertible RIs give you an escape hatch too, via exchange. The rigid instruments earn their extra few points of discount only when you are genuinely certain the underlying shape will not move — and infrastructure, over a three-year horizon, almost always moves.