Savings Plans vs. Reserved Instances: The 2026 Guide to AWS Commitment Discounts

Almost every AWS customer we assess is leaving 10–25% on the table, and commitment discounts are usually the single biggest lever. The problem is that AWS now offers at least eight different ways to commit, each with a different discount, a different lock-in, and a different escape hatch. Pick wrong and you either overpay for flexibility you never use, or you strand a three-year commitment on an instance family you abandoned in month four.

This is the guide we wish existed when we sit down with a new client. It covers what each instrument actually does, which one gives you the deepest discount, which one gives you the most room to move, and how to combine them so you get most of the discount without most of the risk.

One prerequisite. Measuring any of this requires knowing the difference between amortized and unblended cost — commitments look free in one and enormous in the other. If those terms are not solid, read what the numbers on your AWS bill actually mean first.

The trade-off that explains all of it

Most write-ups reduce this to two axes, discount versus flexibility. That is not enough to make a real purchase. Every commitment discount AWS sells trades along six:

• Discount depth — how far below On-Demand you land.
• Flexibility — what you can change without losing the rate. This is not one property but seven, and instruments differ sharply on each. Unbundled below.
• Term — one year or three, with three paying more and hurting more.
• Cash flow — All, Partial, or No Upfront. Paying up front buys a deeper rate, so this is a genuine lever, and not every instrument offers all three.
• Capacity — whether the instance is guaranteed to actually start. Almost nothing buys you this, and the one thing that does gives up everything else.
• Liquidity — whether you can get out. Exactly one instrument has a secondary market.

AWS prices these against each other almost perfectly. The deeper the discount, the narrower the thing you committed to. There is no instrument that is both maximally flexible and maximally cheap, and any vendor telling you otherwise is selling something. Your job is not to find the best one. Your job is to work out how much of your fleet is genuinely predictable, and buy the deepest discount only for that portion.

Flexibility, unbundled

"Flexible" is the most overloaded word in this subject. Here is what each instrument actually lets you change while continuing to receive the discounted rate.

Reading the "Partly" cells. Standard RI size flexibility applies only to Amazon Linux/UNIX with default tenancy — buy for Windows or Dedicated tenancy and it silently does not apply. Convertible RIs can change family, OS, and tenancy, but only through a manual exchange you have to initiate, which is why their Automatic column is a No. Service means moving the workload to a different compute or database service entirely: EC2 to Fargate to Lambda for a Compute SP, or RDS to DynamoDB for a Database SP.

The other four axes

Flexibility is only one column of the decision. Here is everything else, and note that the last two columns are where the surprises live.

Read those two tables together and the whole subject collapses into one line: the bottom row is the only thing that guarantees your instance starts, and it is also the only row with nothing but "No" in the flexibility table. That is the trade in its purest form. Everything else is a negotiation between those two poles.

Two things worth noticing before you read on. Zonal is a scope you apply to an RI, not a separate product — which is why a zonal Standard RI keeps its Marketplace resale right while gaining a capacity reservation. And the Database Savings Plan is the only instrument with no term choice and no payment choice at all, which makes it a far more take-it-or-leave-it decision than its flexibility suggests.

The full menu in 2026

Here is every commitment instrument currently worth knowing, with AWS's own published maximum discounts.

Two things jump out. First, the ceiling for compute has been 72% for years and nothing beats it. Second, the newest and most flexible instrument, Database Savings Plans, has by far the shallowest discount. That is not an accident. It is the price of flexibility, stated plainly.

Compute Savings Plans: the default answer

A Compute Savings Plan is a commitment to spend a certain number of dollars per hour on compute, full stop. It applies automatically regardless of instance family, instance size, Region, operating system, or tenancy. It also covers AWS Fargate and AWS Lambda.

That last part is what people underestimate. You can migrate a workload from c5 to m7g, move it from Ireland to London, then containerize it onto Fargate, then rewrite the whole thing as Lambda functions — and the same commitment keeps paying out the entire time. No exchanges, no paperwork, no stranded reservation.

Best for: most organizations, most of the time. If you are early in a modernization program, actively migrating, or simply do not trust your own 12-month forecast at the instance-family level, this is the correct default.

The cost: you give up roughly six percentage points versus the 72% ceiling. On a $2M annual compute bill, that gap is real money — but it is usually much less than the money lost to a stranded Standard RI.

EC2 Instance Savings Plans: the deep discount with a soft edge

An EC2 Instance Savings Plan takes you to the full 72%, in exchange for naming one instance family in one Region — m5 in Virginia, for example. Within that box you keep a surprising amount of freedom: you can change instance size (m5.xlarge to m5.24xlarge), change the operating system (Windows to Linux), and change tenancy (Dedicated to Default), all without losing the rate.

This is the instrument most FinOps teams under-use. It gives you the same headline discount as a Standard RI, with materially better ergonomics, and it is a financial commitment rather than a reservation — so there is nothing to modify, exchange, or track per-instance.

Best for: a stable production core where you know the family but not the exact sizes. Think a long-lived Kubernetes node group, a database tier on EC2, or a steady fleet you have already right-sized.

