AWS costs: Reserved vs Savings Plans vs Spot - one decision tree

Pick Savings Plans first, not Reserved Instances — that's the direct answer, and it isn't opinion, it's what Amazon's own EC2 documentation now says in the box at the top of the Reserved Instances page. Use a Compute Savings Plan to cover the steady floor of your bill, add Spot Instances for anything that can restart without drama, and reach for a Reserved Instance only when you need a guaranteed seat in a specific Availability Zone, not just a discount. The counterintuitive part: for most accounts in 2026, the "safe, boring" choice everyone assumes is the Reserved Instance is actually the one AWS is steering people away from.

Jake's shop runs a small inventory and repair-tracking app on three EC2 instances, and last October he did the thing every small AWS customer eventually does: he saw a "Recommended" green badge next to a three-year Reserved Instance in the console, clicked buy, and felt responsible for the rest of the afternoon.

Then, in July, he swapped his app server from an old m5 family to a newer, cheaper r6i family because it used less memory per request. The three-year Reserved Instance he'd bought for the m5 kept billing him anyway — for a server he no longer ran. He was paying twice: once for a machine he wasn't using, and once for the machine he actually needed, at full On-Demand price.

"So the discount was the trap," Jake said, when he finally called Ethan. "The thing that was supposed to save me money is the thing that cost me money."

Ethan didn't sugarcoat it. "Reserved Instances aren't a bad idea. They're a bad idea for anyone who might change their mind. And almost everyone changes their mind eventually — you rightsize, you migrate, a new instance generation comes out that's 15% cheaper for the same work. The commitment doesn't bend. You do."

The one question that decides almost everything

Before any pricing model, ask this about the specific workload — not your whole AWS bill, this one workload: if this instance disappeared right now with two minutes' notice, would anything actually break?

If the honest answer is "yes, customers would notice" — it's a database, a stateful app server holding sessions, anything without a graceful restart — Spot is off the table for that piece, full stop. If the answer is "no, it would just relaunch and pick up where it left off" — a batch job, a queue worker, most CI/CD runners, most machine learning training — Spot deserves first look, because nothing else gets close to its discount.

Everything that isn't Spot-eligible then splits on a second question: will this exact instance family, size, and Region still be right in a year? If you're mid-migration, mid-rightsizing, or you just don't know yet, you want the flexible option. If you're certain — same family, same Region, for the whole term — you can safely take the deepest discount available.

The decision tree, one branch at a time

Run every workload — not your whole account, each workload separately — through these six questions in order. Stop at the first one that fits.

1. Can it be interrupted and restart cleanly, with at most a couple of minutes' notice? If yes, go to Spot. Diversify across several instance types and Availability Zones so a single capacity crunch doesn't take out everything at once, and let EC2 Auto Scaling or EC2 Fleet manage the pool for you rather than requesting individual instances by hand.
2. Is this a database, cache, or data warehouse service (RDS, Aurora, DynamoDB, ElastiCache, Redshift, OpenSearch, DocumentDB, Neptune, Timestream, or a similar managed data store)? If yes, a Database Savings Plan is the purpose-built option — it covers that whole family of services under one commitment.
3. Is this Amazon SageMaker AI training or inference usage? If yes, a SageMaker AI Savings Plan is the dedicated option, the same way EC2 has its own plan type.
4. Do you specifically need guaranteed capacity in one exact Availability Zone — not just a lower price, but a guarantee the instance will be there when you launch it, for something like a disaster-recovery standby or a launch-day spike you can't risk missing? If yes, a Zonal Reserved Instance is the only one of the three that carries a capacity guarantee at all. Everything else in this list is a billing discount only.
5. Is the workload's steady-state usage locked in — same instance family, same Region, for the length of the term — and you're confident that won't change? If yes, an EC2 Instance Savings Plan gets you the same ceiling discount as a Standard Reserved Instance, without giving up the ability to move between sizes, operating systems, or tenancy inside that family.
6. Everything left over — steady, has to run every hour, but you can't promise the exact instance family, size, or even the Region won't change — belongs on a Compute Savings Plan. It's the lowest ceiling discount of the group, and it's the right trade for anyone still evolving their architecture, which in practice is almost everyone.

Reserved Instances, and why AWS itself now points elsewhere

A Reserved Instance isn't a physical machine set aside for you. It's a billing discount that applies automatically whenever your running usage matches the Reserved Instance's attributes: instance type, Region, tenancy, and platform (operating system). Buy one that matches nothing you're running yet, and it just sits there unused until you launch something that fits it — or it expires and you've paid for nothing.

