AWSCost

AWS cost · spot instances

Spot instances: what is safe to run on them, and what is not

I moved almost everything I run to spot instances. The savings were the kind of number that makes you double-check the bill - the same compute, most of it running at a fraction of the on-demand price. Nothing broke, because I only put the right things there. That is the whole skill with spot: it is not a risky discount, it is a discount with one rule. Spot capacity can be reclaimed with two minutes notice. Match the workload to that rule and spot is close to free money. Ignore it and you get burned.

Spot instances are the same hardware as on-demand at up to 90% off, with one catch: AWS can reclaim them on a 2-minute notice. That makes them ideal for fault-tolerant, stateless work - batch jobs, CI, containerized workers, stateless services spread across types and AZs - and wrong for a single-node database or any stateful app with no failover.

What is actually safe to run on spot?

The test is simple: if this instance vanished in two minutes, would anything be lost? If the answer is no, it belongs on spot.

WorkloadSpot?Why
Batch jobs, data processingYesrestart the job, no harm done
CI/CD runnersYesa failed run reschedules on new capacity
Stateless web/API behind a load balancerYeswith capacity across types and AZs
Containerized workers (ECS/EKS)Yesthe scheduler reschedules interrupted pods
A single-node databaseNointerruption means data loss or downtime
Stateful app with no failoverNonothing catches the 2-minute notice

Why is spot so much cheaper?

Spot is AWS selling spare capacity it has not committed to anyone else. It is the exact same instance type, the same performance - the discount is not a lesser product, it is AWS filling idle machines. The price you pay for that is the reclaim: when AWS needs the capacity back, you get a 2-minute warning. So the deep discount is real, and the only thing standing between you and it is whether your workload can shrug off an interruption.

How do I run on spot without getting burned?

Diversify and stay stateless. Spread across many instance types and AZs so no single capacity pool can take you all the way down, keep an on-demand or reserved baseline for the part that must always be up, and let ECS or EKS handle rescheduling interrupted work. Before you move anything, it helps to see the current gap - this pulls the live spot price so you can compare it against the on-demand rate for the same instance type:

# current spot price by AZ for an instance type (edit the type/date)
aws ec2 describe-spot-price-history \
  --instance-types m7g.large \
  --product-descriptions "Linux/UNIX" \
  --start-time 2026-07-08T00:00:00Z \
  --query 'SpotPriceHistory[].{AZ:AvailabilityZone,Price:SpotPrice}' \
  --output table

Spot covers the interruptible layer. For the steady, always-on baseline you cannot put on spot, the lever is a reserved instance or Savings Plan, and anything left on-demand is worth a check for being oversized in the first place.

Want to know which of your workloads could move to spot - and what you would save? Connect your account read-only and see what it is wasting, in real dollars.

Connect your AWS

The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.

Frequently asked questions

How much cheaper are spot instances than on-demand?+

Spot instances run on spare AWS capacity at up to 90% off the on-demand price - commonly 60 to 90% depending on instance type and region. It is the same hardware and the same performance; the only difference is that AWS can reclaim the capacity when it needs it back.

What is the catch with spot instances?+

AWS can interrupt a spot instance with a 2-minute warning when it needs the capacity back. That is the whole trade. If your workload can handle being stopped and restarted somewhere else within two minutes, spot is close to free money. If it cannot, spot is the wrong choice.

What workloads are safe to run on spot?+

Anything fault-tolerant and stateless: batch jobs, data processing, CI/CD runners, rendering, and stateless services behind a load balancer with capacity spread across instance types and AZs. Containerized workers on ECS or EKS are a strong fit because the scheduler simply reschedules an interrupted task.

What should never run on spot?+

Anything stateful with no failover - a single-node database, a stateful app that holds data in memory, or a job that cannot be safely restarted. If a 2-minute interruption means data loss or user-visible downtime, keep it on on-demand or reserve it.

How do I handle spot interruptions?+

Spread across many instance types and AZs so no single capacity pool can take you down, use a mix of spot and on-demand as a baseline, and listen for the 2-minute interruption notice to drain gracefully. On ECS and EKS this is largely handled for you - the scheduler reacts to the notice and moves work to healthy capacity.

Spot vs reserved instances - which should I use?+

They solve different problems. Spot is cheapest but interruptible, so it fits fault-tolerant work. A reserved instance or Savings Plan discounts steady-state workloads you cannot interrupt. Many accounts use both - reserve the always-on baseline, run the flexible, interruptible layer on spot.

Related cost breakdowns

More AWS cost breakdowns