A spot instance is a virtual machine that runs on a cloud provider’s spare capacity at a large discount compared with on-demand pricing, with the condition that the provider can interrupt or reclaim it at short notice when it needs the capacity for other customers. Discounts commonly reach 60 to 90 percent, depending on instance type, region and current demand.
In cloud economics, spot capacity is the cheapest way to buy general-purpose compute, but the price is paid in availability guarantees rather than money. The concept exists across major providers under names such as Spot Instances in AWS, Spot Virtual Machines in Azure and Spot VMs in Google Cloud, which replaced the earlier preemptible VMs. Using it well is an architecture decision as much as a purchasing one.
How spot capacity and interruptions work
Cloud providers build data centers for peak demand, so at most times a share of servers sits idle. Spot pricing sells that idle capacity. When on-demand or reserved customers need it, the provider reclaims spot instances, sending an interruption notice first. The instance is then stopped, hibernated or terminated, according to the configured behavior.
Prices today change gradually with long-term supply and demand rather than through the sharp per-second bidding auctions of early spot markets. Customers may set a maximum price, but in most cases the interruption is driven by capacity needs, not by price. The table below compares the main interruption parameters.
| Provider | Advance notice | Interruption actions |
|---|---|---|
| AWS | Two minutes, plus optional rebalance recommendation | Terminate, stop or hibernate |
| Azure | About 30 seconds through scheduled events | Deallocate or delete |
| Google Cloud | About 30 seconds through a shutdown signal | Stop or delete |
Interruption frequency differs widely between instance types, sizes, zones and times. Some combinations run for weeks without interruption, while popular types in busy regions may be reclaimed several times a day. Providers publish historical interruption indicators that help estimate the risk, but no rate is guaranteed.
Spot instances compared with other purchasing models
Spot is one of several ways to buy the same compute. The right mix depends on how predictable and how interruptible each workload is.
| Model | Typical discount | Commitment | Interruption risk |
|---|---|---|---|
| On-demand | None | None | None |
| Reserved instance | Roughly 30 to 70 percent | One or three years | None |
| Savings plan or committed use | Similar to reservations | Spend commitment over one or three years | None |
| Spot instance | Roughly 60 to 90 percent | None | Can be reclaimed at short notice |
Mature FinOps practice combines them: commitments cover the steady baseline, on-demand covers short-term peaks that must not fail, and spot covers flexible, fault-tolerant capacity. Autoscaling groups and node pools can mix the models automatically within one fleet.
Workloads suited to spot instances
A workload suits spot capacity when it is stateless or checkpointed, horizontally scalable and tolerant of delay. If losing one machine means only redoing a few minutes of work, the discount usually outweighs the cost of interruptions.
| Workload | Suitability | Reason |
|---|---|---|
| Batch and data processing | High | Tasks can be retried or resumed from checkpoints |
| CI builds and tests | High | Jobs are short and easy to rerun |
| Stateless web tier behind a load balancer | Medium to high | Works with diverse pools and on-demand fallback |
| Kubernetes worker nodes | Medium to high | Pods are rescheduled to other nodes |
| Machine learning training | Medium | Requires frequent checkpoints; GPU capacity is scarce |
| Primary databases | Low | Interruption risks data loss and long recovery |
| Single-instance legacy servers | Low | No redundancy to absorb the loss |
Designing for interruptions
The central principle is diversification. Requesting many instance types and sizes across several availability zones gives the provider more pools to draw from, which reduces both the chance of interruption and the chance that replacement capacity is unavailable. Allocation strategies that favor capacity-optimized pools usually beat strategies that chase the lowest price.
- Handle the interruption notice: drain connections, finish or checkpoint work and deregister from load balancers.
- Store state outside the instance, in queues, object storage or managed databases.
- Keep an on-demand baseline for capacity that must always exist.
- Use orchestration features that replace reclaimed instances automatically and rebalance proactively.
- Test interruption handling regularly, for example with fault injection that simulates reclamation.
Risks and common mistakes
The typical failure is not a single interruption but a correlated loss: many instances of the same type in one zone reclaimed together, with no replacement capacity. Fleets that rely on one instance type are especially exposed. Another mistake is counting the discount without counting wasted work, such as long jobs without checkpoints that restart from zero after each interruption.
Spot savings also need honest cost allocation. When a platform team blends spot and on-demand prices, product teams may not see that their savings depend on interruption tolerance, and later design changes can quietly remove that tolerance.
Finally, spot capacity for specialized hardware, such as large GPU instances, is often scarce and reclaimed more frequently than general-purpose types. Plans that assume spot GPUs will always be available can stall training schedules, so teams should define a fallback to on-demand or reserved capacity and the maximum delay they are willing to accept before using it.
The simple explanation
Think of standby airline tickets. An airline sells empty seats very cheaply at the last minute, but if a full-fare passenger arrives, the standby traveler may have to give up the seat. For someone with a flexible schedule, the savings are worth it.
Spot instances are standby seats on cloud servers. They cost far less, but the provider can take them back with little warning. They suit work that can pause and continue later without harm.
How it is used in practice
A genomics laboratory processes sequencing data every night. Each sample is split into thousands of short tasks that read from and write to object storage. The team runs the pipeline on a compute fleet that requests twelve different instance types across three zones, all on spot capacity, with a small on-demand pool for the job scheduler.
On a typical night, a few percent of tasks are interrupted and automatically retried on other instances. Each run finishes within the same time window as before, while compute spending falls to roughly a third of the earlier on-demand cost. The team tracks interruption rates weekly and removes instance types that are reclaimed most often.