Spot vs on-demand savings explained: big discounts with a catch

Quick answer

Spot instances are spare cloud capacity sold at a steep discount off on-demand prices, often a large fraction cheaper, in exchange for the provider being able to reclaim them with only short notice. They are ideal for interruption-tolerant workloads: batch jobs, CI, stateless services behind autoscaling, big-data processing, and anything that can checkpoint and resume. They are unsuitable for workloads that cannot tolerate sudden termination, like a stateful single instance. Used correctly, with diversification and graceful interruption handling, spot delivers the biggest per-instance discount available. The catch is interruption, so design for it.

Spot instances are the largest single discount in cloud compute: the same hardware as on-demand, sold much cheaper because it is spare capacity the provider can take back at short notice. That one catch, interruption, is the whole story. Get comfortable with it and spot slashes the cost of a huge class of workloads; ignore it and spot will break the workloads that cannot handle being reclaimed.

How spot differs from on-demand

Factor	On-demand	Spot
Price	Full rate	Steep discount off on-demand
Availability	Guaranteed until you stop it	Reclaimable with short notice
Best for	Anything, especially stateful	Interruption-tolerant workloads

On-demand instances run until you stop them, at the full rate. Spot instances run at a large discount but can be reclaimed when the provider needs the capacity back, giving only a brief warning before termination. So spot trades a guarantee of availability for a much lower price, and the workload has to be able to survive losing an instance on short notice.

What spot is good for

Spot suits any workload that tolerates interruption: batch and data-processing jobs that can checkpoint and resume, CI and build runners, stateless services behind an autoscaler that can replace a lost instance, rendering, and machine-learning training that checkpoints. These workloads either do not care if an instance vanishes or can recover cleanly, so they capture the full discount. This is why spot appears throughout cost guides, from CI runners to Kubernetes nodes.

What spot is not good for

Spot is a poor fit for workloads that cannot tolerate sudden termination: a stateful database on a single instance, a workload with no redundancy, or anything where losing the instance means losing data or causing an outage. For steady, always-on workloads that need guaranteed availability, use on-demand with a commitment discount instead, which lowers cost without the interruption risk.

Using spot safely

Design for interruption: handle the termination notice gracefully (drain, checkpoint, save state), diversify across instance types and Availability Zones so a shortage in one does not take everything, and combine spot with on-demand or reserved capacity for a baseline that must stay up. Right-size the instances first, as in the EC2 right-sizing guide. Price your spot-eligible workloads against the resource catalog so the savings are planned into the architecture.

FAQ

What are spot instances?

Spare cloud capacity sold at a steep discount off on-demand prices, often a large fraction cheaper, in exchange for the provider being able to reclaim them with only short notice. They run the same hardware as on-demand but trade guaranteed availability for a much lower price, so they suit workloads that can tolerate an instance being terminated on short warning.

How much do spot instances save?

Spot offers the largest single discount in cloud compute, frequently a large fraction off the on-demand rate, though the exact discount varies by instance type, region, and current spare capacity. Because the savings are so steep, spot is the most cost-effective way to run interruption-tolerant workloads, provided you design for the possibility of the instance being reclaimed.

What workloads are good for spot instances?

Interruption-tolerant workloads: batch and data-processing jobs that can checkpoint and resume, CI and build runners, stateless services behind an autoscaler that can replace a lost instance, rendering, and machine-learning training that checkpoints. These either do not care if an instance vanishes or can recover cleanly, so they capture the full spot discount without risking data or availability.

When should I not use spot instances?

For workloads that cannot tolerate sudden termination: a stateful database on a single instance, a workload with no redundancy, or anything where losing the instance means losing data or causing an outage. For steady, always-on workloads that need guaranteed availability, use on-demand with a Savings Plan or Reserved Instance commitment, which lowers cost without the interruption risk spot carries.

How do I use spot instances safely?

Design for interruption: handle the termination notice gracefully by draining, checkpointing, and saving state, diversify across instance types and Availability Zones so a shortage in one does not take everything down, and combine spot with on-demand or reserved capacity for any baseline that must stay up. Right-sizing the instances first ensures you capture the discount on appropriately-sized capacity.

How does C3X help with spot instance savings?

C3X prices your infrastructure from Terraform before you deploy, so you can see the cost of spot-eligible workloads and plan the savings into the architecture at design time. That helps you identify which workloads can run on spot for the largest discount and confirm the cost benefit in the pull request, rather than leaving interruption-tolerant workloads on full-price on-demand.

What to do next

Plan spot savings into your architecture before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.