Why the spot discount is not the spot saving
Spot capacity is spare provider inventory sold at a deep discount on the condition that it can be taken back with about two minutes' notice. The discount is real and large. What the rate card cannot tell you is how much of the work you paid for survives, and that is what decides whether spot is cheaper for your particular job.
The mechanism is simple and unforgiving. If an interruption arrives partway through an unprotected job, everything computed since the start is discarded and the job begins again. You paid for those hours. So the effective price per completed job is the spot rate multiplied not by the job length but by the expected compute consumed, which is always larger and grows faster than linearly with job length.
Checkpointing changes the shape of the problem completely. If the job saves recoverable state every hour, an interruption costs at most an hour of repeated work regardless of how long the whole job runs. That converts an exponential relationship between job length and cost into a linear one, which is why long jobs on spot are a checkpointing question rather than a pricing question.
This calculator therefore prices three things together: the discounted rate, the compute repeated after interruptions, and the fixed cost of each restart. The last one matters more than people expect on short segments, because a job checkpointing every fifteen minutes restarts often, and each restart pays for image pulls and warm-up whether or not much compute was lost.
A memoryless hazard, and the expected-hours formula
Model interruptions as a Poisson process: the chance of reclamation in the next instant does not depend on how long you have already been running. If p is the probability of interruption within one hour, the equivalent hazard rate is λ = −ln(1 − p) per hour. At 10% an hour that is 0.105361, slightly above 0.10, because the hazard compounds continuously.
For one segment of length c that must complete without interruption, the probability of success is e^(−λc), so the expected number of attempts is e^(λc). Each failed attempt consumes only the time until it was interrupted, and the expected time consumed per attempt is (1 − e^(−λc))/λ. Multiplying attempts by time consumed — which is valid because the attempts are independent and the count is a stopping time — gives the compact result
E[hours per segment] = (e^(λc) − 1) / λ.
Check the limits. As λ approaches zero the expression approaches c, which is the no-interruption case. As λc grows the expression blows up exponentially, which is the long unprotected job that never finishes. Expected interruptions follow directly as k(e^(λc) − 1) for k segments.
The consequence worth internalising is that with a fixed checkpoint interval, job length stops mattering. Cost is k segments each costing the same, and k is proportional to job length, so cost per hour of work is constant. Without checkpointing, c equals the whole job and cost climbs exponentially with length. That is why this calculator reports a crossover job length only when the exponential regime can actually reach the on-demand line.
Worked example: a 24-hour job at 3% interruption an hour
A training job needs 24 hours of compute. On-demand is $0.384 an hour, spot is $0.115, the instance type shows roughly a 3% chance of reclamation per hour, restarting costs $0.50, and the job has no checkpointing.
- Hazard rate. λ = −ln(1 − 0.03) = −ln(0.97) = 0.0304592 per hour.
- Segment length. With no checkpointing the segment is the whole job: c = 24 h.
- Expected attempts. e^(0.0304592 × 24) = e^0.731021 = 2.0772. On average the job runs to completion on the second or third try.
- Expected compute. (2.0772 − 1) ÷ 0.0304592 = 1.0772 ÷ 0.0304592 = 35.37 hours billed for 24 hours of useful work.
- Expected interruptions. 2.0772 − 1 = 1.077.
- Spot cost. $0.115 × 35.37 + $0.50 × 1.077 = $4.067 + $0.539 = $4.61.
- On-demand cost. $0.384 × 24 = $9.22.
- Saving. $9.22 − $4.61 = $4.61, almost exactly half, against a headline discount of 70%.
Now add hourly checkpoints with a 5% overhead. The work becomes 25.2 hours in 25.2 segments of one hour; each segment costs (e^0.0304592 − 1) ÷ 0.0304592 = 1.015385 hours, so expected compute is 25.58 hours — down from 35.37 — with 0.78 expected interruptions. Spot cost falls to $0.115 × 25.58 + $0.50 × 0.78 = $2.94 + $0.39 = $3.33. Checkpointing bought back $1.27 on a single job, and it is the difference between a 50% and a 64% realised saving.
How to read the result
Look at expected compute against actual work first. A ratio near 1.0 means interruptions are a rounding error and you should be on spot. A ratio above roughly 1.5 means you are paying for a large amount of repeated work, and the fix is checkpointing rather than a different instance type. Above 2.0 the job may be effectively unable to finish during busy periods, whatever the arithmetic says about expectations.
Then read the crossover job length. If it is blank, spot remains cheaper at every length the model covers, which is the normal result once checkpointing is in place. If it is finite and close to your job length, the decision is fragile: interruption rates vary by zone, by instance type and by time of day, and a rate twice what you entered halves the crossover.
Treat the expected number of interruptions as an operational figure, not just a financial one. Each interruption is a scheduling event, a possible partial write, and a log entry someone will read. A pipeline expecting 0.1 interruptions per job needs no special handling; one expecting 3 needs idempotent steps, safe resumption and monitoring that does not page a human.
Finally, remember what spot does not fit. Anything with a hard deadline, anything holding unreplicated state, and anything that cannot tolerate a two-minute termination notice belongs on committed or on-demand capacity. The right portfolio is usually committed capacity for the steady floor, spot for the elastic and interruptible layer, and on-demand for the gap.
Expected compute per hour of work at different interruption rates
| Interruption rate per hour | c = 0.5 h | c = 1 h | c = 4 h | c = 12 h | c = 24 h |
|---|---|---|---|---|---|
| 0.5% | 1.0013 | 1.0025 | 1.0101 | 1.0307 | 1.0626 |
| 1% | 1.0025 | 1.0050 | 1.0204 | 1.0628 | 1.1309 |
| 3% | 1.0077 | 1.0154 | 1.0635 | 1.2072 | 1.4736 |
| 5% | 1.0129 | 1.0261 | 1.1100 | 1.3820 | 1.9697 |
| 10% | 1.0268 | 1.0546 | 1.2437 | 2.0095 | 4.5624 |
| 20% | 1.0579 | 1.1204 | 1.6149 | 5.0610 | 39.3540 |
Multiply your job's hours of work by the figure in the cell to get expected billed hours. The column for c = 24 h with no checkpointing is where long unprotected jobs become unaffordable; the c = 1 h column shows how completely checkpointing removes the problem.
Where the interruption rate comes from
Do not guess this input. AWS publishes a Spot placement score and an interruption-frequency view by instance type and region; Google publishes preemption behaviour for Spot VMs, which are always reclaimed within 24 hours; Azure publishes eviction rates for Spot Virtual Machines. All three vary by capacity pool, so the same instance family can be quiet in one zone and turbulent in the next. Convert whatever your provider publishes into a per-hour probability before entering it — a rate quoted per month is not the same number, and using it directly understates the hourly hazard by a large factor.
Assumptions this model makes
- Interruptions are memoryless. Real reclamation clusters when a capacity pool tightens, so a bad hour is more likely to be followed by another bad hour than this model assumes. Treat the result as a floor on expected cost.
- The spot price is constant. Spot rates float and are capped at on-demand. If your workload runs for weeks, sample the rate over a period rather than taking today's.
- Capacity is available when you retry. During a genuine shortage the retry does not start immediately, and the delay is a schedule cost this model does not price.
- Checkpoint overhead is a flat percentage. In practice it depends on state size and storage throughput, and writing a checkpoint to remote storage also costs requests and transfer.
- One instance is modelled. A distributed job across many spot instances is interrupted far more often than a single one, because any node being reclaimed can stall the whole job.
- No fallback is priced. Most production users run spot with an on-demand fallback, which raises cost and removes the tail risk of a job never finishing.
Making spot work in practice
The single highest-value change is checkpointing, and the table above shows why: at a 10% hourly interruption rate, hourly checkpoints cut expected compute for a 24-hour job from 4.56 times the work to 1.05 times. Nothing about the price negotiation comes close to that. Choose the interval by balancing lost work against restart cost and overhead — the calculator's own table sweeps it for your inputs.
Diversification is the second lever. Spreading a job across several instance types and availability zones draws on independent capacity pools, and provider schedulers will place into the deepest pool available. Fleet-style APIs exist precisely for this and typically reduce effective interruption rates well below any single pool's figure.
Third, match the workload to the mechanism. Batch analytics, CI runners, media transcoding, rendering and model training with checkpointing are all natural fits. Stateful databases, single-instance queues and anything user-facing are not. For the workloads that do not fit, the alternative is a commitment on the steady floor, and where the runtime itself is negotiable the serverless comparison is worth running before either. Whatever mix you land on, divide the result through the unit cost calculator so the saving is visible in a number the business tracks.