AWS Spot Instances: How They Work and When to Use Them

AWS Spot Instances deliver 70-90% discounts off on-demand pricing by letting you access unused EC2 capacity. They're the single highest-leverage cost optimization tool in AWS—if you can handle interruptions. The catch: AWS can reclaim Spot instances with two minutes' notice when capacity is needed elsewhere, making them unsuitable for stateful or interruption-sensitive workloads. But for stateless services, batch jobs, CI/CD pipelines, and Kubernetes nodes, Spot is production-ready and routinely saves teams $50,000+/month.

The most common misconception: "Spot is too unreliable for production." In reality, interruption rates are lower than most teams expect, particularly when you diversify across multiple instance types. The key is understanding when interruptions happen, how to handle them gracefully, and which workloads belong on Spot.

How Spot Pricing Works

Spot pricing fluctuates based on supply and demand for each instance type in each Availability Zone. When AWS has excess capacity, Spot prices drop significantly below on-demand rates. When demand increases, prices rise—and if Spot demand exceeds supply, AWS reclaims instances by sending a two-minute termination warning.

To understand the mechanics, start with our guide on Spot instance pricing explained, which covers how AWS sets Spot prices, why they fluctuate, and how to interpret the EC2 Spot Instance Advisor. The short version: Spot prices are set dynamically per instance type, per Availability Zone. An m5.large in us-east-1a might cost $0.02/hour while the same instance in us-east-1b costs $0.05/hour at the same moment.

Pricing Strategy

AWS recommends not setting a maximum Spot price—instead, let Spot default to the on-demand price as the cap. This ensures you never pay more than on-demand, while the market determines your actual discount. Setting a custom max price can lead to unnecessary interruptions when Spot prices spike temporarily but remain below on-demand rates.

For a comprehensive overview of how Spot instances work end-to-end, see how Spot instances work, which explains request types (one-time vs persistent), capacity pools, and allocation strategies.

One tip is to use the EC2 Spot Instance Advisor to identify instance families with <5% monthly interruption rates. Diversify across 10-15 instance types to maximize availability and minimize interruption risk. Instance types with consistently low interruption rates (m5, c5, r5 families) often deliver reliable Spot capacity in most region.

What Causes an Interruption

AWS reclaims Spot instances in two scenarios: (1) capacity constraints—when AWS needs the capacity for on-demand or Reserved Instance customers, or (2) price exceeds your maximum bid (if you set one). The first scenario is by far the most common.

Our guide on what triggers a Spot reclaim explains the termination lifecycle in detail. The critical insight: AWS provides a two-minute warning via the EC2 instance metadata service (/latest/meta-data/spot/instance-action) before terminating an instance. Modern tools (AWS Node Termination Handler, Karpenter) watch this endpoint and drain workloads gracefully during the two-minute window.

Reliability Myths

Many teams avoid Spot based on outdated assumptions. Our article on Spot reliability myths debunks common misconceptions:

• Myth: Spot instances are interrupted constantly. Reality: Interruption rates for most instance families are <5% monthly. Diversifying across instance types brings this down further.
• Myth: Spot can't run production workloads. Reality: With proper interruption handling (PodDisruptionBudgets in Kubernetes, autoscaling groups with multiple instance types), Spot runs production-grade workloads reliably.
• Myth: Spot interruptions are unpredictable. Reality: AWS publishes interruption frequency data via the Spot Instance Advisor. Low-interruption instance families (<5%) are predictable enough for most production use cases.

For additional insights, see facts about Spot that surprise most teams, including lesser-known strategies like Spot placement scores and capacity optimized allocation.

Which Workloads Belong on Spot

Not every workload tolerates interruptions. Use this decision matrix:

Kubernetes and Container Workloads

For teams running Kubernetes (EKS, self-managed), Spot is often an excellent default for interruption-tolerant Kubernetes worker capacity, typically combined with an On-Demand baseline for critical workloads. Our guide on running Spot on Kubernetes nodes covers the full lifecycle: configuring Karpenter or Cluster Autoscaler for Spot capacity, setting PodDisruptionBudgets (PDBs) to prevent simultaneous evictions, and handling termination notices with AWS Node Termination Handler.

Key strategies:

