Spot instances and performance risk: cheap capacity, with a catch

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.