What Are Spot Instances?
AWS data centers always have spare capacity — servers that are powered on but not currently allocated to any customer. Rather than let that capacity sit idle, AWS offers it at a steep discount as Spot Instances: up to 90% cheaper than On-Demand pricing.
The trade-off: AWS can reclaim Spot Instances at any time when they need the capacity back. You receive a 2-minute interruption notice via the EC2 Instance Metadata Service and Amazon EventBridge. After 2 minutes, the instance is terminated (or stopped/hibernated, depending on your configuration).
This makes Spot Instances unsuitable for stateful, long-running workloads that can't tolerate interruption — but ideal for fault-tolerant, distributed, or batch workloads where individual node failures are handled gracefully.
Classic Spot use cases: Video transcoding, machine learning training, CI/CD build agents, web crawlers, Monte Carlo simulations, genomics pipelines.
Spot Pools and Why They Matter
A Spot Pool is a specific combination of instance type, operating system, and Availability Zone (e.g., c5.large + Linux + us-east-1b). Each pool has its own price and its own supply/demand dynamics. The key insight: different pools have very different interruption rates. A pool with lots of spare capacity is rarely interrupted. A pool that's nearly full gets interrupted constantly.
Allocation Strategies: How AWS Picks Your Instances
When you use an Auto Scaling Group with a mixed instances policy (combining Spot and On-Demand), you must choose an allocation strategy that tells AWS how to select from available Spot pools.
1. lowest-price (The Gambler)
- Logic: Give me instances from the cheapest pool right now.
- Problem: The cheapest pools are cheapest because they're in high demand. High demand means low spare capacity. Low spare capacity means frequent interruptions. You optimize for cost and get punished with instability.
- When to use it: Almost never for production. Acceptable for extremely short-lived batch jobs (under 5 minutes) where interruption probability is low regardless.
2. capacity-optimized (The Smart Play)
- Logic: Find the pools with the most spare capacity, regardless of price (within your configured instance types).
- Why it works: AWS has visibility into its own capacity. Pools with deep spare capacity are the least likely to be reclaimed. You pay slightly more than the absolute minimum, but your instances run longer and get interrupted far less.
- Verdict: The recommended strategy for most production Spot workloads. The small price premium is consistently worth the stability gain.
3. price-capacity-optimized (The Modern Default)
- Logic: A newer strategy that scores pools on a combination of price and available capacity, then selects from the top-scoring pools.
- Why it's better: It avoids the pure price trap of
lowest-pricewhile also not completely ignoring cost the waycapacity-optimizedcan in edge cases. - Verdict: AWS now recommends this as the default for most workloads. If you're starting fresh, use this.
Handling Interruptions Gracefully
The 2-minute warning is only useful if your application is designed to respond to it. Best practices:
- Drain connections: Use a lifecycle hook or the interruption notice to deregister the instance from a load balancer before it terminates.
- Checkpoint work: For batch jobs, save progress to S3 or a database so the job can resume on a new instance.
- Use SQS for job queues: If a worker is interrupted mid-job, the SQS message visibility timeout expires and the job is automatically requeued for another worker.
A common interview question is: "You're running a Spot-based batch processing fleet and jobs are failing when instances get interrupted. How do you fix it?" The answer has two parts: (1) architectural — use SQS as the job queue so interrupted jobs are automatically retried, and (2) operational — switch the allocation strategy from lowest-price to price-capacity-optimized to reduce interruption frequency. Interviewers want to see that you understand both the application-level retry pattern AND the infrastructure-level capacity selection.