Spot instance cost strategy: big discounts for interruptible work

Quick answer

Spot instances are spare cloud capacity offered at up to ~90% off on-demand, in exchange for the provider reclaiming them with little notice (typically a two-minute warning). They suit fault-tolerant, stateless, checkpointed, or interruptible work, batch jobs, CI, HPC, stateless workers, dev, and some containerized services. The strategy: diversify across instance types and zones (so not all capacity vanishes at once), handle the interruption signal gracefully, and keep critical stateful work on on-demand or reserved capacity.

Spot instances are the biggest single discount in cloud compute, spare capacity at up to about 90% off on-demand, and the reason more workloads do not use them is the catch: the provider can reclaim them with little notice. With the right workloads and a bit of engineering, that tradeoff is very often worth taking.

The tradeoff

	On-demand	Spot
Price	Full rate	Up to ~90% off
Availability	Guaranteed	Reclaimable (short notice)
Best for	Stateful, latency-critical, always-on	Fault-tolerant, interruptible, batch

Spot's discount is huge, but the instance can be interrupted with typically a two-minute warning when the provider needs the capacity back. So the workload must tolerate a node vanishing: it must be fault-tolerant, stateless, checkpointed, or able to resume elsewhere. For such workloads, Spot is nearly free money.

What suits Spot

Batch and HPC jobs, CI/CD runners, data processing, stateless web and API workers behind a load balancer, dev and test environments, and ML training with checkpointing are all strong Spot candidates. What does not suit Spot: stateful databases, latency-critical services with no capacity buffer, and anything that cannot recover from an abrupt node loss, keep those on on-demand or reserved.

Making Spot safe

Diversify across many instance types and availability zones so a reclaim in one pool does not take all your capacity (the single most important practice), handle the interruption notice by draining work and checkpointing in the two-minute window, use Spot within managed groups (EC2 Auto Scaling with mixed instances, Spot-backed node pools in Kubernetes) that replace reclaimed nodes automatically, and blend Spot with a baseline of on-demand or reserved for capacity you must not lose.

A blended strategy

The mature pattern is a blend: a baseline of reserved or committed capacity for steady must-run load, on-demand for the stateful and latency-critical tier, and Spot for the elastic, fault-tolerant remainder, often the majority of compute. This captures Spot's discount on the workloads that can take it while protecting what cannot, and it can cut a large compute bill substantially with modest engineering. Diversify, handle interruptions, and put fault-tolerant work on Spot.

FAQ

What are Spot instances and how much do they save?

Spare cloud capacity offered at up to about 90% off on-demand, in exchange for the provider reclaiming them with little notice (typically a two-minute warning). They suit fault-tolerant, stateless, checkpointed, or interruptible work, cutting compute cost dramatically for workloads that can tolerate a node vanishing.

What workloads suit Spot instances?

Batch and HPC jobs, CI/CD runners, data processing, stateless web and API workers behind a load balancer, dev and test environments, and ML training with checkpointing. What does not suit Spot: stateful databases, latency-critical services with no capacity buffer, and anything that cannot recover from abrupt node loss, keep those on on-demand or reserved.

How do I make Spot instances safe to use?

Diversify across many instance types and availability zones so a reclaim in one pool does not take all your capacity (the most important practice), handle the interruption notice by draining and checkpointing in the two-minute window, use Spot within managed groups that replace reclaimed nodes automatically, and blend Spot with a baseline of on-demand or reserved capacity.

What is a blended Spot strategy?

A mix of a reserved or committed baseline for steady must-run load, on-demand for the stateful and latency-critical tier, and Spot for the elastic, fault-tolerant remainder (often the majority of compute). This captures Spot's discount where it is safe while protecting workloads that cannot tolerate interruption, cutting a large compute bill substantially.

How much notice do you get before a Spot interruption?

Typically a two-minute warning when the provider needs the capacity back. Your workload should use that window to drain in-progress work, checkpoint state, and deregister from load balancers so it can resume elsewhere. Handling this interruption signal gracefully is what makes Spot safe for fault-tolerant workloads.

Does C3X estimate Spot savings?

C3X prices your compute from Terraform at on-demand rates as a baseline; Spot pricing varies continuously with the market, so actual Spot cost depends on real-time capacity. C3X helps you see the on-demand cost you would be discounting, and you model the Spot proportion and expected discount for your fault-tolerant workloads.

What to do next

See the on-demand compute cost you could be discounting with Spot. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.