Spot capacity, called Spot on AWS, Spot Virtual Machines on Azure, Spot or preemptible on GCP, and preemptible instances on OCI, is spare provider capacity sold at a deep discount, roughly 60 to 90 percent below on demand, in exchange for the provider's right to reclaim it on short notice. In Kubernetes that interruption is manageable, because the cluster is already designed to reschedule pods when a node disappears. The way to run spot safely is to treat interruption as the normal case rather than an emergency: put spot in its own labelled node pools, schedule only interruption tolerant workloads onto them with taints and tolerations, spread replicas across zones and instance types so no single capacity event takes a service down, and keep a baseline of on demand nodes for the workloads that cannot move. Do that and the discount is real with no loss of reliability.
This is what spot is and the catch, which workloads belong on it, and the design that makes it safe.
What is spot and what is the catch?
Spot capacity is the provider's unused capacity offered at a steep discount. The catch is reclamation: when the provider needs the capacity back, it takes it, usually with a short warning measured in a couple of minutes. Prices and availability also vary by instance type, region, and time. None of this is a problem for workloads that can be interrupted and rescheduled, which is exactly the kind of workload Kubernetes already runs well. The mistake is to treat spot as cheap on demand and run things on it that cannot survive eviction. Treated as what it is, interruptible capacity, spot is one of the largest single levers on Kubernetes node cost.
Which workloads belong on spot?
The test is simple: can the workload survive a node being reclaimed on short notice without harming users or losing work. Stateless web and api services with multiple replicas pass, because a reclaimed replica is rescheduled while the others serve traffic. Batch jobs, CI runners, and data processing pass, because a job can be retried. Development and test environments pass easily. The workloads that do not pass are single replica stateful services, primary databases, anything with long uninterruptible processing, and critical path components with no graceful failover. The aim is not to put everything on spot. It is to move the large interruption tolerant share and keep a dependable on demand base.
| Workload | Spot fit | Why |
|---|---|---|
| Stateless web and api with replicas | Strong | Surviving replicas serve while a reclaimed pod reschedules |
| Batch, CI, data processing | Strong | Work is retryable; interruption costs a restart, not data |
| Dev and test environments | Strong | Low criticality, high tolerance for interruption |
| Primary databases, stateful singletons | Avoid | Eviction risks data and availability with no easy failover |
| Long uninterruptible jobs | Avoid | Reclamation discards in flight progress |
How do you run spot safely?
Safety is a handful of practices applied together. Put spot capacity in separate node pools and taint them, so only workloads with the matching toleration and node affinity land there and nothing reaches spot by accident. Set pod disruption budgets so the cluster never voluntarily evicts more replicas of a service than it can spare at once. Use topology spread constraints to distribute replicas across availability zones and across instance types, so a capacity event in one zone or one instance family does not take the whole service down. Run a node termination handler, or rely on Karpenter's interruption handling, so the short reclamation warning is used to drain the node gracefully and reschedule its pods. And keep a base of on demand nodes so there is always somewhere for evicted pods to land instantly. Diversifying across many instance types is the single most effective way to reduce correlated reclamation.
Ask what happens if a spot pool loses every node in one zone at once. If pod disruption budgets, topology spread, and an on demand base mean the service stays up and merely reschedules, the design is safe. If the answer is an outage, the workload mix or the diversification is wrong, not spot itself.
A worked example
A scaling fintech ran its entire cluster on on demand nodes because an earlier spot experiment had caused an incident when a single instance type was reclaimed across a zone. We separated spot into tainted node pools, moved only stateless services and batch onto them with tolerations and topology spread across zones and a wide set of instance types, set disruption budgets, added graceful termination handling, and kept an on demand base for stateful components. Node cost on the eligible workloads fell sharply, and a later reclamation event passed without any user impact because the load simply rescheduled. Figures are verified against billing data and anonymized.
Where to go next
Pair spot with switching off what no one is using in idle clusters and weekend waste, and tune the scaling that feeds it in horizontal autoscaling tuned for cost. See how the on demand base earns its discount in Kubernetes commitments, how they map, and find the full container lever set in the Kubernetes cost guide.
Frequently asked questions
Is it safe to run production on spot instances?
What workloads should not run on spot?
How much do spot instances save?
Take the next step on your cloud spend
We are an independent buyer side advisory that cuts public cloud spend across AWS, Azure, GCP, and OCI. We hold over $2.4B in annual cloud spend under management, take zero provider commissions, and deliver a 31 percent median reduction in the first 90 days. Our guarantee is simple: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk to you.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.