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 agree to when you buy a reservation, and the levers that set its discount.
- Reserved Instance (RI)
A 1- or 3-year commitment to one instance configuration that earns a discount off the on-demand rate.
An RI is a billing commitment. It applies its discount automatically when running usage matches its attributes. RIs exist for Amazon RDS, ElastiCache, and EC2. The discount is real money back on usage you already run. The risk is a wrong term or class, or a lapse with no renewal.
- On-Demand
The standard pay-as-you-go rate, charged on any usage that has no matching reservation.
Every AWS resource uses on-demand pricing unless a reservation covers it. This is the highest rate you pay. The gap between on-demand and a reservation's rate is what an RI is worth. It is also the rate you fall back to when a term ends unrenewed.
- Standard RI
The Reserved Instance type that fixes its instance attributes for the whole term and gives the deepest discount.
A Standard RI cannot change instance family, size, or (for EC2) operating system mid-term. You can change its AZ. For EC2, you can also sell it early on the RI Marketplace. This rigidity buys the extra discount over a Convertible RI, a median of about 15% across the priced EC2 catalog. Choose it for an instance family with a stable, multi-year record in the fleet. Price the trade for your own instance with the free <a href="/convertible-check">Convertible Check</a> tool.
- Convertible RI
An EC2-only Reserved Instance you can exchange mid-term for another family, size, OS, or tenancy, at a shallower discount.
A Convertible RI gives up some discount for a mid-term escape hatch. It helps when an instance family 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 or engine you pick at purchase is final. The free <a href="/convertible-check">Convertible Check</a> tool prices the premium against the chance that you need to change.
- Term (1-year / 3-year)
The length of the commitment, 1 or 3 years, and the biggest lever on how deep the discount goes.
A 3-year term almost always gives the deeper discount. You give AWS more certainty in return. Ask whether the instance family will still run that long, because the discount alone cannot tell you.
- Payment option
How much of the term's cost you pay upfront (No, Partial, or All), where more cash buys more discount.
All Upfront pays the full commitment on day one and gives the deepest discount for a given term. No Upfront pays nothing upfront and gives the shallowest discount, because the cost moves into the hourly rate. Partial Upfront sits between the two. None of the three changes what you can reserve. They change only how you pay for it.
- Effective hourly rate
The true hourly cost of a reservation after any upfront payment is spread across the whole term.
An All Upfront RI has an effective hourly rate even though AWS bills $0 hourly. It is the upfront cash divided across the term's hours, plus any recurring hourly fee. This number makes term and payment option comparable side by side. Break-even math starts from it.
- Break-even
The day an upfront reservation cost catches up with what on-demand usage would have cost, then every day saves.
A reservation with cash paid upfront starts the term behind. That money could have paid on-demand rates instead. Break-even is where the two lines cross. A shorter break-even removes the risk sooner. This matters most for instance families that might resize or retire before term end.
Scope & flexibility
The dimensions a reservation must match exactly, and the few ways AWS lets it flex.
- Instance family & class
The hardware shape a reservation is bound to, such as db.r6g.xlarge, which must match first.
The family (r6g) is the generation and processor line. The class (xlarge) is the size within it. A reservation discounts only usage that matches its family. Where size flexibility does not apply, the exact class must match too. A wrong family at purchase is the most common reason a reservation covers nothing. Size flexibility never crosses a family boundary.
- Size flexibility (normalization factor)
A feature that lets one reservation's discount apply proportionally across different sizes in the same instance family.
Each size in a family has 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 you bought. EC2 Standard RIs get it at regional scope on default tenancy. RDS gets it within the same instance class type and across Single-AZ and Multi-AZ. This covers Db2, MariaDB, MySQL, Oracle BYOL, and PostgreSQL. SQL Server and Oracle License Included do not get it. ElastiCache reserved nodes gained it in October 2024. A reserved node discounts any size in the same family, region, and engine.
- Previous-generation family
An instance family that AWS has replaced with a newer, usually cheaper family, such as m5 replaced by m8g.
AWS keeps releasing instance families with a better price for the same work. A 1- or 3-year Reserved Instance does not follow that release. An EC2 Convertible RI can exchange into the new family at no fee. An EC2 Standard RI can modify only a few attributes, never family, so the RI Marketplace is the only exit. RDS and ElastiCache reservations offer neither. They stay on the old family for the full term.
- Regional vs Zonal RI
Whether a reservation applies anywhere in a region (Regional) or only in one Availability Zone (Zonal).
A Regional RI is the more flexible choice. Its discount follows matching usage to any AZ in the region. For EC2, so does its capacity reservation. Size flexibility still applies. A Zonal RI locks in one AZ and also reserves actual capacity there. This helps when a workload cannot accept an AZ-level capacity shortfall. The cost is the lost flexibility.
- Scope
The region or Availability Zone that a reservation's discount is bound to.
You set scope once, at purchase. For Standard RIs it is one of the few attributes you can modify later without a full exchange. A wrong scope leaves a discount with nothing running underneath to claim it. This happens when you reserve in a region or AZ where the fleet does not run.
- Platform / engine
The operating system (EC2) or database engine (RDS) that a reservation is bound to, with instance class and region.
For RDS, the engine (MySQL, PostgreSQL, and the rest) is the hardest dimension. A reservation for one engine never discounts another, whatever the size. Deployment option is the exception. On the size-flexible engines, the benefit moves freely between Single-AZ and Multi-AZ. For EC2, only Convertible RIs can exchange platform mid-term. Standard RIs and every RDS or ElastiCache reservation stay locked to the platform or engine you bought.
Coverage & utilization
Coverage and utilization, with discount depth, make up Effective Savings Rate. That one number shows whether your reservations do their job.
- Coverage
The percentage of reservable running capacity that is matched to a reservation you own.
Take everything running that AWS lets you reserve. Ask how much of it a reservation matches right now. That share is coverage. Usage below 100% coverage pays the on-demand premium on something you could discount. Coverage cannot exceed 100%. Extra reservations beyond reservable usage sit unmatched.
- Utilization
The percentage of a reservation's own capacity that matching running usage claims.
Coverage looks from the fleet's side: how much of what runs is discounted. Utilization looks from the reservation's side: how much of what you bought is in use. A reservation with low utilization costs its full price and discounts little or nothing. This failure shows up when a family shrinks, moves region, or retires mid-term.
- Reservable usage
The part of running usage that can be matched to a reservation, the base that coverage is measured against.
Not everything that runs qualifies. Short-lived or serverless usage, for example, was never a candidate for a reservation. Coverage uses only the reservable part. So the number shows how your reservations perform, with no dilution from usage that could never be covered.
The extra you pay per hour on reservable usage that no reservation covers.
This is the gap between the on-demand rate and the cost of the same usage under a matching reservation. It is silent and ongoing. Nothing in the AWS console flags it, so it is easy to miss. It builds on any coverage gap. The gap can be a family you 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 is below 100%, the class's real cost is a blend. It mixes the discounted reserved rate with the full on-demand rate on the uncovered part. This is the number on the bill. Effective hourly rate describes a single reservation on its own.
- On-demand-equivalent cost (ODE)
What your fleet's usage would cost with nothing reserved, the baseline for every savings percentage.
AWS Cost Explorer and the Cost and Usage Dashboard show this natively, next to amortized cost, for this comparison. It is a hypothetical cost. You never pay it. Its job is to be the denominator that turns "how much did reservations save" into a percentage.
- Amortized cost
What you pay once every reservation's upfront and hourly cost is spread evenly across its term.
An All Upfront reservation bills $0 hourly. Amortized cost still gives it an even daily charge for the whole term. This is the same method as effective hourly rate, applied across the entire fleet instead of one reservation. Compare amortized cost to on-demand-equivalent cost over the same period. That comparison gives you Effective Savings Rate.
- Effective Savings Rate (ESR)
The percentage saved off on-demand-equivalent cost after coverage, discount depth, and utilization are priced in.
ESR = 1 − amortized cost / on-demand-equivalent cost. This reduces to coverage × [1 − (1−discount)/utilization]. FinOps teams use it as the standard output metric for rate optimization. Coverage alone cannot give you this number. 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, in real points and dollars.
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.
The running instance keeps going at term end, with no restart, stop, or slowdown. Only the price changes. Usage that was covered reverts to the on-demand rate at that instant, whether or not anyone notices.
- Renewal
A new reservation you buy by hand to replace one that is ending, because AWS has no auto-renew for RIs.
A renewal is a new purchase decision with its own term and payment-option choice. Make it before the old reservation expires so coverage never gaps. Nothing in AWS prompts you. You must track the date and act on it.
- Renewal cliff
The silent jump from a reservation's discounted rate to the full on-demand rate when its term ends unrenewed.
A Reserved Instance has one failure mode: it does not renew itself. The renewal cliff catches disciplined teams as often as sloppy ones. It is a calendar problem, and tracking expiry dates fixes it.
- Modification / exchange
The two ways to change a reservation mid-term: modifying a Standard RI's few attributes, or exchanging a Convertible RI.
Modification is narrow and free on Standard RIs. You can change the AZ or scope. For EC2 with size flexibility, you can also change the instance size within the same family. Exchange works only on Convertible RIs. It can change family, size, OS, or tenancy outright. The new RI's value must be equal to or greater than the value you exchange.
- RI Marketplace
AWS's resale market for the unused term of an EC2 Standard RI, the one way to exit early.
Only EC2 Standard RIs qualify, and only for the remaining term. Convertible RIs and every RDS or ElastiCache reservation have no resale option. Use it as a safety valve for a reservation bought against a family that proved short-lived.
- Queued purchase
A Reserved Instance or Savings Plan purchase you schedule ahead, which AWS completes on your date if the price holds.
AWS lets you queue an EC2 Regional RI or a Savings Plan purchase up to three years ahead. The price is capped when you queue it. If the price rises before the date, the purchase does not complete, and nothing alerts you. You cannot queue Zonal RIs, Marketplace RIs, RDS reservations, or ElastiCache reservations at all. You must buy those right now.
Beyond RIs
The rest of AWS's reservation-shaped discounts, where they overlap with RIs and where they don't. Reserver covers AWS RIs only today. OpenSearch, Redshift, and other clouds are on the roadmap.
- Compute Savings Plan
A spend-based commitment (dollars per hour) that discounts EC2, Fargate, and Lambda usage, whatever the instance family or region.
A Compute Savings Plan does not lock in an instance class. The discount follows any qualifying compute usage, wherever it runs, for the whole term. It never covers RDS or ElastiCache. It shares an RI's failure mode. It has no auto-renew, and usage silently reverts to on-demand at term end.
- EC2 Instance Savings Plan
A narrower Savings Plan: a spend commitment to one instance family and region, with a Standard-RI-like discount.
It gives up the Compute Savings Plan's cross-service flexibility for a deeper discount. You stay pinned to one family and one region. It sits between an RI's rigidity and a Compute Savings Plan's full flexibility. Like every reservation-shaped commitment here, it does not auto-renew.
- Database Savings Plan
A spend-based commitment (dollars per hour) for database usage, launched 2 December 2025, with a discount of up to 35%.
It covers RDS, Aurora, and ElastiCache, among other database services. The term is 1 year, with No Upfront payment only. Provisioned RDS and Aurora instances must be Generation 7 or newer. Serverless usage is also covered. For ElastiCache, only Valkey is covered. AWS does not combine it with an RI on the same workload. It does not renew itself, so a 1-year plan means a renewal date every year.
- Reserved DB instance (RDS)
The Reserved Instance for Amazon RDS, bound to a database engine and deployment option.
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. It also applies 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 ElastiCache Reserved Instance, bound to a cache node type, with a lower discount ceiling than EC2 or RDS.
Reserved nodes cap out at up to 56% off on-demand. That is the smallest ceiling of the three services Reserver covers today. As with RDS, there is no convertible option and no resale. The same silent renewal cliff waits at term end.
Multi-account & organizations
How a reservation's discount behaves when more than one AWS account, or more than one AWS Organization, is involved.
- Discount sharing
AWS's default behavior of applying a Reserved Instance or Savings Plans discount to any account on the same consolidated bill.
Sharing is on by default for every account in an AWS Organization. A Regional RI's discount, and a Savings Plan's, applies to matching usage in a sibling account automatically. Only the management account can turn sharing off, per account or for all of them. AWS warns that turning it off can raise an account's monthly bill.
- Payer account
The account in an AWS Organization's consolidated bill that receives every member account's usage and Reserved Instance discounts.
Coverage measured inside one member account can read wrong. A discount it uses, or one it bought, can belong to a different account. The payer account's view, rolled up across every member account, is the only one that shows where each discount lands.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list, and we will onboard you when we have capacity. Your first recommendation lands within minutes of connecting.