Four things decide its price and its rigidity:

Term: one year or three years

A one-year term runs 365 days; a three-year term runs 1,095 days. The three-year commitment gets the bigger discount, and it also locks in your bet for three times as long — Jake's mistake, at three-year scale.

Offering class: Standard or Convertible

Standard Reserved Instances carry the biggest discount but can only be modified, never exchanged — you're stuck with the instance family you picked. Convertible Reserved Instances trade some discount for the ability to exchange into a different Convertible RI later, as long as the new one is of equal or greater value. If there's any real chance you'll change families, Convertible is the safer bet even at a smaller headline number.

Scope: Regional or Zonal

A Regional Reserved Instance applies its discount across an entire AWS Region and gives you Availability Zone flexibility, plus the option of "size flexibility" — one large RI's discount can cover several smaller instances in the same family proportionally, using a normalized-unit system so, for example, one c4.8xlarge RI's benefit can instead cover two c4.4xlarge instances, or sixteen c4.large instances, or any mix that adds up to the same normalized amount. A Zonal Reserved Instance is pinned to one specific Availability Zone, and in exchange it reserves actual capacity there — the only guarantee-of-availability feature in this whole comparison lives here, not in the discount itself.

Payment option: how you split the bill

Savings Plans: the same discount, without picking a family for life

A Savings Plan is a commitment to spend a consistent dollar amount per hour — not a commitment to a specific machine. You pick a number, say $3.00/hour, for one or three years, and AWS applies the discounted rate to your eligible usage up to that amount automatically; anything above it is billed at the regular On-Demand rate. There are four types, and picking the wrong one is the single most common way people leave money on the table.

Compute Savings Plans — the most forgiving option

Compute Savings Plans reduce cost by up to 66% and apply automatically to EC2 regardless of instance family, size, Availability Zone, Region, operating system, or tenancy — and they also cover AWS Fargate and AWS Lambda. Move a workload from one instance family to another, shift it to a different Region, or migrate it from EC2 onto Fargate or Lambda entirely, and the discount follows you without any manual exchange. This is the plan for a team that's still refactoring.

EC2 Instance Savings Plans — the deepest discount, one family at a time

EC2 Instance Savings Plans offer savings up to 72% — the same ceiling as a Standard Reserved Instance — in exchange for committing to a specific instance family in one chosen Region, for example m5 usage in N. Virginia. Inside that family, you can still freely change instance size, operating system, and tenancy and keep the discount; you just can't jump to a different family or Region and keep the same plan.

Database Savings Plans — the one Jake didn't know existed

Database Savings Plans cut costs by up to 35% across Amazon Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Amazon Keyspaces, Timestream, AWS DMS, and Amazon OpenSearch Service, and you can move a workload from RDS to DynamoDB, say, and keep the discounted rate. If your bill has any managed database or data-store line item at all, this is the plan type worth checking before you assume Reserved Instances are your only option there.

SageMaker AI Savings Plans

SageMaker AI Savings Plans lower the price of SageMaker AI instance usage regardless of instance family, size, component, or Region — the same flexibility idea as Compute Savings Plans, scoped to machine learning training and inference instead of general compute.

The order AWS applies your discounts in

If you have both Reserved Instances and Savings Plans, this isn't guesswork — there's a defined order. Reserved Instance discounts are applied to matching usage first. Then Savings Plans are applied: within your active plans, AWS calculates the potential savings percentage for every eligible combination of usage and applies your commitment to the highest-savings-percentage usage first. Between plan types, EC2 Instance Savings Plans are applied before Compute Savings Plans, because Compute Savings Plans have broader applicability and AWS reserves them for whatever's left. In a Consolidated Billing family with sharing enabled, the owner account's usage is covered first, then linked accounts. None of this needs to be manually managed — it's how the billing engine already works — but knowing the order explains why adding a second plan sometimes doesn't move your bill the way you expected.

Spot Instances: the deepest discount, with a two-minute catch

Spot Instances are unused EC2 capacity, offered at up to 90% off the On-Demand price. There is no bidding, no commitment, no term — you request them, you pay the current Spot price for that instance type in that Availability Zone, and you keep the instance until either you release it or Amazon EC2 needs the capacity back.

