A batch job needs ten hours of compute. An on-demand instance costs $1 per hour; a Spot instance costs $0.30. At first glance the job costs $10 or $3. But if the Spot worker is interrupted after nine hours and must restart from the beginning, its bill is already $2.70 before it produces anything.

The discount applies to running capacity. The customer needs to pay attention to completed work, deadlines and what happens when capacity disappears.

What the lower price buys

AWS Spot Instances use spare EC2 capacity that can be reclaimed. Availability and pricing depend on capacity pools. A persistent request or sufficient account quota does not guarantee that a replacement machine can be obtained when the current one stops.

That makes Spot attractive for workloads that can move, resume or wait: batch processing, rendering, queued jobs and some training runs. A transaction service that must stay available cannot assume the same capacity arrangement is suitable. Stable baseline capacity and interruptible workers can be used together.

Interruption behavior differs across providers

AWS describes Spot interruption notices as best-effort warnings issued two minutes before stop or termination. Hibernation starts immediately when that behavior is selected and does not provide the same two-minute preparation window.

Google Cloud Spot VM documentation specifies no fixed minimum or maximum runtime unless a runtime limit is set. It also distinguishes the configured preemption notice duration from shutdown. At VM creation, the notice duration can be set to zero seconds (the default) or 120 seconds. The subsequent shutdown period is best effort and lasts up to 30 seconds. Do not assume every Google Spot VM receives a two-minute notice.

Azure Spot VMs have no availability SLA and can be evicted when capacity is needed or relevant price conditions are met. Eviction behavior may deallocate or delete the VM. Deallocated machines can retain billable disks; a later allocation attempt may fail if capacity is unavailable.

A warning is useful for draining or recording progress. It cannot replace durable checkpoints, because a machine can also stop for unrelated reasons and writing a large working state may take longer than the warning.

Calculate the cost of wasted work

Return to the ten-hour job. Suppose the first attempt stops at hour nine. The next runs to completion at the same Spot price. Without checkpoints, the job uses 19 hours and costs $5.70 instead of $3.

Now suppose the worker records a durable checkpoint every hour. If it is interrupted just before the ninth-hour checkpoint, it can restart from hour eight. Ignoring checkpoint and restore overhead, it repeats roughly one hour rather than nine. The total is about 11 hours of compute, costing $3.30.

If checkpointing adds ten minutes of compute and I/O work per hour of useful progress, the economics change again. Retained storage, transfer and restoration have costs. Choose the checkpoint interval using the cost of losing progress, the time required to save it and the observed interruption pattern.

The numbers are hypothetical. Actual interruptions can be correlated across capacity pools, rates can change and replacement capacity may not arrive quickly enough. A meaningful cost estimate includes those uncertainties rather than applying the maximum advertised discount to every job.

Retries need to be safe

A restarted worker may repeat more than calculations. It could send a notification again, create a duplicate record or bill an external account twice. Use durable job identifiers and idempotent operations where practical so retrying the same unit of work does not create a second business action.

For a dataset processed by multiple workers, store a record of completed units and publish the final output only when the required set is complete. A worker's local progress file is not enough if the instance is deleted. The object storage and backup article discusses why retained bytes need a valid recovery path.

Allow for a capacity gap

An interruptible job might be economical even with several retries if its deadline is flexible. A job due in two hours may need to switch to on-demand capacity rather than wait for another Spot instance. Factor that fallback into the budget.

The useful measure is cost per accepted completed job, including retries, storage and any fallback capacity. Spot can be an excellent way to use spare infrastructure. It becomes a false economy when the workload cannot tolerate the availability uncertainty that comes with the price.