Spot Instances let you use spare EC2 capacity at a steep discount, up to around 90 percent off the on-demand rate, in exchange for one condition: AWS can reclaim the capacity when it needs it back, giving you a two-minute interruption notice. That single condition is the whole decision. For workloads that can absorb an interruption, Spot is the deepest discount AWS offers. For workloads that cannot, it is a path to outages. Knowing which is which is the skill.
This article links up to our complete guide to AWS cost optimization, the pillar for this cluster. Spot is part of the Cut step of our See, Cut, Lock, Run method, and it sits alongside the commitment choices we cover in Savings Plans vs Reserved Instances: Spot for interruptible capacity, Savings Plans for the steady core, on-demand for the rest.
Can this workload lose an instance with two minutes notice and recover automatically? If yes, Spot is almost always worth it. If no, it does not belong on Spot at any discount.
Which workloads belong on Spot
Spot suits work that is stateless, fault-tolerant, and either parallel or easy to retry. The clearest fits are batch and data processing jobs, CI and build farms, rendering and transcoding, big-data and analytics workers, and stateless web or application tiers behind a load balancer that can lose a node without dropping requests. Containerized workloads on EKS or ECS are particularly well suited, because the orchestrator already reschedules pods when a node disappears. The same logic powers the match-server capacity in our gaming on AWS and OCI scenario, where moving interruptible capacity to Spot was the largest single lever.
What does not belong on Spot: single-instance stateful databases, workloads with long, non-resumable jobs that lose hours of progress on interruption, licensing tied to specific hosts, and anything where a two-minute eviction during a peak would breach a service commitment. For these, stay on-demand or covered by a commitment.
The guardrails that make Spot safe
Spot is risky only when used naively. A handful of practices turn it into a dependable discount.
Diversify across instance types and Availability Zones. The single biggest cause of mass interruption is concentrating on one instance type in one zone. Configure your Auto Scaling group or EC2 Fleet to draw from many compatible instance types across all zones, so when one pool is reclaimed, capacity shifts to another. The capacity-optimized allocation strategy picks pools least likely to be interrupted.
Blend Spot with an on-demand and Savings Plan base. Run a guaranteed floor of on-demand or committed capacity to cover the minimum you cannot lose, and let Spot carry the variable layer on top. EC2 Fleet and Auto Scaling support mixed-instances policies with explicit on-demand and Spot percentages for exactly this.
Handle the two-minute notice. Subscribe to the Spot interruption notice and the rebalance recommendation, drain connections, checkpoint progress, and let the orchestrator reschedule. For Kubernetes, tools like the AWS Node Termination Handler automate the graceful drain.
Make jobs idempotent and resumable. Design batch work to checkpoint and resume rather than restart from zero, so an interruption costs minutes, not hours.
Want Spot adoption modeled for you?
Our AWS cost audit identifies which of your workloads can safely move to Spot, models the blended Spot, on-demand and Savings Plan mix, and quantifies the saving before you change anything. On the performance model, you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →How much can you actually save
The headline is up to roughly 90 percent off on-demand, but the realized number depends on the instance pools you can draw from and how diversified you are. A well-diversified fleet on common instance families typically lands a large, stable discount; a narrow fleet chasing one scarce instance type sees both a smaller discount and more interruptions. Spot prices now move gradually based on supply and demand rather than bidding, so the rate you see is the rate you pay, which makes budgeting far easier than the old auction model.
Crucially, Spot stacks with the rest of your program. Move interruptible work to Spot, rightsize what remains as in our EC2 rightsizing walkthrough, then cover the steady core with Savings Plans. Each lever applies to a different slice of the bill, so they compound rather than overlap.
| Workload | Spot fit | Recommended placement |
|---|---|---|
| Batch, CI, rendering | Excellent | Mostly Spot, diversified |
| Stateless web tier | Good | Spot on top of an on-demand floor |
| Container workers (EKS/ECS) | Good | Spot node groups with graceful drain |
| Single stateful database | Poor | On-demand or reserved |
| Long non-resumable jobs | Poor | On-demand |
Spot mechanics, discount ranges and tooling above reflect AWS offerings as of May 2026. Verify current behavior in the EC2 console and Spot documentation before adopting, as features change.
The AWS Cost Optimization Field Guide includes the workload checklist and the blended-fleet model we use to decide what moves to Spot. It is the downloadable companion to this guide.
The short version
Spot is the deepest discount AWS offers, and it is worth the risk for any workload that can lose an instance with two minutes notice and recover automatically. Diversify across types and zones, blend Spot with an on-demand and committed floor, handle the interruption notice gracefully, and keep jobs resumable. Leave stateful and non-resumable work on-demand. When you want Spot adoption planned and de-risked across your estate, that is what our AWS cost optimization service delivers.