That second condition is the entire trade-off. When EC2 reclaims a Spot Instance — mainly to give the capacity back to a paying On-Demand or Reserved customer, though it can also happen for host maintenance or hardware decommissioning — it's called a Spot Instance interruption, and Amazon EC2 gives you a warning of roughly two minutes before it terminates, stops, or hibernates the instance, depending on which interruption behavior you configured. Two minutes is enough time for a well-built application to save its state, deregister from a load balancer, and shut down cleanly. It is not enough time for a database to fail over gracefully or a stateful session to migrate somewhere else — which is exactly why the interruption-tolerance question sits first in the decision tree above, not last.

One detail that surprises people who assume every discount stacks: Spot Instances are not covered by Savings Plans. If you have an active Compute Savings Plan, it does not apply any additional discount on top of your Spot usage, and your Spot spend does not count toward or draw down your Savings Plan commitment either. They're two separate discount systems that happen to sit in the same account.

Good fits: containerized workloads on ECS, EKS, or self-managed Kubernetes; big data and Spark or EMR jobs; CI/CD build runners; batch processing through AWS Batch; and machine learning training, where SageMaker can manage the interruptions on your behalf. Bad fits: anything holding a database write path, anything with a single point of failure and no redundancy, and anything where "restart in two minutes" isn't actually true for your architecture yet, even if you'd like it to be.

All three, side by side

Layering all three, in the order that actually works

Ethan's opinion, stated plainly: don't pick one of these three. Most real AWS bills are a mix, and the mix follows a simple shape — think of it as layers stacked from the bottom up, not competing options.

1. Measure your true floor first. Look at 30 to 60 days of usage and find the amount of compute that never drops below, even at 3 a.m. on a Sunday. That number — not your peak, not your average — is what you commit to.
2. Cover the floor with a Compute Savings Plan. Start here rather than an EC2 Instance Savings Plan or Standard RI, even though it has a slightly lower ceiling, because the flexibility protects you the way it didn't protect Jake.
3. Once you're confident a specific family and Region are permanent, layer in an EC2 Instance Savings Plan on top of that portion. The two plan types are applied together automatically — EC2 Instance Savings Plans first, then Compute Savings Plans on whatever's left — so you're not choosing one over the other forever, you're refining as certainty increases.
4. Push everything interruption-tolerant onto Spot, separate from the commitment math entirely, since Spot spend doesn't touch your Savings Plan commitment either way.
5. Only add a Zonal Reserved Instance if a specific workload needs a capacity guarantee in one exact Availability Zone — not as a general-purpose discount tool.
6. Recheck every 60 to 90 days, using AWS Cost Explorer's built-in Savings Plans and Reserved Instance recommendations, which analyze your actual usage history and suggest a commitment size and mix — rather than guessing from memory the way Jake did the first time.

Buying commitments when you have more than one AWS account

Jake's shop is a one-account operation, but the moment a business splits staging from production, or adds a second brand under the same AWS Organization, the layering advice above needs one more layer of its own: where inside the organization do you actually buy the commitment?

By default, sharing is turned on for every account in an AWS Organization. That means a Savings Plan or Reserved Instance bought in any one account isn't limited to that account — it's shared across the whole consolidated billing family. The commitment first applies to usage in the purchasing account; if there's any unused hourly commitment left over, it's automatically applied to other accounts in the organization that also have sharing turned on, prioritizing whichever accounts get the largest calculated savings from it. Nobody has to move the discount around manually — it follows the usage.

The management account can turn sharing off for any account, including itself, and both sides of a pairing have to have sharing turned on for the discount to actually cross between them. Turning sharing off is sometimes done deliberately — for cost allocation clarity between business units that get billed separately — but it's worth knowing it's a switch that exists, because deactivating it can raise your organization's total bill if it was quietly covering usage in an account you'd forgotten about.

One practical pattern worth knowing, sourced from how the sharing mechanism itself works rather than from any one team's preference: a Savings Plan purchased in an account that has no EC2, Fargate, or Lambda usage of its own has nothing to consume the commitment locally, so its entire hourly amount is immediately available to share out to other accounts in the family. Some organizations use their management or a dedicated billing account for exactly this reason — it keeps the commitment centralized instead of tied to whichever team happened to buy it. Whether that fits your setup depends on how your organization allocates cost internally, which this article can't tell you — but the mechanism itself is worth understanding before you decide.

The cases the tidy version of this advice skips

Your usage is genuinely spiky, not steady

If there's no real floor — usage swings from near-zero to a burst and back, with no predictable baseline — none of the three commitment models fit yet, and that's a legitimate answer, not a failure to research hard enough. Stay on On-Demand, keep measuring, and revisit once a pattern actually exists. Committing to a number you're guessing at just recreates Jake's original problem in a different shape.

