Spot vs Reserved Instances (2026): Savings or Stability

If you are reshaping your cloud bill in 2026, one of the first big decisions is Spot Instances vs Reserved Instances. They are the two ends of the cloud pricing spectrum: one trades stability for the deepest discount, the other trades flexibility for a guaranteed one. The terms below are mostly AWS, but the same trade-off shows up across every major cloud. This post compares them head to head so you can decide where each belongs, or how to run both.

The short answer

• Spot Instances - pick this when your workload can tolerate interruption. Spare capacity at steep discounts off on-demand, ideal for batch jobs, CI, data processing, stateless tiers, and checkpointed ML training. Best when losing a node is recoverable and savings matter most.
• Reserved Instances - pick this for steady, always-on baseline workloads. A one or three year commitment buys a reliable discount with no interruption risk, ideal for production databases and core services. Best when usage is predictable and you can forecast it.
• Both - the mature pattern. Cover the predictable baseline with commitments, run elastic and interruptible capacity on Spot, and keep a little on-demand for spikes.

The rest of this post unpacks that decision in detail.

Deciding factor to pick

Match your priority to the recommendation. This is the Spot vs Reserved Instances decision in one table:

If you only remember one rule: Spot gives maximum savings on interruptible work, Reserved gives a guaranteed discount on steady baseline.

What each tool is

• Spot Instances are spare cloud capacity sold at a steep discount off the on-demand price. The catch is that the provider can reclaim them when it needs the capacity back, typically with a short termination warning - about two minutes on AWS. They are dramatically cheaper but ephemeral, so they fit fault-tolerant, stateless, interruptible, and batch workloads, never a lone stateful critical instance without resilience built in.
• Reserved Instances are a one or three year commitment in exchange for a steady, substantial discount on capacity you run continuously. There is no interruption risk and the price is predictable, which makes them the right fit for always-on baseline workloads like databases and steady production services. The trade-off is flexibility: you are locking in usage, so you need a reasonable forecast.

Spot vs Reserved Instances: head-to-head

When to choose Spot

Pick Spot Instances when:

• Your workload is interruptible and restartable, so losing a node mid-run is an inconvenience rather than an outage.
• You run batch and data processing jobs, CI pipelines, or rendering that can simply retry on fresh capacity.
• Your web tier is stateless and horizontally scaled behind a load balancer, so individual nodes are disposable.
• You train ML models with checkpointing, letting a job resume from the last checkpoint after a reclaim.
• You want the deepest discount available and have engineering willing to design for graceful node loss.
• You can spread across instance types and zones to reduce the chance of losing all your Spot capacity at once.

When to choose Reserved

Pick Reserved Instances (or the equivalent commitment) when:

• Your workload is always-on and predictable, so a year or more of steady usage is easy to forecast.
• The service is stateful and critical - a primary database or core API - where interruption is unacceptable.
• You want a guaranteed discount with zero interruption risk rather than the lowest possible per-hour price.
• You are covering the baseline floor of your usage that runs around the clock regardless of traffic.
• You have enough usage history to commit confidently for one or three years without overcommitting.
• You value price predictability for budgeting more than the flexibility to release capacity anytime.

Can you use them together?

Yes, and combining them is the mature FinOps pattern, not a compromise. The split we recommend:

• Reserved Instances or Savings Plans for the baseline - the steady, always-on floor of your usage gets a guaranteed discount you can forecast and budget against.
• Spot for elastic and interruptible capacity - batch, CI, data processing, stateless bursts, and checkpointed training run on the cheapest pool, designed to survive reclaim events.
• A little on-demand as a buffer - for genuine spikes and for the moments Spot capacity is short, so nothing stalls.

On Kubernetes this becomes mixed node pools: a committed baseline pool for critical pods and a Spot pool for burst and interruptible work, with disruption handling so pods reschedule cleanly when Spot nodes go away. The same logic governs where commitments end and Spot begins, which is exactly the question a reserved instances vs savings plans decision answers for the committed half. For accelerator-heavy work, pair this with a deliberate AI/GPU cost governance policy so training runs on Spot and steady inference sits on commitments.

Cost comparison

The pricing models are fundamentally different, so compare on workload fit, not just headline discount.

• Spot Instances carry the deepest discount because you are buying spare capacity, but the price fluctuates and the capacity can be reclaimed. The real cost is engineering: you pay in resilience work to handle interruptions gracefully. Savings only land for workloads that can actually tolerate that.
• Reserved Instances offer a substantial, steady discount off on-demand in exchange for a one or three year commitment. The cost is flexibility and forecasting risk: commit to capacity you do not end up using and the discount works against you.

The lowest total bill almost always comes from layering them rather than choosing one. Commitments lock in savings on the predictable baseline, Spot squeezes the most out of elastic and interruptible work, and on-demand fills the gaps. We avoid quoting specific discount percentages here because they vary by cloud, region, instance family, and commitment term - the durable truth is that Spot can be dramatically cheaper for interruptible work and commitments offer a reliable discount on steady usage.

Common pitfalls

• Putting critical stateful workloads on Spot - a lone primary database or single stateful instance on Spot will go down on a reclaim event. Without replication and graceful failover, that two-minute warning is not enough.
• Overcommitting on Reserved Instances - locking in one or three years of capacity you do not actually use turns a discount into waste. Right-size the commitment to your true baseline, not your peak.
• Ignoring the Spot termination notice - if your workload does not drain on the warning, you lose in-flight work and corrupt state. Build the handler before you rely on Spot.
• Concentrating Spot on one instance type - depending on a single instance type or zone means a capacity crunch can wipe out all your Spot nodes at once. Diversify to stay resilient.
• Treating it as one big either-or decision - Spot and commitments are layers, not rivals. Forcing everything onto one model leaves savings on the table or stability at risk.

Related reading

• Reserved Instances vs Savings Plans - how the two main commitment models compare for covering your steady baseline
• Kubecost vs CAST AI - Kubernetes cost visibility versus automated optimization, including Spot automation
• AI/GPU Cost Governance - Spot strategy for training and commitment planning for steady inference
• More comparisons and guides on the finops.qa blog

Getting help

We help engineering and FinOps teams find the right split between committed baseline, Spot, and on-demand, then wire up the interruption handling and commitment coverage to make it stick. A finops.qa Assessment audits your current mix against your actual workloads and leaves you with a concrete plan for which capacity belongs on Spot and which deserves a commitment.

Book a free scope call.