Key takeaway: Spot pricing is not a discount on the same product — it is a different product with an availability guarantee the on-demand price is paying for. Using spot for a workload that assumed on-demand’s guarantees produces outages, not savings.
What the Discount Is Actually Buying
Cloud providers sell spare capacity at a steep discount in exchange for the right to reclaim it when that capacity is needed elsewhere, typically with a warning window measured in minutes rather than hours. The discount is proportional to how much certainty you are giving up, not a promotional price on identical infrastructure.
Treating a spot instance as a cheaper on-demand instance and running anything stateful and interruption-intolerant on it produces exactly the outcome the pricing model describes — an instance disappearing mid-task with a couple of minutes of notice, because that possibility is precisely what was priced in.
What Genuinely Fits Spot Pricing
| Workload characteristic | Fits spot | Reasoning |
|---|---|---|
| Stateless, horizontally scaled | Yes | Loss of one instance has minimal impact |
| Checkpointed batch or training jobs | Yes | Can resume from last checkpoint |
| Fault-tolerant queue consumers | Yes | Message returns to queue if worker vanishes |
| Stateful database primary | No | Interruption causes data loss or downtime |
| Low-latency user-facing API, no fallback | No | Interruption is a visible outage |
| CI runners | Yes | A failed job simply retries |
The checkpointing requirement deserves particular emphasis for training and batch workloads specifically, because the value of spot pricing for these jobs depends entirely on being able to resume from where the interruption occurred rather than restarting the entire job from the beginning. A long training run without checkpointing that gets interrupted at ninety percent completion has lost the savings and then some, in wasted compute time redone from scratch.
Handling the Interruption Correctly
Cloud providers issue an interruption notice with a short warning period before reclamation. Workloads need to actually listen for that notice and act on it — draining connections, checkpointing state, deregistering from a load balancer — rather than simply being killed abruptly when the instance disappears.
For container orchestration platforms, node-level interruption handling that cordons and drains the node gracefully when a termination notice arrives, giving running pods a chance to shut down cleanly and reschedule elsewhere, is what makes spot usage practical at the infrastructure layer rather than something each application has to handle independently.
Diversifying to Reduce Interruption Frequency
Spot availability and interruption likelihood vary by instance type and availability zone, sometimes significantly. Relying on a single instance type in a single zone concentrates interruption risk; spreading a workload across several compatible instance types and zones reduces the chance that a single capacity crunch reclaims the entire fleet simultaneously.
This diversification is a deliberate architectural decision — many workloads default to a single instance type for simplicity, and that simplicity directly increases correlated interruption risk under spot pricing.
Combining With On-Demand Sensibly
A common and effective pattern runs a baseline of on-demand or reserved capacity sufficient to handle steady minimum load, with spot instances absorbing burst and elastic scaling above that baseline. This captures spot’s cost benefit for the variable portion of demand while keeping the guaranteed portion on pricing that matches its actual availability requirement.
The Bottom Line
Reserve spot pricing for genuinely fault-tolerant, stateless or checkpointed workloads, and build real interruption handling — graceful draining, checkpoint-and-resume — rather than assuming the discount is free. Diversify across instance types and zones to reduce correlated interruption, and combine spot with a stable on-demand baseline for the portion of load that cannot tolerate any disruption.
