Cloud providers build massive data centers with enormous excess capacity to handle peak demand periods (like Black Friday or major product launches). Most of the time, this capacity sits idle.
Rather than let it go to waste, they sell it on a Spot Market at steep discounts — often up to 90% off the On-Demand price. Think of it like an airline selling unsold seats at a deep discount one hour before departure. The seat is real and functional, but the airline reserves the right to bump you if a full-fare passenger shows up.
The Catch: Interruption
There is one critical constraint: Spot instances can be reclaimed by the cloud provider with only a 2-minute warning.
If the provider needs that capacity back for On-Demand customers, your Spot instance will be terminated. AWS sends an interruption notice via instance metadata and EventBridge, giving you 2 minutes to checkpoint state, drain connections, or gracefully shut down.
Spot Instance Pools
Spot capacity is organized into pools — each pool is a specific combination of instance type, operating system, and Availability Zone (e.g., c5.xlarge running Linux in us-east-1a). Each pool has its own price and interruption rate. Diversifying across multiple pools dramatically reduces the chance that all your Spot instances are interrupted simultaneously.
How to Use It Safely
You cannot run a traditional stateful database or a monolithic application server on Spot. If it disappears mid-transaction, the consequences are severe.
Spot is ideal for workloads that are:
- Fault-tolerant: If an instance dies, the work is retried on another instance — no data is lost.
- Stateless: The instance holds no unique local state that would be lost on termination.
- Flexible as to timing: It doesn't matter if the job finishes at 2 PM or 4 PM.
- Horizontally scalable: The work can be distributed across many small instances rather than requiring one large, persistent one.
Good Spot use cases:
- Batch data processing pipelines (e.g., Spark jobs on EMR)
- Video rendering and transcoding queues
- CI/CD build agents (each build is stateless and retriable)
- Load-balanced web server pools (as long as a minimum number of On-Demand/Savings Plan instances remain as a stable floor)
- Machine learning training jobs with checkpointing enabled
Bad Spot use cases:
- Primary relational databases (RDS, self-managed PostgreSQL)
- Stateful message brokers without replication
- Any single-instance workload with no redundancy
A common interview question: "How would you architect a batch processing system to safely use Spot instances?" The answer should mention: (1) using a managed queue (SQS, Kafka) so work items are not lost when an instance is terminated, (2) enabling Spot interruption notices via instance metadata to drain gracefully, (3) diversifying across multiple Spot pools using an Auto Scaling Group with a mixed instances policy, and (4) keeping a small On-Demand or Savings Plan baseline to ensure the system makes progress even during high Spot interruption periods.