You need guaranteed capacity but also want flexibility

This is the case most guides quietly skip. If a workload needs both a capacity guarantee and the freedom to change configuration, the two things this article covers don't do it alone — Reserved Instances guarantee capacity but lock configuration, Savings Plans stay flexible but guarantee nothing. The combination worth knowing about is an On-Demand Capacity Reservation (which reserves the seat without locking you into an instance-attribute commitment) paired with a Savings Plan for the discount. That's a genuinely different tool from anything above, and it's worth its own separate research if guaranteed capacity is a hard requirement for you.

You already bought the "wrong" one

If it's a Reserved Instance and you're stuck: a Standard RI can be modified — Availability Zone, scope, or network platform within the same family — but not exchanged; a Convertible RI can be exchanged for a different Convertible RI of equal or greater value; either can be listed on the Reserved Instance Marketplace if you'd rather recover some of the cost than keep paying for unused capacity. If it's a Savings Plan you're overcommitted on, there's no marketplace resale — the commitment runs its course, which is exactly why sizing it to your measured floor rather than your hoped-for growth matters more than which plan type you pick.

Where the popular advice gets it backward

A lot of older cost-optimization advice still treats Reserved Instances as the serious, grown-up choice and Savings Plans as the "flexible but slightly worse" alternative. That framing has it backward for most accounts today. The discount ceilings are effectively the same tier for tier — up to 72% for both a Standard RI and an EC2 Instance Savings Plan, up to 66% for both a Convertible RI and a Compute Savings Plan — so the only real question is which one survives you changing your mind. Reserved Instances don't. Savings Plans do. That's not a minor footnote; it's the entire reason Amazon's own documentation now leads with the recommendation to use Savings Plans instead.

The other backward piece of advice: "avoid Spot, it's unreliable." Spot's discount is real and its interruption risk is manageable for the workloads it's actually meant for — the mistake isn't choosing Spot, it's choosing it for a workload that needed a guaranteed, stateful, always-on machine in the first place. That's a workload-fit problem, not a Spot problem.

Where to find AWS's own recommendations

You don't have to size any of this from memory. In the Billing and Cost Management console, under Reservations, the Recommendations page analyzes your On-Demand usage over a period you choose — the last 30, 60, or whatever number of days you set — and calculates the specific mix of Reserved Instances that would have saved you the most, sortable by monthly estimated savings, upfront cost, or instance type. Cost Explorer does the equivalent calculation for Savings Plans, and it also factors in size-flexible Regional RIs so it isn't just comparing exact-match usage.

Separately, rightsizing recommendations — powered by AWS Compute Optimizer — flag EC2 instances that are oversized or underused, including options across different instance families, not just within the one you're already running, with estimated savings that already account for your existing Reserved Instances and Savings Plans discounts. Run rightsizing first, then size your commitment against what's left — committing to a number before rightsizing just locks in the waste.

AWS Trusted Advisor adds a third layer worth checking on top of both: it includes a dedicated Savings Plan check that reviews your EC2, Fargate, and Lambda usage and surfaces purchase recommendations directly, alongside separate Reserved Instance optimization checks for services like RDS, ElastiCache, Redshift, and OpenSearch. It also carries a Reserved Instance lease-expiration check, which is the piece easiest to forget about — a warning before a Standard RI's term runs out and its usage quietly reverts to full On-Demand pricing overnight. More recently, Trusted Advisor's cost checks have been expanded by pulling in recommendations from the AWS Cost Optimization Hub, which combines Reserved Instance, Savings Plans, and rightsizing data into a single prioritized list — though getting the full set of checks requires opting in to both Cost Optimization Hub and Compute Optimizer first, since Trusted Advisor doesn't turn either of them on for you automatically.

Frequently asked questions

What's the actual difference between Reserved Instances and Savings Plans?

A Reserved Instance commits you to a specific instance configuration — type, Region, tenancy, and platform. A Savings Plan commits you to a dollar-per-hour spending amount and applies its discount to whatever eligible usage best matches that commitment, letting the underlying instance configuration change freely.

Can I use Spot Instances with a Savings Plan for extra savings on top?

No. Spot Instances are not covered by Savings Plans, so an active Savings Plan doesn't add any further discount to Spot usage, and Spot spend doesn't count against or draw down your Savings Plan commitment either. Treat them as two separate discount tracks.

Which of the three actually saves the most money?

Spot has the highest ceiling, up to 90% off, but only for workloads that can tolerate interruption. Among the commitment-based options, a Standard RI and an EC2 Instance Savings Plan share the top discount tier at up to 72%; the difference is that only one of them survives you changing your instance family.

