Savings Plans have largely replaced Reserved Instances for new AWS EC2 commitments. What can a Reserved Instance still do that a Savings Plan cannot, and when would you buy a standard rather than a convertible RI?
answer
- Billing benefit versus capacity guarantee
- Zonal scope is the one that reserves
- Exchange versus resale, not both
- Convertible trades discount for optionality
- Databases are not Savings-Plan eligible
basics
~20 sReserved Instances can reserve capacity when scoped to an Availability Zone, can be exchanged if convertible, and can be sold on the Reserved Instance Marketplace if standard. Savings Plans do none of these — and services such as RDS and ElastiCache still only offer reserved instances.
solid answer
~50 sSavings Plans are simpler and more flexible, so they are the default for EC2 today, but Reserved Instances retain three capabilities. First, an RI scoped to a specific Availability Zone — a *zonal* RI — carries a capacity reservation, so it guarantees you can launch; a regional RI and every Savings Plan are purely billing constructs. Second, a *convertible* RI can be exchanged during its term for a different family, operating system or tenancy, as long as the new reservation is of equal or greater value — Savings Plans cannot be changed at all. Third, a *standard* RI can be listed for sale on the Reserved Instance Marketplace, which is the only genuine exit from an EC2 commitment. Beyond EC2, several services — RDS, ElastiCache, OpenSearch, Redshift — are still bought as reserved instances or nodes, so RIs remain unavoidable there. Buy standard when the configuration is fixed and you value the deeper discount and the resale option; buy convertible when you expect the shape to change.
go deeper
Know that Savings Plans are the modern default for EC2 commitments and that Reserved Instances still exist, including for databases. Do not claim Savings Plans reserve capacity.
Explain the three residual RI capabilities — zonal capacity reservation, convertible exchange, standard resale — and state plainly that a Savings Plan is a billing construct only.
Demonstrate that you separate the capacity guarantee from the discount: Capacity Reservations for launch assurance, Savings Plans for the rate. Check which slice of the bill is even eligible before recommending an instrument.
Frame commitments as an irreversible financial position with almost no secondary market. Be ready to defend a target term mix, an exit strategy, and who is accountable when a commitment outlives the architecture it was bought for.
## Why Savings Plans took over Reserved Instances came first and carried a lot of ceremony: you reserved a configuration, and matching it against real usage involved normalisation factors, regional versus zonal scope, and a good deal of spreadsheet work. Savings Plans replaced that with a single number — dollars per hour — and let AWS do the matching. For most EC2 commitments today, that is the right default, and interviewers expect you to say so. But "default" is not "only", and the residual capabilities of RIs are exactly what a well-prepared candidate can name. ## Capability one: capacity reservation The distinction people miss is *scope*. A Reserved Instance is bought as either: - **Regional** — applies anywhere in the region, gives instance size flexibility within the family, and reserves **no** capacity; or - **Zonal** — pinned to a specific Availability Zone and instance type, no size flexibility, and it **does** reserve capacity in that AZ. A Savings Plan is always the first kind of thing: a billing benefit with no capacity guarantee. So if the requirement is "this workload must be able to launch in `eu-west-1a` even during a capacity crunch", a Savings Plan cannot express it. The modern way to express it is an On-Demand Capacity Reservation, which reserves capacity and is billed like an On-Demand instance — and that billed capacity can itself be discounted by a matching Savings Plan. So the good answer is usually "Capacity Reservation for the guarantee, Savings Plan for the discount", not "buy zonal RIs". ## Capability two: exchange (convertible RIs) A **convertible** RI can be exchanged during its term for one or more other convertible RIs, provided the new reservations are of equal or greater total value. That lets you follow a fleet across families, operating systems or tenancies without eating the whole commitment. The price is a smaller discount than a standard RI of the same term. A **standard** RI cannot be exchanged. You can modify limited attributes — Availability Zone, scope between regional and zonal, network platform, or split and merge sizes within a family — but you cannot move it to a different instance family. Savings Plans sit outside this entirely: there is no exchange mechanism. Their flexibility is built into which usage they match, not into changing the contract afterwards. ## Capability three: resale (standard RIs) Standard RIs can be listed on the **Reserved Instance Marketplace** and sold to another AWS customer, subject to conditions such as seller eligibility and a minimum remaining term. Convertible RIs cannot be sold, and neither can Savings Plans. This makes the standard RI the only EC2 commitment with a genuine secondary market — a real, if narrow, escape hatch if your plans change. ## Beyond EC2 Savings Plans cover EC2, Fargate and Lambda. A number of other services still sell commitments only as reserved instances or reserved nodes — Amazon RDS reserved DB instances, ElastiCache reserved nodes, OpenSearch reserved instances, Redshift reserved nodes, DynamoDB reserved capacity. If a large slice of your bill is databases, "we're on Savings Plans" leaves that whole slice at On-Demand rates. Checking which services in your bill are actually eligible is a step candidates routinely skip. ## Standard versus convertible: the decision Think of it as buying an option. The convertible RI's exchange right is an option on your own uncertainty, and you pay for it with a lower discount. - **Standard** when the configuration is genuinely fixed for the term — a licensed platform pinned to a family, a legacy system nobody will fund a rewrite for, a steady control plane. You get the deeper discount and the Marketplace as a fallback. - **Convertible** when you can foresee the family or platform changing but still want a multi-year discount. - **Neither, buy a Compute Savings Plan** when what you actually want is flexibility across families and compute models — the Savings Plan gives you that up front instead of making you exercise an exchange later. ## The framing that scores An interviewer is checking whether you can distinguish *billing* from *capacity*, and whether you understand that every extra freedom (exchange, resale, capacity guarantee) is paid for in discount. A candidate who says "RIs are the old way, always use Savings Plans" is 80% right and will be caught by the follow-up about guaranteeing capacity in an AZ, or about the RDS half of the bill.
- If a Savings Plan does not reserve capacity, how do you guarantee a workload can launch in a specific Availability Zone?Use an On-Demand Capacity Reservation. It reserves capacity in a named Availability Zone for a specific instance type and platform, and is billed whether or not you run instances in it. Crucially, that billed capacity is itself eligible for Savings Plan or Reserved Instance discounts, so you get the guarantee and the discount from two separate instruments rather than one.
- What is the only way to exit an EC2 commitment early?Selling a standard Reserved Instance on the Reserved Instance Marketplace, subject to AWS's seller eligibility and remaining-term conditions. Convertible RIs can be exchanged but not sold, and Savings Plans can be neither exchanged, cancelled nor sold. That asymmetry is worth remembering when the term length is being decided, because for Savings Plans the only real risk control is buying less.
- A convertible RI exchange must be for equal or greater value. Why does that condition exist?Because otherwise the exchange would function as a partial refund: you could downgrade into a cheaper reservation and walk away from part of the commitment. Requiring equal or greater remaining value keeps the total dollars committed intact while letting the shape change, which is the point of the product — flexibility of configuration, not of amount.
- Your bill is 60% RDS. What does that change about a commitment strategy?It means most of your spend is outside Savings Plan eligibility. You would buy reserved DB instances for the steady RDS baseline — choosing the engine, class and Multi-AZ configuration deliberately, since those scope the reservation — and use Savings Plans only for the EC2, Fargate and Lambda portion. Reporting coverage across both instrument types together is what keeps the picture honest.
saying these in an interview costs you the question
- Claims every Reserved Instance reserves capacity
- Thinks convertible RIs can be sold on the Marketplace
- Believes Savings Plans can be exchanged like convertible RIs
- Assumes Savings Plans cover RDS or ElastiCache
- Says RIs are obsolete with no exceptions