Glossary
Every AWS reservation term, defined.
The vocabulary behind Reserved Instances, coverage, and renewals — what each term means, and what it costs or saves you. The same words matter whether you're carrying one reservation or ten thousand.
The commitment
What you're actually agreeing to when you buy a reservation, and the levers that set its discount.
- Reserved Instance (RI)
A 1- or 3-year commitment to a specific instance configuration, in exchange for a discount off the on-demand rate for matching usage.
An RI doesn't reserve capacity or provision anything — it's a billing commitment that applies a discount automatically whenever running usage matches its attributes. Available for Amazon RDS, ElastiCache, and EC2. The discount is real money back on usage you were already going to run; the risk is entirely in choosing the wrong term, class, or letting it lapse unrenewed.
- On-Demand
The standard pay-as-you-go rate, charged on any usage with no matching reservation.
Every AWS resource defaults to on-demand pricing unless a reservation covers it. It's the ceiling, not the going rate — the gap between on-demand and a reservation's discounted rate is what an RI is worth, and it's what you silently fall back to the moment a term ends unrenewed.
- Standard RI
The Reserved Instance type that fixes its instance attributes for the whole term, in exchange for the deepest available discount.
A Standard RI can't change instance family, size, or (for EC2) operating system mid-term — only its own AZ can be modified, or, for EC2, sold early on the RI Marketplace. That rigidity is what buys the extra discount over a Convertible RI. The right choice for any instance family with a stable, multi-year track record in the fleet.
- Convertible RI
An EC2-only Reserved Instance that can be exchanged into a different family, size, OS, or tenancy mid-term, at a shallower discount than Standard.
Convertible RIs trade some discount depth for a mid-term escape hatch — useful for an instance family that might resize or migrate before the term ends. RDS and ElastiCache reservations have no convertible option; term and payment option are the only levers there, so the family/engine choice at purchase is final either way.
- Term (1-year / 3-year)
The length of the commitment — 1 or 3 years — and the single biggest lever on how deep the discount goes.
A 3-year term is almost always the deeper discount, because you're trading more certainty for AWS. Whether that trade is worth it is a separate question: it depends on whether the instance family will still be running that long, not on the discount alone.
- Payment option
How much of the term's cost is paid upfront — No, Partial, or All Upfront — trading cash now for a deeper discount.
All Upfront buys the deepest discount for a given term by paying the full commitment on day one; No Upfront pays nothing upfront for the shallowest discount, spread into the hourly rate instead; Partial Upfront sits between the two. None of the three change what's eligible to be reserved — only the cash-flow shape of paying for it.
- Effective hourly rate
The true hourly cost of a reservation once any upfront payment is amortized across the whole term.
An All Upfront RI has an effective hourly rate even though $0 is billed hourly — the upfront cash divided across the term's hours, plus any recurring hourly fee. It's the number that makes term and payment option comparable side by side, and the one break-even math is built from.
- Break-even
The day an upfront reservation cost catches up to what on-demand usage would have cost over the same period — every day after is pure savings.
Any reservation with cash paid upfront starts the term "behind," since that money could have paid on-demand rates instead. Break-even is where the two lines cross; a shorter break-even means the reservation is de-risked sooner, which matters most for instance families with any chance of resizing or retiring before term end.
Scope & flexibility
The dimensions a reservation has to match exactly — and the few ways AWS lets it flex.
- Instance family & class
The specific hardware shape a reservation is bound to, e.g. db.r6g.xlarge — the first thing that has to match for a discount to apply.
Family (r6g) is the generation and processor line; class (xlarge) is the size within it. A reservation only discounts usage that matches its family, and — wherever size flexibility doesn't apply — its exact class too. Getting the family wrong at purchase is the most common way a reservation ends up covering nothing, because no amount of size flexibility crosses a family boundary.
- Size flexibility (normalization factor)
A Reserved Instance feature that lets one reservation's discount apply proportionally across different sizes within the same instance family.
Each size in a family carries a normalization factor (an xlarge is worth 2 of a large, for example); size flexibility applies the RI's discount to any mix of sizes in the family whose combined factor matches what was bought. EC2 Standard RIs get it at regional scope on default tenancy. RDS gets it too, within the same instance class type and across Single-AZ and Multi-AZ, on Db2, MariaDB, MySQL, Oracle BYOL and PostgreSQL — but not on SQL Server or Oracle License Included. ElastiCache reserved nodes have none of it: node type must match exactly.
- Regional vs Zonal RI
Whether a reservation's capacity applies anywhere in a region (Regional) or is pinned to one Availability Zone (Zonal).
A Regional RI is the more flexible choice — its discount (and, for EC2, a capacity reservation) follows matching usage to any AZ in the region, with size flexibility still available. A Zonal RI locks in a specific AZ, which also reserves actual capacity there — useful when a workload can't tolerate an AZ-level capacity shortfall, at the cost of that flexibility.
- Scope
The region or Availability Zone a reservation's discount is bound to.
Scope is set once, at purchase, and (for Standard RIs) is one of the only attributes that can later be modified without a full exchange. Getting scope wrong — reserving in a region or AZ that doesn't match where the fleet actually runs — produces a reservation with a discount and nothing running underneath it to claim it.
- Platform / engine
The operating system (EC2) or database engine (RDS) a reservation is bound to, alongside instance class and region.
For RDS, engine — MySQL, PostgreSQL, and the rest — is the hardest dimension of all: a reservation for one engine never discounts another, no matter the size. (Deployment option is the exception, not the rule — the benefit moves freely between Single-AZ and Multi-AZ on the size-flexible engines.) For EC2, Convertible RIs are the one type that can exchange platform mid-term; Standard RIs and every RDS/ElastiCache reservation are locked to the platform or engine that was bought.
Coverage & utilization
The numbers that tell you whether your reservations are actually doing their job.
- Coverage
The % of reservable running capacity currently matched to a reservation you own.
Take everything running that AWS lets you reserve, and ask how much of it is matched to a reservation right now — that share is coverage. Usage below 100% coverage is paying the on-demand premium on something that could be discounted; usage can't exceed 100%, so more reservations than reservable usage just sit unmatched.
- Utilization
The % of a reservation's own capacity that's actually being claimed by matching running usage.
Coverage looks from the fleet's side (how much of what's running is discounted); utilization looks from the reservation's side (how much of what was bought is being used). A reservation with low utilization is still costing its full price while discounting little or nothing — the failure mode that shows up when a family shrinks, moves region, or is retired mid-term.
- Reservable usage
The slice of running usage that's actually eligible to be matched to a reservation — the denominator coverage is measured against.
Not everything running qualifies: short-lived or serverless usage, for instance, was never a candidate for a reservation. Coverage is measured only against this reservable slice, so the number stays an honest read on reservation performance rather than diluted by usage that could never have been covered.
The extra you pay, per hour, on reservable usage that isn't currently covered by a reservation.
It's the gap between the on-demand rate and what the same usage would cost under a matching reservation — silent, ongoing, and easy to miss because nothing in the AWS console flags it. It accrues on any coverage gap, whether that gap is a family that was never reserved or a term that lapsed unrenewed.
- Blended rate
The average effective rate across a mix of on-demand and reserved usage for the same instance class.
When coverage sits below 100%, the class's actual cost is a blend of the discounted reserved rate and the full on-demand rate on the uncovered remainder. It's the number that shows up on the bill; effective hourly rate, by contrast, describes a single reservation in isolation.
Renewals & lifecycle
What happens at term end, why it slips, and the ways to move on from a reservation early.
- Term end / expiry
The moment a reservation's 1- or 3-year commitment ends and its discount stops applying.
Nothing about the running instance changes at term end — it doesn't restart, stop, or degrade. What changes is price: usage that was covered reverts to the on-demand rate at that instant, whether or not anyone notices.
- Renewal
Buying a new reservation to replace one that's ending — a manual, deliberate purchase, since AWS has no auto-renew for RIs.
A renewal is not a continuation of the old reservation; it's a brand-new purchase decision, with its own term and payment-option choice, ideally made before the old one expires so coverage never gaps. Nothing in AWS prompts this — it has to be tracked and acted on.
- Renewal cliff
The silent jump from a reservation's discounted rate to the full on-demand rate the instant its term ends unrenewed.
Reserved Instances are the biggest, most boring discount in cloud, with one failure mode: they don't renew themselves. The renewal cliff catches disciplined teams just as often as sloppy ones, because it's a calendar problem, not a technical one — the fix is tracking expiry dates, not better infrastructure.
- Modification / exchange
The two ways to change a reservation mid-term: modification adjusts a few attributes on a Standard RI; exchange swaps a Convertible RI for a different one entirely.
Modification is narrow — AZ, scope, or (for EC2, with size flexibility) instance size within the same family — and available on Standard RIs at no cost. Exchange is available only on Convertible RIs, and can change family, size, OS, or tenancy outright, provided the new RI's value is equal to or greater than what's being exchanged.
- RI Marketplace
AWS's resale market for the unused portion of an EC2 Standard RI's term — the one way to exit a reservation early instead of letting it sit unused.
Only EC2 Standard RIs qualify, and only for the remaining term; Convertible RIs and every RDS/ElastiCache reservation have no resale option. It's a safety valve for a reservation bought against a family that turned out to be short-lived, not a routine part of the purchase decision.
Beyond RIs
The rest of AWS's reservation-shaped discounts — where they overlap with RIs and where they don't. AWS-only, RI-only today: OpenSearch, Redshift, and other clouds are roadmap, not shipping.
- Compute Savings Plan
A spend-based commitment (dollars/hour) that discounts EC2, Fargate, and Lambda usage automatically, regardless of instance family or region.
Unlike an RI, a Compute Savings Plan doesn't lock in an instance class at all — the discount follows whatever qualifying compute usage lands, wherever it lands, for the life of the term. It never covers RDS or ElastiCache, and it shares an RI's exact failure mode: no auto-renew, silent reversion to on-demand at term end.
- EC2 Instance Savings Plan
A narrower Savings Plan variant: a spend commitment to one instance family in one region, with a discount depth closer to a Standard RI's.
It trades the Compute Savings Plan's cross-service flexibility for a deeper discount, in exchange for staying pinned to a single family and region — a middle ground between an RI's rigidity and a Compute Savings Plan's full flex. Like every reservation-shaped commitment here, it doesn't auto-renew.
- Reserved DB instance (RDS)
The Reserved Instance for Amazon RDS — the same 1-/3-year, discount-for-commitment mechanics as EC2, applied to a database engine and deployment option instead of an OS.
RDS reservations have no convertible option and no marketplace resale — term and payment option are the only two levers, and the engine is fixed for the term. Size is more forgiving than people expect: on Db2, MariaDB, MySQL, Oracle BYOL and PostgreSQL the benefit applies across sizes within the same instance class type, and across Single-AZ and Multi-AZ, by normalized units. The published ceiling is up to 69% off on-demand, the same order of magnitude as EC2's up to 72%.
- Reserved node (ElastiCache)
The Reserved Instance for Amazon ElastiCache — the same commitment mechanics, applied to a cache node type, with a lower published discount ceiling than EC2 or RDS.
Reserved nodes cap out at up to 55% off on-demand, the smallest of the three services Reserver covers today. Like RDS, there's no convertible option and no resale — and the same silent renewal cliff at term end.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list and we'll onboard you as capacity opens up — first recommendation within minutes of connecting.