Spot instances and performance risk: cheap capacity, with a catch
Spot instances cost up to 90% less but can be reclaimed with little warning, so the saving comes with an interruption risk. Matching Spot to fault-tolerant work, and blending with on-demand, is how you get the discount without the outage. Here is how.
Quick answer
Spot instances cost up to 90% less than on-demand but can be reclaimed with about two minutes notice, so the discount carries interruption risk. Use Spot for fault-tolerant, interruptible work (batch, stateless workers, CI), blend Spot with on-demand for services that need a reliable floor, and diversify instance types so a single capacity shortage does not take everything down.
Spot instances sell spare capacity at a steep discount, and the catch is simple: the cloud can take them back when it needs the capacity, with only a short warning. The saving is real and large, but only if the workload can absorb an interruption. Putting the wrong workload on Spot trades cost for outages.
The trade
Spot can be up to 90% cheaper than on-demand, which is transformative for the right workload. In exchange you accept that instances may be reclaimed with about two minutes notice when capacity tightens. The performance risk is not slower compute; it is losing the instance entirely, mid-task.
What belongs on Spot
| Workload | Spot fit |
|---|---|
| Batch and data processing | Great, reschedules on interruption |
| Stateless web/API workers | Good, behind a load balancer with on-demand floor |
| CI runners | Great, jobs retry |
| Stateful databases, singletons | Poor, interruption is disruptive |
Fault-tolerant, interruptible, stateless work is the sweet spot: if an instance vanishes, the system reschedules or another instance picks up. The detail on which workloads qualify is in when Spot saves money.
Managing the risk
Blend Spot with an on-demand (or reserved) baseline so a Spot shortage cannot drop you below a minimum capacity, diversify across instance types and Availability Zones so one capacity pool draining does not take everything, handle the interruption notice to drain gracefully, and keep state off Spot instances. Done this way, you capture most of the discount while holding your performance floor, the same cost-versus-headroom balance as autoscaling.
FAQ
What is the performance risk of Spot instances?
Not slower compute, but reclamation: the cloud can take a Spot instance back with about two minutes notice when it needs the capacity. If the workload cannot absorb an instance disappearing mid-task, the discount comes at the cost of interruptions.
Which workloads are safe to run on Spot?
Fault-tolerant, interruptible, stateless work: batch and data processing, CI runners, and stateless web or API workers behind a load balancer with an on-demand floor. Stateful databases and singletons are poor fits because interruption is disruptive.
How do I use Spot without risking an outage?
Blend Spot with an on-demand or reserved baseline so a shortage cannot drop below a minimum capacity, diversify across instance types and Availability Zones, handle the interruption notice to drain gracefully, and keep state off Spot instances.
How much do Spot instances save?
Up to about 90% versus on-demand, though the exact discount varies by instance type, region, and capacity. The saving is large enough to be transformative for suitable workloads, which is why matching Spot to fault-tolerant work is worthwhile.
Should I run production services on Spot?
Stateless production services can run largely on Spot if they sit behind a load balancer with an on-demand floor, diversify instance types, and drain gracefully on interruption. Stateful or singleton production components should stay on on-demand or reserved capacity.
Does C3X estimate Spot savings?
C3X prices your instances from Terraform, so you can compare on-demand against Spot pricing for the same fleet before deploy. Whether Spot is appropriate depends on the workload's fault tolerance, which you assess separately.
What to do next
Compare Spot and on-demand for your fleet before you commit. C3X reads your Terraform and prices both against a live catalog. Start with the quickstart.
Related posts
- Connection pooling: cheap capacity you are probably wasting
Every database connection consumes memory on the server, so without pooling you scale the database up just to hold connections. A pooler like PgBouncer or RDS Proxy lets a small database serve many clients. Here is the cost-performance case.
- GPU spot interruption economics: when a 70 percent discount is worth the risk
Spot GPUs cost 50 to 70 percent less and can vanish with two minutes of warning. Whether that trade is good depends on one number: how much work you lose per interruption, which is a function of your checkpoint interval.
- ECS capacity providers cost: mixing Spot, on-demand, and scaling
ECS capacity providers decide where your tasks run and in what mix, and that decision drives the cost of an ECS cluster. Splitting between on-demand and Spot, tuning target capacity, and choosing Fargate versus EC2 providers can cut container spend substantially. Here is how they work on cost.
- EC2 burstable instances (T-family): cheap until you burst
T-family burstable instances (t3, t4g) are the cheapest EC2 option for low-average-CPU workloads, using a CPU credit system. Understand credits and unlimited mode or you will get throttled or hit with surprise charges. Here is how they cost out.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.