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, it can be 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, with every day after 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 gained it too, as of October 2024: a reserved node discounts any size in the same family, region, and engine.
- Previous-generation family
An instance family AWS has replaced with a newer, usually cheaper family, such as m5 superseded by m8g.
AWS keeps releasing instance families with a better price for the same work, and a 1- or 3-year Reserved Instance does not track that release. An EC2 Convertible RI can exchange into the new family at no fee. An EC2 Standard RI can only modify a few attributes, never family, so the RI Marketplace is the sole exit. RDS and ElastiCache reservations offer neither, so the reservation rides out its full term on the old family.
- 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
Coverage and utilization are the two levers that, alongside discount depth, roll up into Effective Savings Rate: the one number that tells 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. That's 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.
- On-demand-equivalent cost (ODE)
What your fleet's usage would cost with nothing reserved, the baseline every savings percentage is measured against.
AWS Cost Explorer and the Cost and Usage Dashboard surface this natively, alongside amortized cost, for exactly this comparison. It's a hypothetical, not a bill you'd ever pay. Its only job is to be the denominator that turns "how much did reservations save" into a percentage.
- Amortized cost
What you actually pay once every reservation's upfront and hourly cost is spread evenly across its term.
An All Upfront reservation bills $0 hourly, but amortized cost still assigns it an even daily charge for the whole term: the same trick effective hourly rate applies to a single reservation, run across the entire fleet. Comparing amortized cost to on-demand-equivalent cost over the same period is where Effective Savings Rate comes from.
- Effective Savings Rate (ESR)
The % saved off on-demand-equivalent cost once coverage, discount depth, and utilization are all priced in, the FinOps industry's standard output metric for rate optimization.
ESR = 1 − amortized cost / on-demand-equivalent cost, which reduces to coverage × [1 − (1−discount)/utilization]. It's the one number coverage alone can't produce: two fleets can share a coverage percentage and land on very different ESR, because discount depth and utilization move it just as much. A renewal lapse shows up here too, priced in real points and dollars, not hand-waved.
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.
- Queued purchase
A Reserved Instance or Savings Plan purchase you schedule ahead, which AWS completes on the date you set if the price hasn't changed.
AWS lets you queue an EC2 Regional RI or a Savings Plan purchase up to three years ahead, at a price capped when you queue it. If that price rises before the date, the purchase does not complete, and nothing alerts you. Zonal RIs, Marketplace RIs, RDS reservations, and ElastiCache reservations cannot be queued at all; buying one of those means buying it right now.
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 56% 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.
Multi-account & organizations
How a reservation's discount behaves once more than one AWS account, or more than one AWS Organization, is in the picture.
- Discount sharing
AWS's default behavior of applying a Reserved Instance or Savings Plans discount to any account on the same consolidated bill, not just the account that bought it.
Sharing is on by default for every account in an AWS Organization. A Regional RI's discount, and a Savings Plan's, discounts matching usage in a sibling account automatically. Turning sharing off is a management-account-only setting, per account or for all of them. AWS itself warns that turning it off can raise an account's monthly bill.
- Payer account
The account in an AWS Organization's consolidated bill that every member account's usage and Reserved Instance discounts roll up into.
Coverage measured inside one member account can read wrong. A discount it's using, or one it bought, can belong to a different account entirely. The payer account's own view, rolled up across every member account, is the only one that reflects the true picture.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list and we'll onboard you as capacity opens up. Your first recommendation lands within minutes of connecting.