Spot instances fit stateless, fault tolerant, and restartable work: batch processing, continuous integration, big data, container workloads behind a scheduler, and machine learning training that checkpoints. They break for stateful single node systems, low latency user facing tiers without a fallback, and software licensed per instance, because a two minute reclaim notice is not enough to protect them. The discount, up to 90 percent off on demand, is real, but it is a reward for tolerating interruption, not a free rate, and the way you capture it safely is diversification across instance types and Availability Zones.
Here is the fit test, the failure modes, and the patterns that make Spot dependable.
How do Spot instances actually work?
Spot is AWS selling unused on demand capacity at a discount. The price moves with supply and demand but changes gradually, and you pay the current Spot rate. When AWS needs the capacity back, it sends a two minute interruption notice and then reclaims the instance. There is no penalty and no commitment, but there is no guarantee of availability either. That single fact, capacity can vanish in two minutes, defines every fit decision below.
Because the saving comes from tolerating interruption rather than from a commitment, Spot stacks cleanly with Savings Plans: cover your steady floor with commitments and run the interruptible top of demand on Spot.
Where do Spot instances fit?
Spot fits any workload that can lose a node without losing work. The pattern is statelessness plus a way to retry.
- Batch and data processing. Spark and EMR clusters, ETL, rendering, and scientific compute that split into retryable tasks. A reclaimed node just reschedules its task.
- Continuous integration and test. Build and test runners are short lived and idempotent, so an interruption costs a rerun, not data.
- Container fleets. EKS and ECS with capacity providers can drain a Spot node on the two minute notice and reschedule pods elsewhere.
- Machine learning training that checkpoints to durable storage, so an interrupted run resumes from the last checkpoint.
- Stateless web tiers with autoscaling and a healthy on demand base, where losing a few nodes only trims capacity.
Where do Spot instances break?
Spot breaks wherever a reclaim causes lost work, lost state, or a licence violation.
- Stateful single node systems. A primary database or a stateful queue on one Spot node can lose data or availability when reclaimed.
- Low latency user facing tiers without a fallback. If a reclaim drops capacity below what users need and nothing absorbs the gap, you get errors.
- Per instance licensed software, where moving or restarting an instance triggers a licensing cost or breach.
- Long uninterruptible jobs with no checkpoint, where losing the node means starting from zero, so the cheap compute becomes expensive rework.
- Thin capacity pools, where a single niche instance type in one Availability Zone has little spare capacity and gets reclaimed often.
How do you run Spot safely?
A media company ran a nightly transcoding fleet entirely on a single large instance type in one Availability Zone to chase the lowest Spot price. When that pool tightened, interruptions spiked and jobs missed their window, so the team nearly abandoned Spot. We rebuilt the fleet to draw from a dozen interchangeable instance types across three Availability Zones using the capacity optimized allocation strategy, with a small on demand base for guaranteed throughput. Interruptions became routine and invisible, the window held, and the transcoding bill fell by more than two thirds against the on demand baseline. Figures are verified against billing data and anonimised.
The safety pattern has four parts. Diversify across many instance types and Availability Zones so no single pool is a point of failure. Use the capacity optimized allocation strategy so AWS draws from the deepest pools, which interrupt least. Handle the two minute notice by draining work and checkpointing on the interruption signal. And blend a small on demand or Savings Plan base under the Spot layer so a wave of reclaims never takes you below the floor you need. Check the Spot placement score before you commit a design to a region.
What does Spot mean for your commitment strategy?
Spot and Savings Plans are complements, not competitors. Commitments buy a low rate on the usage you run every hour; Spot buys an even lower rate on the usage that can tolerate interruption. The mistake is treating one as a substitute for the other. Size your commitments to the steady floor as covered in sizing Savings Plan coverage without stranding spend, then layer Spot on the fault tolerant top. For the broader trade between guaranteed and elastic capacity, see Reserved Instances versus Savings Plans, and the full picture sits in the AWS cost optimization guide.
Frequently asked questions
Get the AWS Savings Plan and Spot kit
We map which workloads can safely move to Spot, design the diversification and fallback so interruptions stay invisible, and blend Spot with commitments for the lowest defensible compute bill. It is the same discipline behind the 31 percent median reduction we see in the first 90 days, with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.