• Diversify instance types: Configure broad NodePool requirements rather than restricting Karpenter to a small set of instance types. Allowing many compatible instance types and Availability Zones gives Karpenter more options when Spot capacity becomes constrained.
• Layer Spot and on-demand: Run stateless workloads (web, workers, batch) on Spot; keep stateful services (databases, caches) on on-demand or Reserved Instances.
• Use PodDisruptionBudgets: Ensure critical services maintain minimum replica counts during Spot interruptions. A PDB prevents Kubernetes from evicting the last replica of a deployment during a node drain.

Spot vs Reserved Instances vs Savings Plans

Spot, Reserved Instances (RIs), and Savings Plans serve different use cases. The optimal savings rate typically involves a combination. Understanding when to use each—and how they layer—is critical for maximizing AWS cost efficiency.

Our detailed comparison Spot compared with Reserved Instances explains the trade-offs:

• Spot Instances: 70-90% discount, no commitment, interruptible. Best for stateless workloads where interruptions are acceptable.
• Reserved Instances: up to 72% discount, 1- or 3-year commitment. Best for stable, long-running instances (databases, legacy apps).
• Savings Plans: 40-60% discount, 1- or 3-year hourly spend commitment, flexible across instance families/regions. Best for dynamic workloads where instance types change frequently.

How Spot and Savings Plans Work Together

A common misconception is that you can’t run Spot instances with Savings Plans. In reality, Spot and Savings Plans operate on different layers. Our guide on how Spot and Savings Plans work together clarifies the mechanics:

• Spot instances receive 70-90% discount off on-demand pricing
• Savings Plans apply to the on-demand portion of your workload (instances not covered by Spot or RIs).

Example: You run 100 instances. 70 are Spot (70-90% discount), 30 are on-demand. A Compute Savings Plan covering 20 instances will discount those 20 on-demand instances by ~50%—bringing your effective discount on those 20 from 0% to 50%, while the 70 Spot instances remain at 70-90% off.

Implementing Spot Safely

Adopting Spot requires more than flipping a switch—you need interruption handling, diversification, and monitoring. Our guide on maximizing Spot savings and stability covers the full implementation checklist:

1. Interruption Handling

Install AWS Node Termination Handler (for EC2) or use Karpenter (for EKS). These tools watch the instance metadata endpoint for termination notices and drain workloads gracefully during the two-minute warning period. Without graceful termination, Spot reclaims result in abrupt connection drops and failed requests.

2. Diversification

Target 10-15 instance types across multiple families (m5, m6i, c5, c6g, r5, etc.). This maximizes Spot pool availability and reduces the likelihood that all your instances get interrupted simultaneously. Use EC2 Fleet or Auto Scaling Groups with "capacity optimized" allocation strategy to automatically select the most available Spot pools.

3. Workload Segmentation

Never run stateful services on Spot. Databases, caches, message brokers, and session stores should use on-demand or Reserved Instances. Use Spot exclusively for stateless workloads that can tolerate interruptions (web servers, workers, batch jobs, CI/CD runners).

4. CI/CD Pipelines on Spot

CI/CD is the easiest Spot adoption target—builds are ephemeral and restartable. Our guide on running CI/CD pipelines on Spot explains how to configure Jenkins, GitLab CI, and GitHub Actions to use Spot runners. One team reported $51,000/month savings by migrating 70% of their CI/CD infrastructure to Spot.

For CI/CD, use persistent Spot requests with "terminate" interruption behavior. When a build runner is interrupted, the Spot request automatically provisions a replacement in a different Spot pool, ensuring builds queue briefly but eventually complete.

Optimize AWS Costs Automatically with nOps

Commitment optimization is often the biggest lever for Kubernetes savings. nOps helps you save 50-60% automatically, with 5-minute setup and no infrastructure changes required.

Maximize savings. nOps continuously layers commitments in small hourly increments to capture 55%+ savings while minimizing overcommitment risk — even for dynamic workloads

Results-based pricing model: Customers typically save ~20% more by switching to nOps — and you pay only when you get better results.

Free Savings Analysis: Quantify exactly how much more you can save for no work on your part. We optimize, and you get the credit.

You can book a free savings analysis to find out how nOps can help you start saving today!

nOps processes over $4 billion in cloud spend and was recently named #1 in G2's cloud cost management category.

FAQ