Spot cuts compute by up to 90% — with interruption. The two-minute reclaim, workloads that suit it, and those that must avoid it.
Nearly every AWS discount roundup covers Spot in a single sentence: use spare capacity, save up to 90%, but mind the stability of supply.
Nothing there is wrong, but it omits the two things that decide whether you can use it at all: where that 90% comes from (under what conditions), and how interruption actually happens (how much warning, can you finish cleanly). Without those, you neither dare use it nor know how to.
This page covers both, and gives a checklist of four workloads that fit and three that must never go on it. All five providers have this layer; what differs is how much warning you get and how deep the discount goes — see cloud discount mechanisms compared.
What "up to 90% off" leaves out
The first omission: the number floats, and someone else sets it. Spot prices follow supply and demand per region and instance type in real time — it is not a fixed discount. "Up to about 90% off" is an observed ceiling in AWS's own material, not something you are entitled to. Popular instance types in tight periods may discount very little.
The second omission: you are not paying money, you are paying certainty. On-demand is expensive because it is always there; Spot is cheap because it can be taken back. The Spot discount is essentially the price of interruption risk — once you see that, the only remaining question is how much interruption your workload can absorb.
| Dimension | On-Demand | Reserved / Savings Plans | Spot |
|---|---|---|---|
| Unit price | Highest | Mid (commitment for discount) | Lowest (wide range, up to ~90% off) |
| Can it be interrupted | No | No | Yes, roughly two minutes notice |
| Commitment | None | Yes (1 or 3 years) | None |
| Best for | Uncertain, temporary, must-not-break | Steady baseline | Interruptible, retryable compute |
One line: Reserved Instances and Savings Plans are "commit for cheap"; Spot is "accept risk for cheap". They do not conflict — they should be used together. Cover the baseline with a commitment, hand the elastic remainder to Spot.
What Spot actually is: not discounted EC2, but someone else's spare window
Thinking of Spot as "discounted EC2" leads you astray. A closer analogy: the part of a region's capacity pool nobody currently wants, sold at whatever supply and demand dictates. When a higher-priority claim on that capacity appears, it is taken back.
Three properties follow, and they determine how you use it:
- Price moves with supply and demand. The same instance type can differ substantially by region and by time of day. Choosing less popular types and spreading across regions often improves price and interruption rate together.
- Capacity is not guaranteed. Ask for 100 and you may get 70. Requests can partially fail.
- Interruption is part of the design, not a fault. It is not "occasionally goes wrong" — it is the normal behaviour of this mechanism. Your system has to assume it happens.
So the precondition for Spot is "the workload can be interrupted", not "hopefully it will not be". That is where most misuse comes from: putting something uninterruptible on Spot and hoping.
How interruption happens: the two-minute notice and three reclaim triggers
When Spot capacity is reclaimed, AWS gives roughly two minutes of advance notice (historically two minutes; confirm against current documentation). Those two minutes are all the wind-down time you get — see the end of this section for how to spend them.
Reclaim is triggered in a few ways, and knowing them helps you configure correctly:
| Trigger | What it means | What you can do |
|---|---|---|
| Capacity demand rises | A higher-priority claim needs that capacity | Change instance type or AZ; spreading across types usually cuts the hit rate sharply |
| Price exceeds your max | Current Spot price is above the ceiling you set | Set the ceiling sensibly (in many cases setting it at the on-demand price still earns a discount) |
| Pool exhausted | That capacity pool has nothing to allocate right now | Multiple AZs + multiple instance types is the most effective answer |
Three things to do with the two minutes (in order): ① stop accepting new requests (remove from the load balancer); ② write progress to external storage (checkpoint, or return the message to the queue); ③ finish the current shard or abandon it deliberately. All three must be coded in advance — there is no time to decide during an interruption.
One thing often missed: interruption does not have to mean lost work. Design tasks as "small shards + retryable + idempotent" and one interruption costs a single shard, not the whole batch. That engineering precondition matters more than which instance type you pick.
Four workloads that suit Spot
There is one test: if it is interrupted, is re-running acceptable? The smaller the cost of a re-run, the better the fit. By that test, these four usually qualify.
| Type | Examples | Why it fits |
|---|---|---|
| Batch / offline compute | Log analysis, reporting, ETL, video transcoding | Shardable and retryable; an interruption hits one shard |
| CI/CD and testing | Builds, automated tests, load tests | Naturally short-lived; a break simply means run it again |
| Stateless elastic capacity | Web tier that scales freely, queue consumers | When a node disappears, requests get rescheduled elsewhere |
| Fault-tolerant training / rendering | Checkpointed model training, render farms | Checkpoints allow resume; the loss is bounded |
- What they share: none depends on "this machine must stay up".
- A quantifiable rule: if the average cost of one interruption is under 5–10% of what the discount saves, go ahead.
The most underrated category is the stateless web tier. Many teams relegate Spot to batch only, but "a fixed block of reserved/on-demand + an elastic block of Spot" is extremely cost-effective for web services with clear peaks — Spot carries the peaks, commitments carry the baseline.
Instance selection and capacity planning are on how to choose EC2 instances.
Three things that must never go on Spot
These three are where real incidents come from. What they share is that interruption causes data loss or a user-visible failure — not merely "slower".
- The primary node of a stateful database. Reclaim means a write interrupted mid-flight and a replication relationship to rebuild. Even with replicas, losing the primary triggers failover — far more expensive than the saving. Database cost should be addressed with Reserved Instances, storage tiering and read replicas; see AWS discounts beyond EC2.
- Services that hold state locally and cannot re-run. Anything keeping sessions, temp files or intermediate results on instance storage: reclaim the machine and the data is gone. The test: is there anything on local disk that, if lost, means starting over?
- Tasks with a hard delivery window. Batch that must finish by a fixed time with no room to re-run (for example pre-settlement processing). Spot interruption is unpredictable — do not gamble on it.
⛔ An easily missed middle ground: tasks that can be interrupted but need a human to recover. Do not put those on Spot — the saving is eaten by operations time. "Retryable" means automatically retryable; if it needs a person, it does not count.
One more boundary case worth naming: long-running services with an external SLA, even stateless ones. If a large-scale reclaim leaves you short of capacity and responses slow down, that is an SLA incident. For those, guarantee the baseline with reserved/on-demand and treat Spot purely as peak headroom.
Making it stable: many types, many AZs, mixed base
Spot stability does not come from picking the right instance type — it comes from spreading. Three actions, most effective first:
- Multiple instance types. Do not request one type; request a set of types with similar compute. When one pool tightens, allocation falls through to others and interruption rates typically drop sharply.
- Multiple availability zones. Spread requests across AZs within a region so one zone's squeeze does not take down the whole fleet.
- Mixed instances policy. Configure an Auto Scaling group with a reserved/on-demand baseline plus a Spot elastic portion. The baseline guarantees a floor; Spot absorbs elasticity. This is the most robust shape in production.
| Shape | Suits | Risk |
|---|---|---|
| Pure Spot | Internal tools, pure offline jobs | Interruption hits all capacity; only for fully re-runnable work |
| On-demand baseline + Spot elasticity | The mainstream production shape | Baseline holds; interruption only reduces peak capability |
| Reserved baseline + Spot elasticity | Clear steady state with distinct peaks | Cheapest overall, but needs an accurate baseline estimate |
Allocation strategy deserves a note: capacity-optimised style strategies prefer pools that are currently least likely to be reclaimed, which is usually more stable than "pick the cheapest pool" — the cheapest pool is often the tightest one. Do not select pools on price alone.
Relationship with commitment discounts: Spot usage is not covered by Reserved Instances or Savings Plans — those offset on-demand-class compute. So they do not conflict; they divide the work: steady state on commitments, elasticity on Spot.
How to size Reserved Instances (how much, how long, what to do after a wrong call) is on how to buy AWS Reserved Instances; how the two saving paths stack is on AWS discounts and reseller pricing.
Common questions
Does Spot really save 90%?
"Up to about 90% off" is an observed ceiling in AWS material, not a guarantee. Actual discounts swing widely by instance type, region and time — popular types in tight periods may barely discount. Do not model your saving at 90%; model it at the price you actually get. Choosing less popular types and spreading across regions usually improves both price and interruption rate.
How much warning, and what can I do in two minutes?
Roughly two minutes (confirm against current documentation). Enough for three things: stop taking new requests, write progress to external storage, and finish or deliberately abandon the current shard. The prerequisite is that this logic is already written — there is no time to decide or to involve a person.
Can I put a database on Spot?
Not the primary. Reclaim means interrupted writes and a failover, which costs far more than the saving. Having replicas does not change this — the failover itself is the incident. Address database cost with Reserved Instances, storage tiering and read replicas; see AWS discounts beyond EC2. Read replicas or analytical followers can be reasonable in some setups, but the cost of a re-run still has to be quantified.
How do I lower the chance of being reclaimed?
By spreading, not by picking: request a set of instance types with similar compute rather than one, request across several AZs, and use a capacity-optimised allocation strategy (prefer pools least likely to be reclaimed rather than the cheapest). Those three beat any single parameter.
Can Spot and Savings Plans be used together?
They do not conflict because they cover different usage: Savings Plans offset on-demand-class compute, and Spot usage is outside their scope. The sensible division is steady baseline on Reserved Instances or Savings Plans, elasticity on Spot. Treating them as alternatives is a common misunderstanding.
Is it safe to run Spot in production?
Yes, with a mixed base: guarantee baseline capacity with on-demand or reserved, and let Spot carry everything above the baseline. Then even a full Spot reclaim leaves you running at baseline, with reduced peak capability. Pure Spot for a production service only fits where work is fully re-runnable and there is no SLA.