Your AWS bill is creeping up, someone upstairs wants it cut, and you’ve got three discount mechanisms staring back at you: Savings Plans, Reserved Instances, and Spot. The marketing copy on all of them says roughly the same thing — “save up to X%” — which is useless when you’re about to lock real money into a one- or three-year commitment.
So here’s the honest breakdown. These three aren’t competitors. They cover different parts of your workload, and the teams that save the most use all three at once. The trick is knowing which dollar of spend belongs to which mechanism.
I’ll go through what each one actually locks you into, the real discount numbers as of 2026, and how to layer them without over-committing yourself into a corner.
The three models, minus the jargon
Savings Plans are a commitment to spend a fixed dollar amount per hour for one or three years. You don’t pick instances — you pledge, say, $5/hour of compute, and AWS automatically applies the discount to whatever compute you run up to that amount. There are two flavors:
- Compute Savings Plans apply across EC2, Fargate, and Lambda regardless of instance family, region, OS, or tenancy. Maximum flexibility.
- EC2 Instance Savings Plans lock you to a single instance family in a single region (you can still change size, OS, and tenancy within that), and pay a deeper discount in exchange.
Reserved Instances are the older model. You commit to a specific instance type, size, platform, and region for one or three years. Standard RIs give the deepest discount but almost no flexibility. Convertible RIs let you swap instance family, size, and OS mid-term for a smaller discount. RIs still matter because — and this is the part people miss — they’re the only commitment that covers the data tier: RDS, ElastiCache, Redshift, and OpenSearch don’t accept Savings Plans.
Spot is the leftover-capacity market. AWS sells unused EC2 capacity at a steep discount, but it can reclaim those instances with a two-minute warning whenever it needs the hardware back. No commitment, no term, cheapest by far, but interruptible.
Discount depth vs flexibility, with real numbers
Here’s where the trade-off lives. More flexibility means a shallower discount. As of 2026:
| Mechanism | Max discount off On-Demand | Flexibility | Term |
|---|---|---|---|
| Compute Savings Plan | ~66% | Highest — any EC2/Fargate/Lambda | 1 or 3 yr |
| EC2 Instance Savings Plan | ~72% | Family + region locked | 1 or 3 yr |
| Standard RI | ~72% | Instance type locked | 1 or 3 yr |
| Convertible RI | ~66% | Family/size/OS swappable | 1 or 3 yr |
| Spot | up to ~90% (realistically 50–70%) | None — can be reclaimed | None |
A few things jump out. The deepest committed discount (~72%) comes from the two least flexible options — EC2 Instance Savings Plans and Standard RIs. The most flexible committed option, Compute Savings Plans, tops out around 66%. That ~6-point gap is the price of flexibility, and for most teams it’s worth paying.
Why? Because over a three-year term, your instance mix will change. You’ll migrate to Graviton, you’ll resize, you’ll move workloads to Fargate. A Standard RI on an m5.xlarge becomes dead weight the moment you move to m7g. A Compute Savings Plan follows you. I’ve watched teams sit on a pile of mismatched Standard RIs that no longer cover anything they run — they bought the deepest discount and got the worst outcome.
Spot’s “up to 90%” headline is real but optimistic. Day to day, most workloads land in the 50–70% range depending on instance type, region, and how hot demand is for that capacity. Still cheaper than any commitment — when it fits.
Spot in 2026: how scary is the interruption really?
The fear around Spot is the reclaim. AWS can take the instance back with two minutes’ notice. That sounds terrifying until you look at the actual rate.
Historically, the average interruption frequency across all regions and instance types has been under 5%. AWS publishes interruption rates in buckets — under 5%, 5–10%, 10–15%, 15–20%, and over 20% — in the Spot Instance Advisor, so you can check before you commit a workload. Pick a less-popular instance family in a less-popular AZ and you can routinely stay in the sub-5% bucket.
Two tools make Spot far less of a gamble than it used to be:
- Spot Instance Advisor shows the historical interruption rate and savings for each instance type, so you can favor types that are both cheap and stable.
- Spot Placement Score gives a near-real-time likelihood (1–10) that a Spot request will succeed in a given region or AZ for the capacity you want. It’s a recommendation, not a guarantee — it won’t promise capacity or a low interruption rate — but it’s a genuinely useful signal for picking where to run.
The honest catch: neither tool guarantees anything. Spot is capacity AWS doesn’t currently need, and “currently” can change. So Spot is safe for workloads that tolerate a node disappearing — batch jobs, CI runners, stateless web tiers behind an autoscaler, data processing that checkpoints. It is not safe for your single stateful database or anything that can’t survive a restart mid-task.
The other thing that’s changed: tooling like Karpenter and EC2 Auto Scaling with mixed instance policies now diversify across dozens of instance types automatically. When one Spot pool dries up, your cluster shifts to another. That diversification is what turned Spot from “scary” into “default for fault-tolerant compute” over the last couple of years.
The layering strategy
Here’s the mental model that ties it together. Picture your compute usage as a graph over time. There’s a flat baseline you always run, a chunk that floats up and down predictably, and spiky elastic capacity on top. Each layer maps to a mechanism.
Bottom layer — the always-on baseline. Whatever you run 24/7 every day of the year. This is your safest commitment territory.
- For the data tier (RDS, ElastiCache, Redshift, OpenSearch), use Reserved Instances — they’re the only option that covers these services, and the baseline here rarely changes.
- For the compute baseline, this is where you decide between deeper-but-rigid and flexible. If you’re confident an instance family is stable for the full term, an EC2 Instance Savings Plan grabs the ~72%. If you expect to evolve, take the ~66% Compute Savings Plan and sleep better.
Middle layer — the floating compute. Capacity that moves around but stays generally present. Cover this with a Compute Savings Plan. Its flexibility means you don’t have to predict exactly which instances will absorb the load — the discount lands wherever the spend goes, including Fargate and Lambda.
Top layer — elastic and fault-tolerant spikes. Batch, CI, async workers, anything stateless behind an autoscaler. Run this on Spot and pay the 50–70% discount with no commitment.
The principle underneath all of it: commit only to what you’re sure you’ll use, and commit deeper the more certain you are. Never commit to your peak. Cover the bottom of the graph with reservations and Savings Plans, and let Spot and On-Demand handle the top.
A worked example
Say you run a steady production workload averaging $10/hour of EC2 On-Demand, plus a Postgres database on RDS, plus a nightly batch pipeline that bursts hard for a few hours.
A rough layering:
- RDS Reserved Instance (3-yr, no upfront) on the database baseline → roughly 40–50% off that line item, and it’s the only way to discount RDS at all.
- Compute Savings Plan committing to ~$6/hour — covering the floor of your EC2 usage that never drops below that. At ~66% off, that $6 of On-Demand-equivalent costs you around $2/hour.
- The remaining ~$4/hour of variable EC2 usage rides at On-Demand for now (you can layer a second, smaller Savings Plan once you’ve watched the pattern for a month).
- The nightly batch moves entirely to Spot at ~60% off.
Blended, the steady EC2 line drops from $10/hour toward roughly $5–6/hour effective, the batch job’s compute cost more than halves, and the database picks up a discount it couldn’t get any other way. None of it required predicting a specific instance type three years out, because the bulk of the commitment sits in a flexible Savings Plan.
The exact percentages depend on your region and instance mix — plug your real numbers into the AWS Pricing Calculator before you buy anything. The point is the shape: reservations and Savings Plans on the floor, Spot on the spikes.
Mistakes that cost real money
Over-committing. The single most common one. You commit to a $/hour rate based on peak usage, then a workload moves or a project winds down, and you’re paying for a commitment you can’t fill. Always size commitments to the floor of your usage, not the average and definitely not the peak. Start with a conservative commitment and add a second tranche later — you can always buy more, but you can’t easily unwind a three-year plan.
Ignoring Convertible RIs when you do need RIs. If you’re committing to instances (not the data tier) and there’s any chance your needs shift, Convertible RIs trade a few points of discount for the ability to exchange. For most people Compute Savings Plans have made Convertible RIs largely redundant — but they still exist for specific reservation-with-capacity scenarios.
Stacking the wrong layers. Buying a Compute Savings Plan and Standard RIs that cover the same instances means the RIs apply first, then the Savings Plan fills around them — fine if intentional, wasteful if you double-covered the same baseline by accident. Look at your coverage and utilization reports in Cost Explorer before adding another commitment.
Treating Spot as free money for the wrong workloads. Putting a stateful service or a non-checkpointed long-running job on Spot to chase the 90% headline is how you end up debugging mysterious 3 a.m. outages. Spot’s discount is compensation for interruptibility — only spend it on things that genuinely tolerate interruption.
Buying before you measure. Don’t commit in your first month on a workload. Watch the usage pattern for at least a few weeks, identify the true floor, then commit to that floor. Cost Explorer’s Savings Plans recommendations are a decent starting point, but they tend to assume your recent usage continues unchanged — sanity-check them against what you actually know about upcoming changes.
Where to start
If you’ve never committed to anything, the highest-leverage first move is almost always a 1-year, no-upfront Compute Savings Plan sized to the conservative floor of your EC2 spend. It’s flexible, it covers serverless too, and the no-upfront option means no big check. From there, move your fault-tolerant batch and CI onto Spot, and add Reserved Instances on the database tier once you know its steady size.
Pull up Cost Explorer this week, find the line on your usage graph that never drops, and commit to a slice below it. That one move tends to pay for itself faster than any amount of right-sizing.
Sources: AWS docs — Compute Savings Plans and Reserved Instances, Amazon EC2 Spot Instances Pricing, Spot placement score — EC2 User Guide