Discount guides quote 30–70% off but never say how much to buy, for how long, or what to do after a wrong call. Three decisions, three escape routes.
Search "AWS discounts" and you get the same list of numbers everywhere: Reserved Instances save 30–70% against on-demand, Savings Plans similar, Spot up to 90%. The numbers are broadly right and almost useless to someone about to spend money.
Because the real decision is not "should I buy" — it is three narrower questions: how much, for how long, and what happens if I get it wrong. This page takes them in that order, each with a decision rule and a concrete action.
Scope note: this is about Reserved Instances (RI). Savings Plans are a different instrument — more flexible, but with no resale exit. The trade-off between them is on Savings Plans vs Reserved Instances. One level up: whether a commitment discount locks the spec differs sharply by provider (reservations lock, savings plans do not) — see cloud discount mechanisms compared.
You are not buying a discount — you are making a cash commitment
Treating an RI as a coupon is where most misjudgements start. What you actually do is promise AWS this much usage, every hour, for one or three years, and AWS gives you a lower unit price. The discount is the price of that promise, not a promotion.
That framing decides three things:
- Under-use and you still pay. Commit to ten instances an hour, run six, and the other four still appear on the bill. Unused commitment is not refunded.
- Over-use and the excess is on-demand. The commitment only covers what it covers; anything above it bills at list price.
- Depth of discount prices certainty. Longer term, more upfront, narrower scope (locked family and region) — all buy a lower rate. The more flexibility you surrender, the better the price.
One line to keep: an RI is not a money-off voucher, it is a contract trading flexibility for unit price. So the first question is never "how much saves the most" but "how much flexibility can I give up with confidence".
And because it is a contract, "what if I got it wrong" deserves a real answer — the part every discount roundup skips. See the section three below.
How much: the answer is your baseline, not your current usage
Almost everyone gets this wrong the same way: committing to whatever is running today. Current usage contains a lot that is actually elastic — nightly batch jobs, nodes that only scale out for campaigns, test environments nobody cleaned up. Locking all of it into a one-year commitment means paying a fixed price for variance.
What you want is the steady baseline: take usage over a long enough window (at least three months, covering a full business cycle), lay it out hour by hour, and find the part that runs essentially every hour. Only that belongs in a commitment.
| Usage type | Signature | Commit or not |
|---|---|---|
| Steady baseline | Runs every hour, low variance (resident web/API nodes) | Commit — this is what RIs are for |
| Cyclical peaks | Higher at fixed times daily or weekly (end-of-day batch) | Partly — only if it happens every single day |
| Occasional scale-out | Appears for launches, load tests, promotions only | Do not commit — leave on demand or Spot |
| Uncleaned idle | Forgotten test instances, unattached volumes | Delete first — not a commitment question |
A practical self-check: draw your commitment as a horizontal line over the last three months of usage. Ideally it hugs the bottom edge of the curve, exceeded only briefly. If it cuts through the middle, you are paying for idle capacity roughly half the time.
One step people skip: do the free clean-up first. Idle instances, unattached EBS volumes, orphaned snapshots, incomplete multipart uploads — clearing those visibly lowers your baseline, so the amount worth committing drops too. It needs no commitment and can be done any time. Do it before you buy; the reverse order locks in a wrong number for a year.
The clean-up checklist and bill breakdown are in six moves for a lower AWS bill.
How long: 1 vs 3 years is not about the discount rate
The reflex is "three years discounts more, so buy three years". That holds only if the shape of your workload is fixed for three years. There are three real judgement points and the discount rate is just one of them.
- Will the instance generation change? Moving x86 to Graviton (ARM) usually saves another chunk without losing performance. If that is plausible inside three years, one year is the better call — a classic RI is tied to instance family, so a Graviton move is not covered by the old commitment.
- Will the region change? Commitments are regional. A move for latency or data-residency reasons leaves the commitment behind.
- How far can the business actually see? Early-stage projects or a customer mix that is still shifting: one year. A system stable for two years already: three years is fair game.
A useful compromise: do not fill three years at once. Cover the baseline with a one-year term, watch the real utilisation and coverage figures AWS reports, then decide next year whether part of it graduates to a longer term. Trading one year of real data for next year's certainty beats betting three years up front.
Do not ignore the coverage metric: after buying, the console reports how much of your usage the commitment actually covered. Persistently low coverage means you over-bought; coverage near 100% alongside heavy on-demand spend means you can add a little. Reading that number monthly beats agonising for hours at purchase time.
If the goal is "do not waste it when the architecture changes", the better instrument is a Compute Savings Plan, which does not lock family or region — at the cost of a shallower discount than an equivalent RI. The comparison is on Savings Plans vs Reserved Instances.
Three payment options: all, partial, no upfront
RIs normally come in three payment shapes: All Upfront > Partial Upfront > No Upfront, with the discount getting shallower as the cash burden moves later.
- All Upfront: pay the whole term once, lowest unit price. Suits healthy cash flow and resources you are certain about.
- Partial Upfront: pay part now, the rest monthly. The middle ground, and the most commonly chosen.
- No Upfront: nothing in advance, billed monthly. Shallowest discount, but almost no financial risk — and often the only option procurement will approve.
The deciding factor is not "which discounts most" but your cost of capital and your process constraints:
- If a lump sum needs budget approval that takes months, waiting a quarter for a few extra points is usually a bad trade.
- If the money has a clear, stable purpose for two years, the extra discount on All Upfront is free money.
- If the company may restructure or shrink, the flexibility of No Upfront is worth far more than the discount gap.
⚠️ The overlooked cost of All Upfront: once the money is paid, under-use becomes a pure sunk cost. Partial and No Upfront at least let you stop further monthly payments when usage falls. When unsure, buy flexibility in the payment shape, not in the term — it costs less.
You got it wrong: three ways out
This is what discount roundups never cover and what most people eventually need. If a commitment is wrong — too large, wrong shape, region needs to move — there are generally three routes, in increasing order of pain.
| Route | When it applies | Cost |
|---|---|---|
| Resell (Reserved Instance Marketplace) | Standard RI you genuinely cannot consume | Sell the remaining term at market price, usually at a discount; requires a supported region and a minimum holding period |
| Modify | Change size / zone / region within the same generation | Some attributes can be changed and the discount recalculated; not every attribute is modifiable |
| Absorb it | Change is outside what is allowed, or resale finds no buyer | Keep paying for unused capacity until the term ends |
Route one: resell. AWS runs an official RI marketplace where unused Standard RIs can be listed. Two hard limits: it generally requires the RI to have been active for a minimum period, and Savings Plans cannot be resold at all. That is the most practical difference between the two instruments — an RI has an exit, a Savings Plan does not.
Route two: modify. Some RIs allow attribute changes — adjusting instance size within a family, or the scope of availability zones. If your problem is "bought too big", check whether a modification is possible before going to market; it is usually less hassle.
The cheapest fix happens before you buy: split a large commitment into several smaller ones over time. If the baseline is ten, buy six, watch for a month, then add two. Batching costs nothing — the unit price is identical — but it keeps every correction option open. Filling the whole thing at once trades all future corrections for a quantity discount that does not exist.
Route three: absorb. When the change is outside what is allowed and resale does not clear, you pay for idle commitment until expiry. The remaining mitigation is to move workload onto what the commitment covers — shift jobs that were running on demand onto the reserved capacity, so the commitment is at least consumed.
What happens on the day it expires
A very common incident: the commitment expires, the bill jumps, and nobody saw it coming. Expiry does not auto-renew and does not announce itself. The rate simply reverts from discounted to on-demand.
- Expiry is not an outage. Resources keep running; only the unit price changes. So the symptom is never "service went down" — it is "this month's bill is noticeably higher".
- Keep an expiry register. Record every commitment end date in one place with reminders at 60 and 30 days. With real volume, that register matters more than any optimisation trick.
- Recompute the baseline before renewing. Expiry is a free correction window — recalculate and buy the new number. Many teams renew "as before" and carry a three-year-old mistake into another term.
One more layer worth separating: everything above is an official discount, acting on the unit price AWS bills. Provisioning and settling through a reseller instead lowers what you actually pay. Different layers, both can apply — it is not either/or. That logic is on AWS discounts and reseller pricing.
Common questions
Reserved Instances or Savings Plans — which should I buy?
It depends which flexibility you can give up. RIs lock instance family and region, usually discount more deeply, and can be resold — they have an exit. Savings Plans lock an amount rather than a specific instance, so they are more flexible in use, but cannot be resold or cancelled. Expect a family or region change: Savings Plans. Shape is settled and you want an exit: RIs. Full comparison on Savings Plans vs Reserved Instances.
Should I commit to peak or to average usage?
Neither. Commit to the baseline — the part running essentially every hour. An average still includes plenty of usage that appears only part of the time; peak is worse. Lay usage out hourly and draw the line along the bottom edge.
Can I get a refund if I over-bought?
RIs are not refundable, but unused Standard RIs can be listed on the official marketplace for the remaining term — at a discount, and usually subject to a minimum holding period. Savings Plans are neither refundable nor resellable; once bought, you hold them to term. That is another argument for starting conservatively.
The three-year discount is much better — why not just buy three years?
Because a three-year term locks not just price but instance family and region. If a move to Graviton, a region change, or a major scale change is plausible inside three years, the extra discount can easily be outweighed by one architectural change that strands the commitment. Judge by how far you can see, not by the size of the gap.
Is there a discount for buying the whole amount at once?
No. The unit price for a given RI does not depend on quantity or on how it is split — five separate purchases and one purchase of five cost the same per unit. So batching has no price cost and keeps correction options open. It is the highest-value suggestion on this page.
Can I stack a reseller discount on top of Reserved Instances?
Yes — they act at different layers. Reserved Instances lower the unit price on the AWS bill; a reseller discount lowers what you actually settle. They do not conflict. See AWS discounts and reseller pricing, and if you are comparing paying AWS directly with going through a channel, AWS direct vs reseller.