AWS Reserved Instances in 2026 — where they still cut your bill, and where Savings Plans won.

IWhat changed: RIs are now a database tool, not a compute tool

If the last time you tuned Reserved Instances was a few years ago, the mental model has flipped. EC2 RIs still technically exist, but for compute the right default in 2026 is a Savings Plan. RIs earn their keep on the services Savings Plans do not cover.

Reserved Instances were AWS's original commitment discount: promise to run a specific instance type for one or three years, get a large discount versus on-demand. They worked, but they were rigid — a reservation was tied to an instance family, and changing your architecture could strand it. In 2019 AWS launched Savings Plans, which commit to a dollar-per-hour of spend rather than a specific instance, and for EC2/Fargate/Lambda that flexibility usually wins. The practical result by 2026: most teams cover compute with Savings Plans and stop buying EC2 RIs entirely.

But Savings Plans only apply to compute. They do not cover RDS, Aurora, ElastiCache, Redshift, or OpenSearch. For those services the commitment mechanism is still a Reserved Instance (RDS, ElastiCache, OpenSearch) or a Reserved Node (Redshift). So the question "should I buy RIs?" in 2026 is really "is a meaningful share of my bill in the managed-database and analytics tier?" — and for most data-heavy SaaS companies, the answer is yes.

This matters because the database tier is where a lot of teams quietly overspend. Compute gets right-sized and Spot-optimized because engineers touch it daily; the RDS Multi-AZ Postgres instance that has been running at the same size for 18 months rarely gets a second look. That stable, always-on, predictable footprint is exactly what a Reserved Instance is built to discount. The boring, steady part of your bill is usually the most reservable part.

A useful framing: think of your bill in two pools. The compute pool (EC2, Fargate, Lambda) is best covered by Savings Plans. The data pool (RDS/Aurora, ElastiCache, Redshift, OpenSearch) is best covered by Reserved Instances / Nodes. A mature commitment strategy uses both, sized to the steady-state floor of each pool, and leaves the spiky top layer on on-demand or Spot. The rest of this guide is mostly about the data pool — because that is where RIs live now.

IIHow a Reserved Instance actually works (it is a billing discount, not a server)

The single most common misconception is that a Reserved Instance is a reserved server. It is not. An RI is a billing construct — a discount that auto-applies to matching usage. You never "launch into" an RI; you keep running normally and the discount lands on your invoice.

When you buy a Standard RDS RI for, say, a db.r6g.xlarge running PostgreSQL in us-east-1, you are not reserving a machine. You are telling AWS billing: "for the next 12 or 36 months, charge me the reserved rate for one r6g.xlarge-equivalent of PostgreSQL in this region." Each hour, the billing engine looks at your running instances, finds usage that matches the reservation's attributes, and applies the discounted rate to it. If nothing matches that hour, the reservation earns nothing — you still paid for it (or owe the recurring fee), but it discounted nothing.

The attributes that have to match depend on the service, but generally include: the instance/node family and size, the region, the database engine (Postgres vs MySQL vs Aurora, etc.), and sometimes the deployment option (Single-AZ vs Multi-AZ for RDS). For RDS specifically, "size flexibility" within a family means one reservation can cover a different size in the same family by scaling its coverage proportionally — a single db.r6g.2xlarge reservation can cover two db.r6g.xlarge instances, for example. That flexibility is one reason buying at a mid-size and letting it spread is often smarter than buying many small reservations.

Because it is a billing discount, an RI cannot be "turned off" to save money during a quiet period — the commitment is the point. If you All-Upfront a 3-year RDS RI and then migrate that database to Aurora Serverless v2 six months in, the original RI keeps charging (or stays sunk) and now matches nothing. This is the mechanism behind stranded RIs, covered in Section VIII. The discipline an RI demands is forecasting: only reserve the part of your footprint you are confident will still be running, in roughly the same shape, for the length of the term.

IIIStandard vs Convertible — what you give up for the right to change your mind