The cost: the family and Region are locked for the whole term. If your graviton migration moves you off m5 in month seven, that commitment does not follow you.

Standard EC2 RIs: maximum discount, minimum give

Standard Reserved Instances hit the same 72% ceiling and remain the most rigid instrument AWS sells. You commit to an instance type, Region, tenancy, and platform. You cannot exchange a Standard RI for a different configuration — though you can modify some attributes, and you can sell it on the Reserved Instance Marketplace.

That marketplace resale right is the one genuine advantage Standard RIs hold over every Savings Plan. If your needs collapse, you can list the reservation and recover some capital. Convertible RIs cannot be sold. Savings Plans cannot be sold. It is the only real secondary market in the AWS commitment world.

One critical detail people get wrong: regional Standard RIs offer instance size flexibility, but that flexibility only applies to Amazon Linux/Unix RIs with default tenancy. Buy a regional RI for Windows or for Dedicated tenancy and the size flexibility silently does not apply. We have found six-figure variances hiding in exactly that footnote.

Best for: a genuinely frozen workload, or a team that specifically wants the resale option as an exit.

Convertible RIs: the instrument Savings Plans made redundant

Convertible RIs top out at 66% and can be exchanged during the term for another Convertible RI with different attributes — family, type, platform, scope, or tenancy. There is no limit on how many times you exchange.

But read the rules carefully, because they are asymmetric by design:

• The new RI must be of equal or higher value. You can trade up, never down. If the target is worth less, AWS simply gives you more instances so the total value holds.
• The Region is fixed for the life of the reservation. You cannot exchange across Regions.
• You cannot sell Convertible RIs on the Marketplace.
• Merging RIs with different terms produces a three-year commitment. People trip on this constantly.
• You cannot exchange an All or Partial Upfront RI down to No Upfront.

Now compare: a Compute Savings Plan offers the same 66%, applies across Regions automatically, covers Fargate and Lambda, and requires zero manual exchanges. For most new purchases, the Convertible RI has been strictly dominated. AWS's own documentation now leads the Reserved Instances page with a recommendation to use Savings Plans instead.

Best for: holders of existing Convertible RIs managing them to expiry. Rarely the right new purchase.

Zonal RIs: the one thing Savings Plans genuinely cannot do

This is the most important section in the article, and the one most often missed.

Savings Plans do not reserve capacity. Neither do regional RIs. Only a zonal Reserved Instance reserves actual physical capacity in a specific Availability Zone.

For most workloads this is irrelevant — until the day a Region gets capacity constrained and your Auto Scaling group cannot launch. If you run financial transaction processing, real-time gaming, clinical systems, or anything with a hard availability floor, a billing discount is not the same thing as a guarantee that the instance will start.

The nuance: a zonal RI trades away everything else to get that guarantee. No Availability Zone flexibility. No instance size flexibility. No queued purchases. You are pinned to one instance size in one AZ.

The better modern pattern is usually to decouple the two concerns: buy an On-Demand Capacity Reservation for the capacity guarantee, and let a Savings Plan apply the discount on top of it. AWS explicitly supports this. You get the capacity assurance and keep the commitment flexible, which is almost always the better structure.

Database Savings Plans: new, flexible, and shallow on purpose

Announced at re:Invent 2025, Database Savings Plans are the newest instrument and the one generating the most confusion. They now span ten services: Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Timestream, Neptune, Keyspaces, DMS, and Amazon OpenSearch Service.

The flexibility is remarkable. A single $/hr commitment applies regardless of engine, instance family, size, Availability Zone, or Region — and it covers serverless usage, which previously had no reservation model at all. You can migrate from RDS for Oracle to Aurora PostgreSQL, or move a workload from RDS to DynamoDB entirely, and keep your discounted rate.

Now the constraints, which matter a great deal:

The headline 35% applies to serverless. Provisioned instances land around 20%, DynamoDB and Keyspaces on-demand throughput around 18%, and provisioned capacity around 12%. Against a three-year RDS RI at up to 69%, a Database Savings Plan is less than half the discount.

So the honest framing is this: Database Savings Plans are not a cheaper way to run databases. They are a way to commit money to a database estate you intend to reshape. If your database footprint is frozen and modern, RDS RIs still win on pure dollars. If you are mid-modernization, the DSP is the instrument that survives the journey.

The discount ladder, ordered

If you only remember one thing, remember the ordering — most savings and least flexibility at the top:

1. Standard RI, 3-year, All Upfront — deepest rate, hardest lock, but resaleable on the Marketplace.
2. EC2 Instance Savings Plan, 3-year — same 72% ceiling, family and Region locked, but free movement on size, OS, and tenancy.
3. Convertible RI, 3-year — 66%, exchangeable upward, Region locked, manual effort.
4. Compute Savings Plan, 3-year — 66%, near-total flexibility including Fargate and Lambda.
5. Compute Savings Plan, 1-year — the sweet spot for most teams. Real savings, short leash.
6. Database Savings Plan, 1-year — up to 35%, extraordinary flexibility across ten services.

