Spot instances are the largest single discount AWS offers on compute — up to about 90% off On-Demand — and they are also the most misunderstood, because the marketing leads with the number and buries the contract. The contract is simple once you say it plainly: you are renting EC2's spare capacity, and AWS can take it back with two minutes' notice whenever a paying On-Demand or Reserved customer wants it. Everything about using Spot well follows from taking that sentence literally.
What the market actually is
A Spot instance runs on the same hardware, network, and AMIs as On-Demand. The only difference is the capacity's tenure. AWS provisions data centers for peak demand, which means most of the time a large fraction sits idle. Spot is that idle capacity, sold cheap on the understanding that it evaporates the moment real demand shows up.
The pre-2017 auction model is gone. You no longer bid against other users, and prices no longer spike wildly second to second. Spot prices now move smoothly based on longer-term supply and demand trends for each pool. You can still set a maximum price, but the default cap is the On-Demand rate, and setting a lower cap only means you get interrupted sooner when the price rises to meet it. For nearly everyone, leaving the max at On-Demand is correct — you are not trying to win an auction, you are trying to survive interruptions.
Capacity pools are the unit that matters
The concept that makes Spot predictable is the capacity pool: a single instance type in a single Availability Zone. c7g.2xlarge in us-east-1a is one pool; c7g.2xlarge in us-east-1b is a different pool; m6i.2xlarge in us-east-1a is another. Interruptions do not happen to "Spot" in the abstract — they happen to a pool, when EC2 needs that specific type-and-zone capacity back for On-Demand demand.
This is the single most important fact for cost engineering with Spot, because it means your interruption risk is a function of how many pools you spread across, not of luck. Concentrate a fleet in one pool and one demand surge in that zone takes the whole fleet at once. Spread the same fleet across fifteen pools and a surge in one costs you a fraction of your nodes, which your scheduler can replace from the other fourteen.
The signals: rebalance recommendation, then the two-minute notice
Spot gives you two escalating warnings, and using both is the difference between graceful and abrupt.
The rebalance recommendation is the early one. AWS emits an EC2 Instance Rebalance Recommendation when an instance's pool is at elevated risk of interruption — often well before any hard notice, sometimes many minutes ahead. It is a heads-up: start draining, stop scheduling new work here, begin standing up a replacement. It is advisory and can occasionally fire without an interruption following, so treat it as "prefer to move" rather than "must move."
The interruption notice is the hard one. Two minutes before reclaiming the instance, EC2 delivers the warning two ways:
- Via instance metadata at
http://169.254.169.254/latest/meta-data/spot/instance-action, which returns the action (terminate,stop, orhibernate) and a timestamp. A small agent polling this endpoint every few seconds is the classic pattern. - Via EventBridge, as an
EC2 Spot Instance Interruption Warningevent you can route to Lambda, SQS, or an orchestrator. This is what Karpenter, Spot-aware ASGs, and Batch consume to cordon and drain automatically.
Two minutes is enough to finish an in-flight request, flush a checkpoint, and deregister from a load balancer. It is not enough to complete a 40-minute non-restartable job. Design to that budget.
Diversification is the actual risk control
Because risk lives at the pool level, the lever that lowers your interruption rate is pool count. AWS gives you allocation strategies to do this for you across EC2 Fleet, Spot Fleet, and ASG mixed-instances policies:
price-capacity-optimized— the current default recommendation. It weighs both how cheap a pool is and how deep its available capacity is, favoring pools less likely to interrupt. In practice this cuts interruption rates meaningfully versus chasing the absolute lowest price.capacity-optimized— pure "launch where there's the most spare capacity," lowest interruption rate, slightly less aggressive on price.lowest-price— cheapest pools only; concentrates you into the pools most likely to be reclaimed. Avoid it for anything but the most trivially interruptible work.
The practical recipe: define your workload by requirements (say, ≥8 vCPU, ≥16 GiB, arm64-or-amd64) rather than by a named instance type, list a dozen-plus compatible types, and spread across every AZ in the region. Use the Spot placement score API when planning capacity to find which region/pool combinations can actually supply what you need. The Spot Instance Advisor publishes each pool's historical frequency of interruption in bands (under 5%, 5-10%, 10-15%, 15-20%, over 20%) alongside its savings — read it before you commit an architecture to a family.
Checkpointing is what makes long work Spot-safe
For anything that runs longer than the two-minute budget, Spot only works if losing an instance costs you a bounded, small amount of progress. That means checkpointing: periodically persist enough state to durable storage (S3, EFS, a database) that a replacement can resume from the last checkpoint rather than from zero. Model training frameworks, video transcode pipelines, and large batch jobs all support this; the engineering is in choosing a checkpoint interval that balances I/O overhead against how much recomputation an interruption costs. A rebalance recommendation is a good trigger to force an out-of-band checkpoint before you lose the node.
What should never touch Spot
Spot is wrong for any workload where an unplanned two-minute eviction violates a real constraint:
- Stateful singletons with no replication — a primary database, a single stateful cache holding the only copy of hot data, a license server. Losing it is an outage, not a reschedule.
- Quorum-sensitive clusters run carelessly. A Raft or etcd cluster can use Spot only if members are spread across pools so a single-pool interruption never takes quorum. Pack them into one pool and Spot will eventually kill your consensus.
- Software licensed per launch or per instance-start, where each interruption-and-relaunch either costs money or trips activation limits.
- Jobs that cannot checkpoint and run past two minutes with a hard deadline — a nightly close that must finish by a regulatory cutoff and cannot resume.
- Anything whose restart cost exceeds the savings. If recovering from an interruption takes an engineer's pager and an hour, the 70% you saved on the instance is not real.
The honest framing is that Spot is not "cheap compute." It is interruptible compute priced at a discount that matches the interruptibility, and the discount is only real if your architecture already treats individual instances as disposable. For stateless web tiers behind a load balancer, CI runners, batch and rendering, big-data workers, and Kubernetes nodes with proper draining, that is already true and Spot is close to free money. For the crown-jewel stateful pieces, the discount is a trap. Sort your workloads by that line first, and the 90% takes care of itself.