What happens if I stop using an EC2 Instance Savings Plan mid-term?

You keep paying the committed hourly amount for the rest of the term regardless of whether matching usage exists — there's no early exit and no partial refund built into the plan itself.

Can I cancel a Reserved Instance if I no longer need it?

No, purchases can't be canceled. Depending on the offering class you may be able to modify it, exchange a Convertible RI for a different one of equal or greater value, or sell it on the Reserved Instance Marketplace, but there's no direct cancellation.

What's the difference between Standard and Convertible Reserved Instances?

Standard RIs carry the bigger discount but can only be modified, never exchanged into a different instance family. Convertible RIs carry a smaller discount in exchange for the ability to be exchanged for a different Convertible RI of equal or greater value later.

Do Savings Plans apply to Lambda and Fargate, or just EC2?

Compute Savings Plans cover EC2, AWS Fargate, and AWS Lambda usage together. EC2 Instance Savings Plans, by contrast, apply only to EC2 usage within the specific instance family and Region you committed to.

What's a Zonal RI versus a Regional RI, and which should I buy?

A Regional RI applies its discount across a whole Region and offers Availability Zone and size flexibility, but no capacity guarantee. A Zonal RI is pinned to one Availability Zone and, in return, actually reserves capacity there. Buy Zonal only if you specifically need that guarantee; otherwise Regional's flexibility is generally the safer default.

How much warning do I get before a Spot Instance is interrupted?

Amazon EC2 gives roughly two minutes' notice before terminating, stopping, or hibernating a Spot Instance it needs back, depending on the interruption behavior you configured.

Are Spot Instances actually safe to use in production?

For workloads built to handle interruption — stateless services, workers behind a queue, batch and CI/CD jobs — yes, and AWS documents best practices around instance-type diversification and allocation strategy specifically to support that use. For anything stateful with no graceful restart path, it's not the right tool regardless of how reliable Spot has been generally.

Can I have Reserved Instances and Savings Plans active in the same account?

Yes, and it's common. Reserved Instance discounts are applied to matching usage first; Savings Plans are then applied to remaining eligible usage, EC2 Instance Savings Plans before Compute Savings Plans.

What is a Database Savings Plan and what exactly does it cover?

It's a Savings Plan type covering Amazon Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Amazon Keyspaces, Timestream, AWS DMS, and Amazon OpenSearch Service, with savings up to 35%, and it lets you move usage between covered services while keeping the discounted rate.

How does AWS decide which discount to apply first when I have both RIs and Savings Plans?

Reserved Instance discounts apply first to matching usage. Savings Plans then apply to the remaining eligible usage, starting with whichever combination gives the highest savings percentage, and EC2 Instance Savings Plans are applied before Compute Savings Plans.

Is All Upfront, Partial Upfront, or No Upfront the best payment option?

All Upfront gets the deepest discount at the cost of paying everything at purchase; No Upfront gets the smallest discount but needs no cash upfront and instead bills a discounted hourly rate for the whole term regardless of use. There's no universally best choice — it depends on whether the bigger discount or the lighter cash-flow hit matters more to your business right now.

How do I find out what AWS itself recommends for my account instead of guessing?

In the Billing and Cost Management console, the Reservations Recommendations page and the Savings Plans recommendations both analyze your recent usage history and suggest a sized commitment, Compute Optimizer's rightsizing recommendations flag oversized instances first, and Trusted Advisor's Savings Plan and Reserved Instance checks (plus its Cost Optimization Hub-powered checks, once you opt in) surface the same kind of guidance in one place.

If I don't use my full Savings Plan commitment one month, do I lose that money?

Yes, in the sense that the committed hourly amount is billed whether or not matching usage exists to apply it to — there's no rollover of unused commitment to a future month. That's exactly why sizing the plan to your measured, conservative usage floor rather than an optimistic average matters more than which plan type you choose.

Revision note. Written September 2026, covering the current Reserved Instance, Savings Plans (Compute, EC2 Instance, Database, and SageMaker AI), and Spot Instance pricing models as documented by AWS, including how commitments share across AWS Organizations accounts. This will need a fresh look whenever AWS changes a discount ceiling, adds another Savings Plan type, or reworks its sharing rules — check back if your console numbers don't match what's here. If you're the one staring at a bill trying to figure out where the money went, you're not the only one who's found this more confusing than it should be, and it's worth the hour it takes to get it right..Happy learning, See you on next post..!!