The first real decision is Standard vs Convertible. It is a discount-for-flexibility trade. Standard RIs discount more; Convertible RIs let you exchange into different instance families later. Pick based on how confident you are in your architecture over the term.

A Standard RI is the cheaper, more rigid option. It locks you to an instance family and (mostly) the attributes you bought. You can still modify some attributes within limits — change the Availability Zone, change scope from zonal to regional, or split/merge across sizes in the same family — and Standard RIs can be sold on the RI Marketplace (EC2) if you need an exit. What you cannot do with a Standard RI is exchange a db.r6g into a db.m6g or a different engine. If your architecture is settled, Standard captures the deepest discount.

A Convertible RI costs a few discount points more but adds the exchange right: you can trade it for a Convertible RI of a different instance family, OS/engine, or tenancy, as long as the new reservation is of equal or greater value. That makes Convertibles the safer choice when you expect to migrate instance families during the term — for example, an ARM/Graviton migration (r5 → r6g), or a planned move from one engine to another. The cost of that insurance is typically on the order of 3–8 percentage points of discount versus the equivalent Standard RI; treat exact spreads as representative and check current AWS pricing.

In practice the decision tracks your roadmap. If you are reasonably sure the reserved workload will look the same in three years (a stable production Postgres primary, a steady Redis cache), Standard wins on price. If a migration is likely — Graviton, an engine change, a re-platform — Convertible is cheaper than eating an exchange or stranding a Standard RI you can no longer use. A common pattern: Standard for the genuinely stable core, Convertible for the parts of the estate you expect to evolve.

IV1-year vs 3-year, and No / Partial / All Upfront

Two independent dials set how deep the discount goes: the term (1 or 3 years) and how much you pay up front (None, Partial, or All). Longer term and more upfront both push the discount higher — and both reduce your flexibility and tie up cash.

Term is the bigger lever. A 3-year commitment discounts substantially more than a 1-year one — but it is a real three-year bet on the workload still existing in roughly the same form. For an early-stage company whose architecture might be unrecognizable in 18 months, a 1-year term is usually the right call even though it leaves discount on the table; the optionality is worth more than the extra points. For a stable, predictable production database that is not going anywhere, 3-year captures the deepest savings.

Payment option is the second dial. No Upfront spreads the cost across monthly charges and holds zero cash, at the smallest discount. All Upfront pays the entire term at purchase for the deepest discount. Partial Upfront sits in between — roughly half up front, the rest monthly. The spread between No Upfront and All Upfront on the same term is typically only a few percentage points, so the decision is mostly about cash: if capital is tight (and for a startup it usually is), No Upfront captures most of the benefit without locking up cash that is more valuable in the business than in a prepaid reservation.

There is also a cash-flow argument that interacts with AWS credits. If you are sitting on Activate credits, an All-Upfront purchase consumes a large chunk of credit immediately, whereas No Upfront spreads the consumption across the term and lets the credits cover more months of your overall bill. Teams burning credits often deliberately choose No Upfront for exactly this reason. The table in Section VI lays out the four common term/payment combinations side by side with representative discount bands.

VScope (regional vs zonal) and the RI Marketplace

Two details that materially change how much of your discount you actually capture: the scope of the reservation (regional vs zonal), and your exit route if you no longer need it (the RI Marketplace, for EC2).

Scope decides how broadly a reservation can match. A regional-scoped RI applies the discount across any Availability Zone in the region and brings instance-size flexibility within the family — so it floats to wherever the matching usage runs. A zonal-scoped RI is pinned to a specific Availability Zone and, in the EC2 case, additionally reserves capacity in that AZ. For almost all cost-optimization purposes you want regional scope: it maximizes the chance the reservation finds matching usage and minimizes the risk of stranding it because a workload moved AZs. Choose zonal only when you specifically need the capacity reservation guarantee in a particular AZ.

