1 Overview
Most teams running containers in the cloud start with the safest possible capacity: on-demand instances that stay up until you delete them. That choice is easy to reason about, and it removes a whole category of operational surprises. The problem is that it quietly becomes the default forever, even for workloads that do not need that level of stability. A stateless API behind a load balancer, a queue consumer, a batch renderer, a scheduled job runner: none of these care which specific machine they run on, only that enough capacity exists somewhere in the fleet. When that is true, paying the premium for guaranteed, uninterrupted capacity is a form of overprovisioning that shows up on every invoice.
Spot capacity, sometimes called preemptible or interruptible capacity, is spare compute sold at a discount in exchange for the provider's right to reclaim it. The discount is real and usually substantial in relative terms, but so is the trade: instances can disappear with little warning. The mistake teams make is treating this as a binary decision, either all on-demand or all spot. In practice the interesting design space is mixed, where interruption-tolerant replicas absorb the cheap capacity and a small stable floor keeps the service alive when reclamation spikes.
This article is about the pattern, not any particular vendor. The mechanics differ in details, but the shape of the problem is consistent: you have elastic, disposable work, and you are paying for durability you do not use.
2 Why this workload pattern matters
Containerized services are unusually good candidates for interruptible capacity because the unit of work is already disposable. A container is designed to be replaced, rescheduled, and restarted. The scheduler already assumes that any given replica might vanish and that its replacement will come up somewhere else. That assumption is exactly the contract that spot capacity offers. When your workload already tolerates replica churn, the marginal cost of tolerating instance churn is mostly engineering effort, not architectural change.
The economics matter because container fleets tend to scale with traffic, and traffic is spiky. A service sized for peak demand sits idle most of the day, and idle capacity is where the premium for guaranteed availability is most wasteful. If a meaningful share of your replicas can run on discounted capacity, the blended cost of the fleet drops without changing the peak capacity you can serve. The savings scale with the fleet, so the pattern rewards teams that right-size rather than teams that overbuy.
There is also a reliability argument that gets overlooked. Teams that depend entirely on one capacity type inherit that type's failure modes. A mixed fleet is more resilient to provider-side incidents, quota problems, and regional capacity shortages, because the scheduler has more than one pool to draw from. Interruptible capacity is not just cheaper; it is a second source of supply. The discipline of designing for interruption tends to produce services that degrade more gracefully under all kinds of pressure, not only reclamation.
3 The architecture in plain terms
The core idea is to separate replicas into tiers by how much disruption they can absorb. A small floor of stable capacity runs the replicas that must stay up: the ones holding leadership, serving latency-sensitive traffic, or maintaining long-lived connections. The rest of the fleet runs on interruptible capacity and is treated as expendable. The scheduler places work across both pools, and a controller watches for reclamation signals so it can drain and replace affected replicas before they are taken away.
Graceful shutdown is the load-bearing detail. When a reclamation notice arrives, the affected node should stop accepting new work, finish or hand off in-flight requests, and let the orchestrator reschedule its pods elsewhere. That requires realistic termination grace periods, readiness probes that actually reflect whether a replica can serve, and connection draining at the load balancer. Without those, reclamation looks like a hard crash and users see errors. With them, reclamation looks like a rolling restart that nobody notices.
Capacity diversity is the second pillar. Spreading replicas across multiple instance families, availability zones, and capacity pools reduces the chance that a single reclamation event takes out a large fraction of the fleet at once. The scheduler should prefer spreading over packing, and the autoscaler should treat interruptible capacity as a pool with a variable size rather than a fixed target. The result is a fleet that looks ordinary from the outside and is assembled from whatever cheap capacity happens to be available at any moment.
4 Scaling and cost trade-offs
Autoscaling on interruptible capacity needs to be more aggressive than autoscaling on stable capacity, because the pool can shrink without warning. A common approach is to keep a headroom buffer above the observed demand so that losing some replicas does not immediately saturate the rest. The buffer is a cost, but it is usually far smaller than the premium paid for guaranteed capacity across the whole fleet. The right buffer size depends on how bursty the workload is and how quickly new capacity can be acquired, which is often the real constraint during a widespread reclamation event.
Relative cost comparisons are the useful frame here. Interruptible capacity typically costs a fraction of the equivalent stable capacity, and a blended fleet lands somewhere between the two depending on the mix. The savings are largest for workloads with long-running, low-urgency tasks and smallest for latency-critical services that need a large stable floor. There is no universal ratio, and anyone quoting a fixed percentage is guessing. What matters is measuring your own interruption rate, your own replacement latency, and your own tolerance for degraded performance, then choosing a mix that keeps the service within its objectives.
The hidden cost is engineering time. Designing for interruption, testing reclamation handling, and tuning autoscalers takes effort that does not show up on the invoice. For small fleets the savings may not justify that effort. For large, elastic container fleets the math usually favors a mixed model, because the same engineering investment amortizes across many replicas and many months. The trade-off is not cheap versus expensive; it is predictable spend versus engineering discipline, and the right answer depends on scale.
5 Failure modes and what to watch
The dominant failure mode is abrupt reclamation that outpaces replacement. If many replicas are reclaimed at once and new capacity is slow to arrive, the remaining replicas take on more traffic than they can handle, latency climbs, and queues back up. This is especially dangerous for services with long startup times, because a replacement that takes minutes to become ready does not help during a spike. Watch the gap between capacity lost and capacity regained, and alert on it rather than only on raw replica count.
A second failure mode is improper shutdown handling. If termination grace periods are too short, or if the application ignores the shutdown signal, in-flight requests are dropped and users see errors that look like random flakiness. This is insidious because it only appears during reclamation, which may be rare enough that it escapes testing. Load tests that simulate node loss, not just traffic spikes, are the way to catch it. Similarly, readiness probes that report ready before the application can actually serve traffic will route requests to replicas that are still warming up.
A third risk is correlated capacity. If your interruptible pool depends on a single instance family or zone, a provider-side event can reclaim a large share of it simultaneously. Diversifying pools and zones reduces correlation, but it also complicates scheduling and cost tracking. Finally, beware of silent degradation: a service that quietly serves stale data or drops background work under pressure may pass health checks while failing its actual purpose. Define what correct behavior looks like under partial capacity loss, and test for it deliberately.
6 Operating it in practice
Start by classifying workloads rather than instances. For each service, ask whether a replica can be lost right now without violating a user-facing objective. Services that pass that test can run mostly on interruptible capacity; services that fail it need a stable floor. Document the classification and revisit it as the service evolves, because a workload that was interruption-tolerant last quarter may have grown state or long-lived connections since. The classification is the policy that the scheduler and autoscaler enforce.
Instrument the things that actually predict pain: reclamation rate, replacement latency, queue depth, error rate during churn, and the fraction of the fleet running on each capacity type. Dashboards should make it obvious when the cheap pool is shrinking faster than replacements arrive. Run game days where you deliberately drain a large share of the interruptible pool and confirm that the service stays within its objectives. These exercises surface the gaps between what the architecture assumes and what the code actually does.
Keep a runbook for capacity emergencies, including how to shift the mix toward stable capacity quickly when the interruptible pool becomes unreliable. Automate that shift if you can, but keep a manual override for the cases automation gets wrong. Finally, review the mix periodically. The right balance changes with traffic patterns, provider behavior, and the cost of engineering time. Treating the mix as a tunable parameter rather than a one-time decision is what keeps the savings real without turning reliability into a gamble.
7 Frequently asked questions
Is interruptible capacity safe for production? It can be, for the right workloads. The question is not whether reclamation happens but whether your service can absorb it without violating its objectives. Stateless, horizontally scaled services with proper draining usually can. Stateful services, single-replica services, and anything with strict latency guarantees need a stable floor or a different capacity strategy entirely. The safe answer is a mixed fleet with a deliberate policy, not an all-or-nothing bet.
How much can I save? Relative savings are meaningful but vary with the mix, the workload, and how often capacity is reclaimed. Anyone promising a specific percentage is oversimplifying. Measure your own interruption rate and replacement latency, then model the blended cost. The savings come from shifting the interruptible-tolerant share of the fleet, so the more of your workload that qualifies, the larger the effect.
Do I need Kubernetes or a specific orchestrator? No. The pattern applies to any scheduler that can reschedule containers across capacity pools and react to reclamation signals. The important capabilities are graceful shutdown, readiness gating, connection draining, and autoscaling that treats capacity as variable. If your platform provides those, the pattern works; if it does not, fix that first.
What is the biggest mistake teams make? Treating spot as a pure cost optimization and skipping the reliability work. The discount is only real if the service stays healthy under reclamation. Teams that adopt interruptible capacity without draining, headroom, and testing often end up paying the savings back in incidents and lost trust.