Every major cloud runs with spare capacity: servers that are powered on, paid for, and sitting idle between demand peaks. Rather than waste them, providers sell that capacity at a steep discount under names like spot instances on AWS, Spot VMs on Azure, and preemptible VMs on Google Cloud. The discount is dramatic — typically sixty to ninety percent off on-demand prices — and the catch is equally simple: the provider can take the capacity back with short notice, usually around two minutes, when someone willing to pay full price needs it. For workloads that can handle that interruption, spot is the cheapest compute in the cloud by a wide margin.

How Spot Pricing Actually Works

On AWS, spot prices move with supply and demand for each instance type in each availability zone, but in practice they sit far below on-demand most of the time. You request capacity with a maximum price you are willing to pay, and the instance runs until the market price rises above it or the provider needs the capacity back. Google's preemptible VMs work differently: a fixed, heavily discounted price, but a maximum lifetime of twenty-four hours. Azure Spot VMs sit somewhere between the two models. The details differ, but the principle is identical — you trade a guarantee for a discount.

That trade is what trips people up. Spot is not a cheaper version of on-demand; it is a different product with different guarantees, and using it like on-demand is how teams get burned. The workloads that thrive on spot are the ones designed for interruption from the start: batch jobs, CI runners, rendering, data processing, and stateless web services running behind a load balancer with several replicas. The workloads that suffer are the ones that assume a server will stay up: databases, single-instance applications, and anything holding state in memory.

Designing Workloads That Survive Interruption

The first rule is to spread across instance types and availability zones. A fleet that only uses one instance type in one zone can lose everything at once when that capacity is reclaimed; a fleet spread across several types and zones degrades gracefully instead. Tools like Karpenter on EKS automate this, choosing the cheapest suitable capacity across many types and replacing interrupted nodes automatically. The second rule is to handle the interruption signal: cloud providers send a warning a couple of minutes before reclaiming an instance, and your application should use that window to drain connections, finish the current task, and shut down cleanly.

The third rule is to keep state out of the instance. Store uploads in object storage, sessions in a managed cache or database, and job progress in a queue, so that losing a node loses nothing but compute time. Stateful services — databases, message brokers, file servers — stay on on-demand or reserved capacity, where the guarantee is worth the price. A common architecture puts the web tier and workers on spot and the data tier on on-demand, which typically cuts total compute spend by forty to fifty-five percent while keeping the parts that must not fail on solid ground.

When Spot Does Not Make Sense

Spot is a poor fit for small, steady workloads that never scale. A single small server running a blog or an internal tool costs little on demand, and the engineering time to make it interruption-proof exceeds the saving. It is also a poor fit for latency-sensitive workloads where a reclaimed instance means dropped requests, and for regulated workloads where the provider's ability to terminate a node conflicts with compliance requirements. And if your team has no one comfortable operating the automation that keeps a spot fleet healthy, the operational risk outweighs the discount — start with non-production workloads, learn the failure modes there, and only then move production traffic.

One more consideration: spot prices are not guaranteed to stay low. In a busy region or for a popular instance type, prices can spike, and a workload that only works at spot prices can become expensive at the worst moment. Set a maximum price, monitor the actual spend, and keep a fallback: an autoscaler that falls back to on-demand when spot is unavailable. Done that way, spot becomes a reliable discount rather than a gamble, and the savings — often hundreds of dollars a month for a small team — fund the next thing you actually want to build.

Frequently Asked Questions

Q: How much can spot instances really save?

A: Discounts of sixty to ninety percent off on-demand are typical, and teams usually see forty to fifty-five percent off total compute once stateful services stay on on-demand.

Q: What happens when a spot instance is reclaimed?

A: You get about two minutes of warning. Well-designed workloads drain gracefully and restart elsewhere; poorly designed ones lose in-flight work.

Q: Can I run a production website on spot instances?

A: Yes, if it is stateless, runs multiple replicas across zones, and keeps sessions and uploads outside the instance. Many production sites run this way.