The RI Marketplace is the exit valve — for EC2 Standard RIs specifically. If you hold a Standard EC2 RI you no longer need, you can list it for sale to other AWS customers and recover some of the remaining value. It is not a full refund mechanism and it does not cover Convertible RIs or, in general, the database-tier RIs (RDS/ElastiCache/Redshift/OpenSearch) — so do not buy a 3-year database RI assuming you can simply resell it if plans change. For the database tier, your "exit" is really modification (adjusting attributes) or, for Convertibles, exchange — not resale.

The practical takeaway: default to regional scope, and do not treat the Marketplace as a safety net for anything except EC2 Standard RIs. For everything in the data tier, the safety net is buying the right term length and using Convertibles where a change is plausible — because once you own a database RI, you mostly live with it until it expires.

VIThe four common RI configurations, side by side

VIIReserved Instances vs Savings Plans — when each one wins

This is the question that sends people to this page, so here is the honest answer. They are not competitors across the whole bill — they cover different services. The choice only exists for compute, and there the answer is usually Savings Plans.

For compute (EC2, Fargate, Lambda): Savings Plans almost always win in 2026. A Compute Savings Plan commits to a dollar/hour of compute spend and floats across instance families, sizes, regions, OS, tenancy, and even between EC2, Fargate, and Lambda — at roughly the same discount an EC2 Convertible RI used to give, with far more flexibility. An EC2 Instance Savings Plan goes a bit deeper on discount in exchange for committing to a specific family in a region. There is very little reason left to buy a new EC2 RI when a Savings Plan covers the same spend more flexibly.

For the data and analytics tier (RDS/Aurora, ElastiCache, Redshift, OpenSearch): Reserved Instances / Nodes are the only commitment option — Savings Plans do not apply. So there is no "versus" here; if you want a commitment discount on these services, RIs are it. This is the single most important thing to internalize: in 2026 RIs are not the worse version of Savings Plans, they are the tool for the services Savings Plans cannot touch.

The right portfolio therefore uses both, deliberately: Savings Plans sized to the steady-state floor of your compute spend, and Reserved Instances sized to the steady-state floor of your database/analytics spend. The mistake is treating it as one-or-the-other across the whole bill, or — worse — buying EC2 RIs out of habit when a Savings Plan would cover the same compute with room to change your architecture. The comparison table below frames the two tools head to head.

VIIIStranded RIs, modification, exchange — keeping coverage healthy

A Reserved Instance only saves money in the hours it matches running usage. The recurring failure mode is the stranded RI: a reservation whose attributes no longer match anything you run, quietly earning a fraction of what you paid for it. Keeping coverage healthy is an ongoing job, not a one-time purchase.

Stranding happens for ordinary reasons. You buy a 3-year RDS RI for a db.r5.xlarge, then migrate to Graviton (db.r6g) for better price-performance — and the old Standard RI, locked to r5, now matches nothing. Or you right-size a database down, or change engines, or move a workload to a region you did not reserve in. The reservation keeps charging (or stays sunk if All-Upfront) while discounting little or nothing. The cruel irony: the cost-optimization work that improves your architecture is often exactly what strands a rigid reservation bought without an exit plan.

AWS gives you two repair tools. Modification changes attributes of an existing RI without buying a new one — adjust the Availability Zone, flip scope from zonal to regional, or split/merge coverage across sizes within the same instance family. Modification does not let you change family or engine. Exchange (Convertible RIs only) lets you trade into a different family/engine/tenancy, provided the new Convertible RI is of equal or greater value. This is the entire reason to pay the Convertible premium up front: when the architecture moves, you exchange instead of strand.

Operationally, the fix is a managed commitment portfolio with three habits. First, ladder your terms — stagger expirations across quarters instead of one giant cliff, so you re-forecast continuously and never face a single huge renewal decision. Second, monitor utilization and coverage as named metrics: utilization is the percentage of each reservation actually being used (you want this near 100%), and coverage is the percentage of eligible usage sitting under a commitment (you tune this to your steady-state floor, not 100% — over-covering a spiky workload strands the reservation on quiet days). Third, run exchanges and modifications as your estate evolves rather than letting reservations drift out of alignment. Cost Explorer's utilization and coverage reports, plus its reservation recommendations, are the built-in starting point.