Every AWS account team eventually runs into the same expensive surprise: two engineering teams running nearly identical EC2 fleets, paying wildly different bills, because one picked the right purchasing model and the other never left On-Demand. AWS offers four distinct ways to pay for the same compute capacity, and the gap between the cheapest and most expensive option can run to Up to **72% off On-Demand** for identical hardware. [5][13] Yet most teams default to whatever the console suggests first and never revisit the decision.
This comparison breaks down AWS Reserved Instances, Savings Plans, Spot Instances, and On-Demand pricing using AWS’s own published rates and terms, with real dollar figures, flexibility trade-offs, and the workload patterns that fit each one. If your team is trying to cut EC2 spend in 2026 without breaking production, the numbers below should settle the debate.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why AWS EC2 Pricing Strategy Matters in 2026
AWS EC2 pricing is not one price. It is four separate pricing systems bolted onto the same underlying hardware, and the choice between them is arguably the single biggest lever a team has over its cloud bill, short of shutting workloads off entirely. On-Demand Instances charge full price with zero commitment. Reserved Instances lock in a specific instance configuration for one or three years in exchange for a steep discount. Savings Plans trade a dollar-per-hour spend commitment for a similar discount with far more flexibility. Spot Instances rent AWS’s unused capacity at the deepest discount of all, with the catch that AWS can take it back with little warning.
None of this is a footnote. Cloud cost overruns are now a board-level concern at most mid-size and large engineering organizations, and EC2 typically represents the largest single line item on an AWS bill. Our earlier coverage of rising cloud waste as AI spend breaks budgets found that unused or misallocated compute is one of the fastest-growing sources of overspend, and purchasing-model mismatch sits near the top of that list. AWS has also started shipping its own automated tooling to catch this, which we covered when AWS launched a free FinOps agent aimed at exactly this kind of waste.
The core tension is simple to state and hard to execute well: deeper discounts demand more commitment, and more commitment means less room to adapt when workloads change. A team that over-commits to three-year Reserved Instances on the wrong instance family ends up paying for capacity it no longer needs. A team that never commits at all pays full On-Demand price forever. The right answer, for almost every organization, is a blend of all four models mapped to how predictable each workload actually is. The rest of this piece works through that mapping with AWS’s published numbers.
AWS On-Demand Instances: The Baseline Everyone Starts From
On-Demand is the default. There is no commitment, no upfront payment, and no discount. You launch an instance, AWS bills you for what you use, and you stop paying the moment you terminate it. Linux instances bill per second with a 60-second minimum, which makes On-Demand the only model with genuinely frictionless entry and exit.
That flexibility is the entire point, and it is also the entire cost. Because On-Demand is the reference price against which every other model’s discount is measured, it is the most expensive way to run steady-state production traffic over any meaningful stretch of time. Where On-Demand earns its keep is at the edges: short-lived experiments, unpredictable traffic spikes that do not fit a committed baseline, brand-new workloads where usage patterns are not yet known, and any capacity you genuinely might turn off next month. AWS publishes current On-Demand rates by instance type and region on its EC2 On-Demand pricing page, and that page is the number every other pricing model discounts against.
The mistake we see most often is teams treating On-Demand as the safe, conservative default for everything, including workloads that have run unchanged for a year. If a fleet has a predictable floor of usage, even a small one, that floor is money left on the table every hour it sits on On-Demand pricing instead of a committed plan.
AWS Reserved Instances Explained
Reserved Instances, or RIs, are the oldest of AWS’s discount instruments and the most rigid. You commit to a specific instance family in a specific region for a one-year or three-year term, choose a payment option (No Upfront, Partial Upfront, or All Upfront), and AWS applies the discount automatically to matching usage. According to AWS’s own EC2 pricing guidance, Reserved Instances can cut costs by up to 72% compared with On-Demand rates at the three-year, all-upfront tier, detailed on AWS’s Reserved Instances pricing page.
Standard vs Convertible Reserved Instances
AWS sells two flavors. Standard RIs carry the deepest discount but lock you into the exact instance family, size, and region you picked at purchase time, with only limited size flexibility inside the same instance family. Convertible RIs trade some of that discount for the ability to exchange the reservation for a different instance family, operating system, or tenancy later in the term. Neither type follows your workload across regions the way a Savings Plan can, and both are billing instruments tied to EC2 specifically. AWS’s cost optimization whitepaper on reservation models walks through the mechanics in more depth, including how unused RIs can be resold.
Reserved Instances make the most sense when a team already knows, with a high degree of confidence, exactly which instance family and region a workload will run in for the next one to three years. A legacy monolith that has not changed its instance type in two years is a good candidate. A service still being actively re-architected is not.
AWS Savings Plans Explained
Savings Plans launched specifically to fix Reserved Instances’ rigidity problem. Instead of committing to a specific instance configuration, you commit to spending a set dollar amount per hour on compute for one or three years, and AWS automatically applies the discount to whatever usage qualifies, even as your instance mix changes underneath that commitment.
Compute Savings Plans vs EC2 Instance Savings Plans
AWS splits Savings Plans into two tiers. Compute Savings Plans are the more flexible of the two: the discount, up to **66% versus On-Demand** by AWS’s own EC2 purchasing guidance, applies automatically across **EC2, AWS Fargate, and AWS Lambda**, regardless of instance family, size, operating system, tenancy, or region. [2][9] That breadth makes Compute Savings Plans the closest thing AWS offers to a set-and-forget discount that survives a re-architecture.
EC2 Instance Savings Plans trade some of that flexibility for a deeper discount, up to 72%, but the commitment is tied to a single instance family within a single region. You can still change instance size within that family and the discount follows, but switching families or regions means the plan no longer applies at the higher rate. Full pricing detail for both tiers is published on AWS’s Savings Plans overview page and its Compute Savings Plans pricing page.
The practical distinction from Reserved Instances is worth repeating because it trips up a lot of FinOps newcomers: Savings Plans commit you to a spend rate, not a machine. Reserved Instances commit you to a machine. If your workloads shift instance families every few months as new generations ship, Savings Plans preserve the discount through that change. Reserved Instances do not.
AWS Spot Instances Explained
Spot Instances are AWS’s spare capacity, sold at a steep discount, up to 90% versus On-Demand according to AWS’s EC2 Spot Instances page, with no commitment required in either direction. You do not promise AWS anything, and AWS does not promise you the instance will still be running an hour from now.
That is the trade at the center of Spot: the deepest discount of any AWS purchasing option, paid for with capacity risk instead of a financial commitment. When AWS needs that capacity back for On-Demand or committed customers, it reclaims the instance and gives your application an interruption notice before doing so. AWS’s Spot Instances documentation covers the interruption mechanics in detail, and AWS is explicit that it does not publish one universal interruption rate. Actual interruption frequency depends heavily on instance family, region, availability zone, and how much spare capacity exists in that pool at any given moment, so treat any specific interruption percentage you see quoted elsewhere as a snapshot for one instance type in one region, not a global constant.
Spot pricing floats with supply and demand rather than sitting at a fixed discount, and pricing, availability, and capacity vary independently by instance type, region, and availability zone. That makes Spot the most operationally demanding of the four models. It rewards teams that design for interruption from the start rather than bolting fault tolerance on afterward.
Full Comparison: AWS Pricing Models Specs and Terms Side by Side
The table below lines up all four purchasing options against the attributes that actually change how you architect around them: discount depth, lock-in, service coverage, and risk profile.
| Attribute | On-Demand | Reserved Instances | Savings Plans | Spot Instances |
|---|---|---|---|---|
| Maximum discount vs On-Demand | 0% (baseline) | Up to 72% (3-year, all upfront) | Up to 72% (EC2 Instance SP) / up to 66% (Compute SP) | Up to 90% |
| Commitment term | None | 1 or 3 years | 1 or 3 years | None |
| Payment options | Pay-as-you-go | No / Partial / All Upfront | No / Partial / All Upfront | Pay current Spot market price |
| Instance family flexibility | Full | Low (Standard) / Moderate (Convertible) | High (Compute SP) / size-flexible within family (EC2 Instance SP) | Full, subject to available capacity |
| Region flexibility | Full | Tied to purchase region/AZ scope | Any region (Compute SP) / one region (EC2 Instance SP) | Full, subject to available capacity |
| OS and tenancy flexibility | Full | Constrained to purchased attributes | Full (Compute SP) | Full |
| Services covered | EC2 only | EC2 only | EC2, Fargate, and Lambda (Compute SP) / EC2 only (EC2 Instance SP) | EC2 only |
| Capacity assurance | None guaranteed | Can be paired with Capacity Reservations | Can be paired with Capacity Reservations | None — capacity can be reclaimed |
| Interruption risk | None | None | None | Yes, with an AWS-issued warning before reclaim |
| Billing granularity | Per-second, 60-second minimum (Linux) | Hourly, applied automatically to matching usage | Hourly dollar commitment, applied automatically | Per-second, at the prevailing Spot rate |
| Best for | Unpredictable or short-lived workloads | Known, stable, EC2-only footprints | Broad steady-state spend across compute services | Fault-tolerant, interruptible, batch-style workloads |
| Resale or exchange option | Not applicable | Convertible RIs can be exchanged for different attributes, and unused Standard RIs can be sold on the RI Marketplace | No resale mechanism | Not applicable |
Two patterns jump out. First, Savings Plans and Reserved Instances land in roughly the same discount range, up to **72% at the top end** is not the whole story, because AWS documents **up to 72% off** for certain Reserved Instance purchases and **up to 90% off** for Spot, so price can be a major factor. [5][13] It is about whether you can predict your instance mix (pick Reserved Instances) or your dollar spend (pick Savings Plans). Second, Spot stands alone as the only option where the discount is paid for with operational risk instead of reduced flexibility. Everything else trades flexibility for discount. Spot keeps the flexibility and trades away the reliability guarantee instead.
Pricing Table: Real Dollar Savings by Instance Type
Percentages are useful for comparing models, but engineers budgeting a fleet want dollar figures. The table below applies AWS’s published maximum discounts to three common us-east-1 On-Demand Linux rates: a general-purpose m6i.xlarge, a compute-optimized c6i.xlarge, and a memory-optimized r6i.xlarge, all at a 730-hour month.
| Instance type | On-Demand (per hour / per month) | At up to 72% off (RI or Savings Plan, monthly) | At up to 90% off (Spot, monthly) |
|---|---|---|---|
| m6i.xlarge (general purpose) | $0.1920 / $140.16 | ~$39.24 | ~$14.02 |
| c6i.xlarge (compute optimized) | $0.1700 / $124.10 | ~$34.75 | ~$12.41 |
| r6i.xlarge (memory optimized) | $0.2520 / $183.96 | ~$51.51 | ~$18.40 |
Those RI and Savings Plan figures assume the maximum published discount at a three-year, all-upfront commitment, and actual realized savings depend on the specific term, payment option, instance family, and region you choose. AWS does not publish one universal discount table covering every term and payment combination, so treat the “up to” figures as a ceiling, not a guarantee. The gap is still the headline number here: on a single r6i.xlarge, the difference between leaving it on On-Demand and running it on Spot is roughly $165 a month, or close to $2,000 a year, for one instance. Multiply that across a fleet of a few hundred instances and the purchasing-model decision stops being a rounding error and starts being a budget line item CFOs ask about directly.
Flexibility and Lock-In: What You Give Up for the Discount
Every discount AWS offers below On-Demand is a trade, and the currency is flexibility. Standard Reserved Instances sit at the far end of that trade: the deepest RI discount, paired with the least room to change your mind. Lock in a c6i family in us-east-1 for three years and that is what you have, aside from limited size adjustments within the family.
Convertible Reserved Instances loosen that constraint by letting you exchange the reservation for a different instance family, OS, or tenancy mid-term, at the cost of a smaller discount than Standard RIs typically offer. Compute Savings Plans go further still, following your workload across instance families, sizes, operating systems, and regions, and across EC2, Fargate, and Lambda simultaneously, because the commitment is denominated in dollars rather than hardware. EC2 Instance Savings Plans sit in between: full size flexibility within one instance family in one region, but nothing beyond that boundary.
Spot Instances break this pattern entirely. There is no configuration lock-in at all. You can launch whatever instance type has available capacity, in whatever region you want, and change your mind every hour with zero financial penalty. The cost is not measured in flexibility given up. It is measured in the possibility that AWS reclaims the instance while your workload is mid-task. For teams weighing purchasing models, the honest framing is that Reserved Instances and Savings Plans ask you to be confident about the future. Spot asks you to be resilient to it instead.
Spot Instance Interruptions: What Engineers Need to Know
Running production workloads on Spot is less about chasing the biggest possible discount and more about building software that treats interruption as a normal event rather than an outage. AWS issues an interruption notice through the instance metadata service and, optionally, through Amazon EventBridge before reclaiming a Spot Instance, giving an application a window to checkpoint state, drain connections, or hand off work before the instance disappears. Exactly how much warning you get and how often it happens varies by instance family, region, and availability zone, which is why AWS avoids publishing a single global interruption number.
The standard mitigation pattern is diversification: spread a fleet across multiple instance families and availability zones using EC2 Auto Scaling groups or EC2 Fleet with a mixed-instance policy, so that losing one Spot pool does not take down the whole workload. Batch jobs checkpoint progress regularly. Stateless services sit behind a load balancer that can route around an interrupted node in seconds. None of this is exotic engineering, but it does mean Spot adoption is a design decision, not just a purchasing decision.
Netflix’s engineering team documented one of the earliest large-scale examples of this pattern on its technical blog, describing an internal spot-market-style system built for video encoding workloads and reporting roughly 92% cost efficiency compared with running the same encoding fleet on On-Demand capacity. The architecture predates some of AWS’s current Spot tooling, but the underlying principle, treat interruptible capacity as the default for anything that can tolerate it, still holds and is documented in Netflix’s engineering writeup.
5 Real-World Use Cases and Which Pricing Model Fits
Abstract discount percentages only go so far. Here is how the decision plays out across five workload patterns most engineering teams actually run.
- Steady-state production web tier. A fleet of application servers that has run the same instance family at roughly the same scale for the past six months is the textbook case for Reserved Instances or EC2 Instance Savings Plans. The workload is predictable, EC2-only, and rarely changes instance family, so the deeper discount is worth the commitment.
- ML training and batch processing. Training jobs that checkpoint progress and can resume from the last saved state are close to ideal for Spot. The workload is inherently fault-tolerant, runs in bursts rather than continuously, and the cost difference at 90% off compounds fast on GPU-heavy training runs.
- CI/CD build fleets. Build and test runners are short-lived, stateless, and easily retried, which makes them another strong Spot candidate. A failed build simply reruns on a new instance, and the discount on a fleet that scales up and down all day adds up quickly.
- Development and test environments. Dev and staging environments are usually too unpredictable for Reserved Instances but too cost-sensitive to leave entirely on On-Demand. A Compute Savings Plan sized to the baseline dev footprint, topped up with On-Demand for spikes, is the common middle ground.
- Disaster-recovery standby capacity. DR environments need capacity assurance more than they need a discount, since the whole point is that the capacity must be there when needed. This is where On-Demand Capacity Reservations paired with a Savings Plan for the discount layer make more sense than Spot, which offers no such guarantee.
Most real fleets are a mix of all five patterns running at once, which is exactly why the highest-performing FinOps teams do not pick one purchasing model. They map each workload to the model that fits its actual predictability and fault tolerance, then revisit that mapping as workloads change.
Capacity Reservations vs Billing Discounts: Do Not Confuse Them
One of the more common points of confusion in AWS cost planning is treating Capacity Reservations as a pricing model alongside Reserved Instances, Savings Plans, and Spot. They are not. On-Demand Capacity Reservations solve a completely different problem: guaranteeing that compute capacity will be available in a specific availability zone when you need it, with no billing discount attached on their own. AWS’s Capacity Reservations documentation is explicit that these are a capacity-assurance mechanism, not a discount mechanism.
The discount comes from pairing a Capacity Reservation with a Savings Plan or a Regional Reserved Instance, which layers the billing discount on top of the capacity guarantee. AWS also distinguishes between immediate-use Capacity Reservations, which require no commitment, and future-dated reservations, which do require a commitment starting on the reservation’s start date. For teams running mission-critical workloads that cannot risk a capacity shortfall during a regional event, this two-layer structure, capacity assurance plus a separate discount instrument, is worth understanding before assuming a Reserved Instance alone guarantees a machine will be there when needed.
What Changed in AWS EC2 Pricing for 2025 and 2026
The most significant recent shift landed in mid-2025 and is still shaping GPU capacity planning heading through 2026. Starting June 1, 2025, AWS cut On-Demand pricing on its accelerated compute instances: P5 instances dropped by up to AWS’s June 2025 GPU price cut was **up to 45%** for **P4/P5** families overall, with specific cuts of **45% for P5 under 3-year EC2 Instance Savings Plans** and **26% for P5en under 3-year EC2 Instance Savings Plans**. [3][7] AWS applied the corresponding effects to Savings Plans purchased against those instance families starting June 4, 2025.
That matters for anyone weighing a multi-year Savings Plan or Reserved Instance commitment on GPU capacity right now, because the baseline On-Demand rate those discounts are calculated against has already moved once in the past year and could move again as newer accelerator generations ship. Teams locking in long-term GPU commitments in 2026 should treat that June 2025 repricing as a reminder that the underlying On-Demand rate is not static, and a three-year commitment made today is a bet on where AWS’s GPU pricing sits over the full term, not just where it sits this quarter.
Migration Guide: From On-Demand to a Committed-Spend Strategy
Moving a fleet that has been running entirely On-Demand into a blended purchasing strategy does not require a big-bang cutover. A staged approach keeps risk low while capturing most of the available savings within a single billing cycle.
- Pull at least 30 to 60 days of usage history from AWS Cost Explorer to establish a real baseline rather than guessing at steady-state load.
- Identify the floor: the minimum amount of compute that has run continuously across that window, regardless of daily or weekly spikes. That floor is your committed-spend candidate.
- Start with a Compute Savings Plan sized to a conservative fraction of that floor, since it is the most forgiving instrument if your architecture changes mid-term.
- Layer in EC2 Instance Savings Plans or Reserved Instances only for workloads you are confident will keep the same instance family for the full term.
- Identify anything fault-tolerant, batch, or easily retried, and move it to Spot with a diversified instance pool rather than a single instance type.
- Set up Capacity Reservations for any workload where availability during a regional capacity crunch matters more than the discount.
- Re-check coverage and utilization monthly using Cost Explorer’s Savings Plans recommendations, and resize the commitment as usage shifts.
Cost Explorer’s API can generate a Savings Plans purchase recommendation directly from your usage history, which is a useful sanity check before committing real dollars:
aws ce get-savings-plans-purchase-recommendation
--savings-plans-type COMPUTE_SP
--term-in-years THREE_YEARS
--payment-option ALL_UPFRONT
--lookback-period-in-days SIXTY_DAYSFor teams evaluating Spot adoption, checking recent price history for a candidate instance type is a quick first step before building out a fleet:
aws ec2 describe-spot-price-history
--instance-types m6i.xlarge
--product-descriptions "Linux/UNIX"
--max-items 5Neither command commits you to anything. Both are read-only checks worth running before a team debates purchasing strategy in a meeting instead of looking at its own usage data first.
How to Measure Whether Your Purchasing Strategy Is Working
Buying Reserved Instances or Savings Plans is the easy part. Knowing whether that purchase is actually saving money six months later is where most teams lose the thread. AWS Cost Explorer tracks two metrics that answer that question directly, and both are worth checking on a recurring schedule rather than once at purchase time.
Coverage measures what percentage of your eligible usage is covered by a Reserved Instance or Savings Plan versus running at full On-Demand rates. Low coverage on a workload with a known, stable floor is a signal you are leaving discount money on the table. Utilization measures the inverse risk: what percentage of the commitment you actually paid for is being used. A Savings Plan sized for peak traffic that only shows up during a holiday sale will report low utilization the rest of the year, meaning you are paying for committed capacity that is not running anything.
The healthiest pattern is high coverage on your proven, steady-state floor and near-total utilization on whatever commitment you have bought, with On-Demand and Spot absorbing everything above that floor. If either metric drifts, coverage dropping because a workload grew past its commitment, or utilization dropping because a workload shrank below it, that is the trigger to revisit the purchasing mix rather than waiting for the annual budget review to notice a bill that no longer matches expectations.
Pros and Cons of Each AWS Pricing Model
| Model | Pros | Cons |
|---|---|---|
| On-Demand | Zero commitment, full flexibility, simplest to reason about | Most expensive option over any sustained period |
| Reserved Instances | Deepest discount alongside Savings Plans, resale option via Convertible exchange or RI Marketplace | Locked to a specific instance family and region, EC2 only |
| Savings Plans | Discount survives instance-family and region changes, and Compute SP covers EC2, Fargate, and Lambda | Still a 1 or 3-year dollar commitment that must be sized carefully |
| Spot Instances | Deepest available discount, no commitment in either direction | Capacity can be reclaimed with little warning, requires interruption-tolerant architecture |
Common Mistakes That Waste Money on AWS Compute
Most EC2 overspend does not come from picking the wrong pricing model outright. It comes from picking a reasonable model and then managing it poorly. A few patterns show up again and again in cost reviews.
- Over-committing to three-year Reserved Instances before a workload has stabilized. Locking in a specific instance family for the maximum term looks great on a spreadsheet showing the 72% discount, until the team re-architects the service six months later and the RI no longer matches anything running in production.
- Never checking Savings Plans coverage and utilization reports. A Savings Plan sized for last year’s traffic can sit partially unused as workloads shift, quietly burning committed spend on capacity nobody is running. AWS surfaces both metrics directly in Cost Explorer, and teams that do not check them regularly tend to find out only when finance asks why the discount rate on the bill dropped.
- Running Spot fleets on a single instance type. A Spot strategy built around one instance family in one availability zone concentrates all the interruption risk in one pool. Diversifying across several compatible instance types and zones is the difference between a brief, unnoticed reshuffle and a workload going down when AWS reclaims that specific pool.
- Assuming a Reserved Instance guarantees capacity. As covered above, RIs are billing discounts, not capacity guarantees. Teams that need both have to add a Capacity Reservation on top, and skipping that step is a common source of confusion during a regional capacity crunch.
- Letting Reserved Instances or Savings Plans expire unnoticed. Both are set-and-forget in the sense that AWS applies them automatically, but the term still ends. A commitment that expires without a renewal plan quietly reverts every covered instance to full On-Demand pricing, and that shift rarely shows up until the next bill.
- Committing before right-sizing. Buying a three-year Reserved Instance for an oversized instance locks in the waste along with the discount. Right-sizing first, then committing to the corrected footprint, captures savings twice instead of once.
None of these mistakes are exotic. They are the ordinary byproduct of treating a purchasing decision as a one-time task instead of an ongoing process, which is exactly the gap tools like AWS’s own FinOps tooling and third-party cost platforms are built to close.
The Verdict: Which AWS Pricing Model Should You Choose
There is no single winner here, and any article that tells you otherwise is oversimplifying a genuinely multi-dimensional decision. The data does, however, point to a clear default strategy for most teams. Start with a Compute Savings Plan covering your conservative, proven usage floor across EC2, Fargate, and Lambda, since its up-to-66% discount and near-total flexibility make it the lowest-risk way to capture meaningful savings without betting on a specific instance family surviving the full term. Layer in EC2 Instance Savings Plans or Reserved Instances only where a workload has genuinely proven, for months, that it will not change shape, since the extra few points of discount up to 72% only pay off if the commitment actually holds.
Push everything fault-tolerant, batch, or easily retried onto Spot. At up to 90% off On-Demand, Spot is not a marginal optimization. It is frequently the difference between a training run or a CI pipeline costing real money and costing next to nothing, and modern instance-diversification tooling has made the operational overhead far more manageable than it was a few years ago. Reserve On-Demand for what is left over: genuinely unpredictable workloads, brand-new services with no usage history, and short-lived experiments that will not exist long enough for a commitment to make sense. Keep Capacity Reservations in the toolkit specifically for anything where availability during a regional capacity crunch is non-negotiable, and pair them with a Savings Plan rather than assuming the reservation itself provides a discount.
None of this is a one-time decision. Instance generations change, workloads get re-architected, and AWS periodically reprices entire instance families, as it did with accelerated computing in June 2025. Treat the purchasing-model mix as something to revisit quarterly against real Cost Explorer data, not something to set once and forget.
Frequently Asked Questions
What is the maximum discount AWS Savings Plans offer?
EC2 Instance Savings Plans can save up to 72% versus On-Demand pricing, while the more flexible Compute Savings Plans, which also cover Fargate and Lambda, save up to 66%, according to AWS’s published Savings Plans pricing.
Are Reserved Instances better than Savings Plans?
Neither is universally better. Both top out around the same maximum discount, up to 72%. Reserved Instances make more sense when you are certain a workload will keep the same instance family and region for the full term. Savings Plans make more sense when you want the discount to survive changes to instance family, region, or even a shift toward Fargate or Lambda.
How much can I save with AWS Spot Instances?
AWS states Spot Instances can save up to 90% compared with On-Demand pricing. The actual discount at any moment depends on instance type, region, and availability zone, since Spot pricing floats with supply and demand rather than sitting at a fixed rate.
Can I lose data when a Spot Instance is interrupted?
You can, if the workload is not designed for interruption. AWS issues a warning through the instance metadata service before reclaiming a Spot Instance, giving applications time to checkpoint state or drain connections. Workloads that do not handle that warning gracefully risk losing in-progress work, which is why Spot is best suited to fault-tolerant, checkpointed, or easily retried jobs.
Do Savings Plans cover AWS Lambda and Fargate?
Compute Savings Plans cover EC2, Fargate, and Lambda usage under a single commitment. EC2 Instance Savings Plans and Reserved Instances are limited to EC2 only.
Can I combine Reserved Instances and Savings Plans?
Yes. They are not mutually exclusive, and many organizations run both simultaneously across different parts of their fleet. AWS applies discounts in a defined order across whichever combination of RIs and Savings Plans you hold, matching them to eligible usage automatically.
What happens if I stop needing a Reserved Instance I purchased?
Convertible Reserved Instances can be exchanged for a different instance family, OS, or tenancy for the remainder of the term. Standard Reserved Instances cannot be exchanged, but unused ones can potentially be sold on the Reserved Instance Marketplace, subject to AWS’s eligibility rules.
Is On-Demand ever the right choice for production workloads?
Yes, specifically for production workloads that are genuinely unpredictable or too new to have a reliable usage baseline. Most production fleets end up blending On-Demand for the unpredictable portion with a committed instrument for the proven, steady-state floor underneath it.
Related Coverage
- ECS vs EKS vs Fargate: $0 vs $73/mo Control Plane [2026]
- Cloud Waste Hits 29% as AI Spend Breaks Budgets [2026]
- AWS FinOps Agent Launches Free in $16.5B Market [2026]
- Amazon Aurora vs RDS: 5x Faster, 21% Pricier [2026]
- How to Set Up Kubecost: 12 Steps, 60 Min [2026]
- AWS vs Azure 2026: 31% vs 24% Market Share [Tested]
- How to Build an AWS Lambda API: 12 Steps, 60 Min [2026]
For broader context on how cloud providers stack up beyond pricing mechanics, see our full cloud computing coverage.