How AWS actually applies them (the order matters)

When you hold several instruments at once, AWS applies them in a fixed sequence. This is not cosmetic — it determines whether your commitments stack cleanly or cannibalize each other:

1. Reserved Instances apply first. Savings Plans apply to usage only after RIs have been applied.
2. EC2 Instance Savings Plans apply before Compute Savings Plans, because Compute plans have broader applicability and AWS wants to spend the narrow commitment first.
3. Within Savings Plans, the highest discount percentage is covered first. AWS computes the savings percentage of each eligible usage and spends your commitment where it goes furthest.
4. In a consolidated billing family, plans apply to the owner account's usage first, then to other accounts, if sharing is enabled.

Two consequences worth internalizing. Savings Plans never apply to Spot usage or to usage already covered by an RI, so double-committing is pure waste. And each hour's commitment can only be used in that hour — unused commitment does not carry forward. A plan sized to your peak bleeds money every quiet hour, every weekend, every holiday.

The layering strategy that actually works

Sophisticated FinOps teams do not choose one instrument. They stratify the fleet by confidence and buy a different instrument for each layer.

Layer 1 — the frozen base (roughly 40–50% of steady usage). The workloads that have not changed in 18 months and will not change in the next 18. Buy the deepest instrument you are comfortable with: a 3-year EC2 Instance Savings Plan on the dominant family, or Standard RIs if you want the resale exit.

Layer 2 — the predictable middle (roughly 25–35%). Usage you are confident exists but not confident about the shape of. A 1-year Compute Savings Plan. Full flexibility, meaningful discount, short enough that a strategy change does not hurt.

Layer 3 — the volatile top. Leave it On-Demand, or move it to Spot if it is interruption-tolerant. Do not commit here. This is the layer people over-commit and then quietly waste for three years.

Databases run as a parallel track. Modern, stable estate: RDS RIs. Mid-migration or heavily serverless: a Database Savings Plan.

The target is not 100% coverage. Aim for roughly 70–85% of steady-state usage covered, with utilization held near 100%. Which brings us to the mistakes.

Five expensive mistakes we see repeatedly

1. Chasing 100% coverage. Coverage and utilization are different metrics and they pull in opposite directions. Coverage asks what share of your usage is discounted. Utilization asks what share of your commitment is actually consumed. Push coverage to 100% and you will inevitably buy commitment that sits idle overnight — paying for nothing at a discounted rate is still paying for nothing.

2. Committing before right-sizing. The worst possible sequence is to commit three years of spend to an over-provisioned fleet. You have now locked in the waste and removed your own incentive to fix it. Right-size first, run for a month, then commit to the floor you observe.

3. Ignoring the expiry cliff. RIs and Savings Plans do not auto-renew. They simply stop, and your bill silently reverts to On-Demand. We have walked into accounts where a $40k/month increase went unnoticed for two billing cycles because nobody owned the renewal calendar.

4. Buying three-year terms on a one-year strategy. If a Graviton migration, a Kubernetes consolidation, or a serverless rewrite is on your roadmap, three-year instrument-specific commitments will strand. Either buy one-year, or buy the flexible instrument.

5. Forgetting what is never covered. Savings Plans do not discount Spot usage or RI-covered usage. The per-Region Dedicated Instance fee of $2/hour is not discounted. EKS control plane charges are not covered, although the underlying EC2 instances are. And in AWS's own worked example, Lambda requests receive a 0% discount while Lambda duration is discounted. Model the real line items, not the headline.

Your escape hatches, ranked

Commitments cannot be cancelled. But there are four ways out, and they are worth knowing before you buy rather than after:

• The 7-day return window (Savings Plans). Plans with an hourly commitment of $100 or less, purchased within the past 7 days and in the same calendar month, can be returned for a full refund of upfront charges. Capped at 10 returns per year per management account. This is a genuine safety net for a mis-sized purchase — but note the $100/hr ceiling excludes most large commitments.
• The Reserved Instance Marketplace (Standard RIs only). Sell the remainder to another customer. The only true secondary market available.
• Convertible RI exchange. Trade to a different configuration, equal or higher value, same Region.
• RI modification. Adjust some attributes on Standard or Convertible RIs without a full exchange.

Notice what is not on that list: there is no way to exit a large Savings Plan early. That is the real cost of the flexible instruments — they flex on what you run, not on whether you pay.

The short version

The instrument matters less than the discipline. Right-size first. Commit to the floor, never the peak. Layer terms by confidence rather than buying one thing for everything. Own the renewal calendar. Teams that do those four things consistently land in the 20–40% savings range without ever taking a risky position.

Where HiveTek comes in

We model this for clients before a dollar is committed: what your true steady-state floor is, which layer each workload belongs in, what a stranded commitment would cost under each scenario, and where your existing RIs are quietly expiring. Most engagements surface savings in the first week, and knowledge transfer is included in every one — no vendor lock-in, and your team owns the model afterwards.

If you want to know what your commitment position actually looks like, get a free AWS cost analysis and we will map it with you.