Definition
A spot instance is spare compute capacity that a cloud provider sells at a steep discount compared to its regular on-demand price, with one important catch: the provider can reclaim that capacity with only a short warning whenever it needs the machine back for a customer paying full price. You get real compute power at a fraction of the usual cost, in exchange for accepting that it might disappear on short notice. That tradeoff is the entire premise of spot pricing, and understanding it clearly is the first step to using spot instances well.
Spot instances exist because cloud providers build out enormous amounts of physical capacity to handle peak demand, and a meaningful chunk of that capacity sits unused at any given moment when demand is below peak. Rather than let that capacity go entirely to waste, providers sell access to it at a discount, recovering some revenue from hardware that would otherwise generate nothing, while giving cost-conscious customers a way to run workloads much more cheaply than the standard price. This dynamic is why spot pricing exists across essentially every major cloud provider rather than being a quirk of just one of them.
What separates a genuinely useful spot instance strategy from a risky one is designing workloads to expect and tolerate interruption from the start, rather than treating a spot instance as a cheaper substitute for a reliable machine and being surprised when it goes away mid-task. Software built to checkpoint progress, retry on a different instance, or simply not care if any one instance disappears midway through is what actually captures the savings safely. Software that assumes the instance will always be there is setting itself up for a bad surprise eventually.
By 2026, spot instances are a well-established, mainstream part of cloud cost optimization, used widely for batch processing, big data jobs, machine learning training, and increasingly for stateless application workloads behind a load balancer that can absorb an individual instance disappearing without anyone noticing. Cloud providers have also gotten better at giving advance warning before reclaiming a spot instance and at offering tools that automatically diversify across instance types to reduce the odds of losing a lot of capacity all at once. These improvements have made spot capacity a much less intimidating option for teams that might have avoided it a few years earlier.
This page covers how spot instance pricing and reclamation actually work, how spot instances compare to on-demand pricing, what separates them from reserved instances as a cost strategy, and where the discount is worth the interruption risk versus where it clearly is not. The idea worth keeping is that a spot instance is a real trade: meaningfully lower price in exchange for real, unpredictable interruption risk, and that trade only makes sense for workloads specifically designed to handle losing an instance without losing real work. Getting that fit right is mostly a matter of being honest about what a given workload can actually tolerate losing.
Key Takeaways
- A spot instance is spare cloud compute capacity sold at a steep discount, with the tradeoff that the provider can reclaim it on short notice.
- It exists because cloud providers have unused capacity at any given moment and would rather sell it cheaply than let it sit idle.
- Spot instances only pay off for workloads specifically designed to tolerate interruption, not as a cheaper drop-in for reliable machines.
- By 2026, spot instances are mainstream for batch jobs, machine learning training, and stateless applications that can absorb losing an instance.
- The core trade is a real, meaningful discount in exchange for real, unpredictable interruption risk, and it only makes sense when the workload is designed for that.
How Spot Instances Work
Cloud providers price spot instances based on the current supply and demand for spare capacity of a given instance type in a given region, which means the price fluctuates over time rather than staying fixed the way on-demand pricing generally does. Some providers have moved toward steadier spot pricing models over the years, but the underlying mechanism, price reflecting available spare capacity, remains the basic idea across providers. Watching how a given instance type's spot price has behaved historically can give a rough sense of how volatile or stable it tends to be.
When you request a spot instance, you generally get it at whatever the current spot price is, provided capacity is actually available for that instance type in that region at that moment. If demand for that instance type spikes and the provider needs the capacity back for on-demand or reserved customers, it can reclaim your spot instance, usually giving some advance warning, commonly around one to two minutes, though the exact amount varies by provider.
That warning period is your window to do something useful before the instance disappears, save application state to persistent storage, finish or checkpoint whatever work is in progress, or trigger a replacement instance to pick up where the old one left off. Workloads that ignore this warning and just get abruptly cut off tend to lose whatever work was in flight at that exact moment, which is precisely the risk you are accepting in exchange for the discount.
Many teams reduce the practical risk by spreading workloads across multiple instance types and availability zones simultaneously, since the odds of losing capacity across several different pools at once are much lower than the odds of losing it in any single pool. Cloud providers and third-party tools have built increasingly sophisticated automation around this diversification, picking from a wide pool of instance types to keep overall interruption risk manageable while still capturing most of the discount.
Spot Instances Compared to On-Demand Instances
On-demand instances are the standard, no-commitment way to rent cloud compute: you pay a fixed, published rate for as long as you use the instance, and the provider guarantees you keep it running until you choose to stop it. There is no interruption risk built into the arrangement itself, and the price, while higher than spot pricing, is predictable and easy to plan around. This predictability is precisely what makes on-demand pricing the safe default choice whenever a workload's tolerance for disruption is genuinely unclear.
Spot instances trade that guarantee away entirely for a discount that is often substantial, frequently a large fraction off the on-demand rate for the same instance type, though the exact discount varies by instance type, region, and current demand. You are effectively betting that either the interruption never happens during your workload's runtime, or that your workload is built to shrug it off without losing meaningful work when it does. Understanding your own workload's tolerance for that bet is more important than chasing the biggest headline discount available.
The right choice depends heavily on what the workload actually needs from its compute. A workload that absolutely must keep running without interruption, a database serving live customer traffic with no failover plan, is a poor fit for spot pricing regardless of the savings on offer, since the downside of an interruption at the wrong moment is simply too costly to accept for a discount on the compute bill. No discount is worth accepting when the realistic downside is a service outage affecting real customers.
A workload that can genuinely absorb an instance disappearing, a batch job that checkpoints regularly, a stateless web server behind a load balancer with several other instances covering for it, is exactly where spot pricing earns its reputation as one of the more effective and underused cost levers available in cloud infrastructure, precisely because the downside of an occasional interruption there is close to nothing. Recognizing which category a given workload falls into is really the whole decision, more than any specific percentage of savings on offer.
What Makes Spot Instances Different From Reserved Instances
Reserved instances trade a different kind of commitment for a different kind of discount: you commit to using a certain instance type for a fixed term, often one or three years, in exchange for a lower price than on-demand, and in return you get a guarantee that the instance keeps running with no interruption risk, the same reliability as on-demand, just cheaper because you committed ahead of time. That guaranteed reliability is exactly what a workload with no tolerance for interruption actually needs, regardless of how attractive spot pricing looks on paper.
Spot instances offer a steeper discount than reserved instances typically do, but the mechanism behind the savings is fundamentally different. Reserved pricing rewards commitment and predictability for the provider, letting them plan capacity around guaranteed future revenue. Spot pricing rewards flexibility and tolerance for interruption, letting the provider monetize capacity that would otherwise sit completely idle in the meantime. Neither mechanism is inherently better, they are simply built around different assumptions about what the customer can offer the provider in return.
This means the two are suited to genuinely different kinds of workloads and, often, genuinely different parts of the same system. A steady, predictable baseline load that runs continuously for years is a natural fit for reserved pricing, since you know you will need that capacity and can commit to it without much doubt. Bursty, interruption-tolerant, or short-lived workloads fit spot pricing better, since committing to a long term for something you might not even be running in three months makes little sense.
Plenty of well-run cloud cost strategies use both together deliberately: reserved instances covering the predictable baseline a team knows it needs, and spot instances covering the variable, bursty portion of demand on top of that baseline, with on-demand instances filling in wherever spot capacity is not comfortably available or reliable enough for that particular moment or workload. This layered approach lets a team capture meaningful savings across most of its infrastructure while still keeping a safety net in place for whatever spot capacity cannot reliably cover.
Where Spot Instances Fit and Where They Do Not
Spot instances fit well for batch processing and big data jobs that can checkpoint progress and resume on a different instance without losing meaningful work, since an interruption there just means the job takes a bit longer, not that it fails outright or corrupts anything important along the way. Rendering pipelines and scientific computing workloads follow a similar pattern, where the total completion time matters far more than any single instance's uptime.
They also fit well for stateless application workloads running behind a load balancer with enough total capacity that losing any single instance briefly does not meaningfully affect the service as a whole, since traffic simply shifts to the remaining instances while a replacement spins up to take the lost one's place. The redundancy already built into that kind of architecture is what makes the occasional lost instance a non-event rather than an incident.
They fit poorly for workloads that hold critical, unrecoverable state on the instance itself with no plan for losing it, a database with no replication, a long computation with no checkpointing that would have to restart entirely from scratch if interrupted, since the cost of an interruption there can easily outweigh any savings the discount provided in the first place. Teams tempted by the discount in these cases should weigh it honestly against what an actual data loss or restart from scratch would cost.
They also fit poorly for latency-sensitive, customer-facing workloads with no redundancy to absorb an interrupted instance gracefully, since even a brief gap while a replacement comes online can translate directly into a visible outage for real users, which is rarely worth the discount for a system that has not been specifically built to tolerate that kind of disruption. The math rarely favors the discount once the cost of a visible customer-facing failure is actually accounted for.
How to Use Spot Instances Well
Design for interruption from the start rather than retrofitting it later, building in checkpointing, statelessness, or graceful handoff as a core requirement of the workload's architecture, not as an afterthought bolted on once someone notices the first unexpected instance loss in production. A team that treats resilience as optional groundwork tends to discover the gap the hard way, during the very first real interruption in production. Building this in during initial design is far cheaper than retrofitting it after a painful outage forces the issue.
Diversify across multiple instance types and availability zones rather than betting everything on one specific instance type in one specific zone, since spreading the risk meaningfully lowers the odds of losing a large share of your capacity all at the same time, and most cloud providers offer tooling that makes this diversification straightforward to set up rather than something you have to build entirely by hand. Relying on manual diversification instead tends to drift out of date as instance availability shifts, quietly reintroducing the concentration risk it was meant to solve.
Act on the interruption warning automatically rather than relying on someone noticing it manually, since the warning window is short, often just a minute or two, and automated handling, saving state, draining connections, requesting a replacement, is the only realistic way to consistently use that window well every single time it happens. Building this automation once and testing it thoroughly is far more reliable than hoping an on-call engineer notices and reacts in time during a real interruption.
Combine spot with on-demand or reserved capacity as a fallback rather than depending on spot instances alone for anything that actually matters, so that if spot capacity becomes scarce or unusually expensive for your instance type at a given moment, the workload can fall back to a more expensive but reliable alternative instead of simply failing to get the capacity it needs. That fallback path should be tested occasionally too, since an untested failover is not meaningfully different from having no failover at all.
Monitor interruption rates and actual realized savings over time rather than assuming the discount you saw when you first set things up holds steady forever, since spot pricing and availability shift with market demand, and a workload that made great financial sense on spot a year ago might be worth reevaluating today if conditions in that particular instance type or region have genuinely changed. A quick quarterly review of interruption logs and cost reports is usually enough to catch a strategy that has quietly stopped paying off.
Best Practices
- Build workloads to expect interruption from the start, with checkpointing or statelessness as a core design requirement, not an afterthought.
- Diversify across multiple instance types and availability zones to avoid losing a large share of capacity all at once.
- Automate the response to interruption warnings, since the short notice window rarely leaves time for a person to react manually.
- Keep on-demand or reserved capacity as a fallback rather than relying on spot instances alone for anything that truly matters.
- Monitor interruption rates and actual savings over time, since spot pricing and availability shift with market demand.
Common Misconceptions
- A spot instance is not simply a cheaper on-demand instance; it comes with real, unpredictable interruption risk that on-demand does not have.
- Spot instances are not only for huge companies with massive infrastructure; any workload tolerant of interruption can use them at any scale.
- Losing a spot instance is not a rare edge case to ignore; interruption is a normal, expected part of using spot capacity.
- Spot instances are not a good fit for workloads holding critical, unrecoverable state with no redundancy plan.
- The spot discount is not fixed or guaranteed forever; pricing and availability shift with real-time supply and demand.
