AWS EC2 Spot Instances Explained: Savings, Risks, Uses

Simple explanation

AWS runs data centres with more physical capacity than its on-demand customers are currently using. Rather than leave that spare capacity idle, AWS rents it out at a steep discount. These are Spot Instances.

The trade-off is that the capacity is not guaranteed. If AWS needs it back for an on-demand customer, it reclaims your instance with a 2-minute warning. That makes Spot unsuitable for anything that must stay running. It is ideal for work that can be paused, retried, or spread across many short-lived machines.

Good example: a batch job that processes 1,000 video files. Each file is independent. If an instance is interrupted mid-file, you reprocess that one file on another instance. Your total cost on Spot might be $30 instead of $200.

How Spot Instances work

Each AWS Availability Zone maintains a pool of capacity for each EC2 instance type. When on-demand and reserved customers are not using all of it, the remainder becomes available as Spot.

The Spot price fluctuates based on supply and demand in each AZ for each instance type. AWS publishes historical pricing so you can see how stable a given instance type tends to be in a given zone. In practice, most pools are stable. Large sudden price spikes are rare.

AWS retired the old bidding model in 2017. You no longer submit a bid price. Instead, you set a maximum price (which defaults to the on-demand price if you leave it unset). Your instance keeps running as long as the current Spot price is below your maximum and AWS has not reclaimed the capacity.

In most real interruptions, the reason is that AWS needs the capacity for on-demand demand, not because the price exceeded your threshold. This means diversifying across instance types and AZs matters far more than tuning your maximum price.

How interruptions work

When AWS needs to reclaim Spot capacity, it sends a 2-minute interruption notice through two channels:

1. Instance metadata endpoint: http://169.254.169.254/latest/meta-data/spot/interruption-notice returns the scheduled interruption time once a notice has been issued. Poll this endpoint every 5 seconds from your application or a sidecar process.
2. EventBridge event: AWS publishes an EC2 Spot Instance Interruption Warning event to EventBridge. You can route this to a Lambda function, SQS queue, or SNS topic to trigger graceful shutdown logic from outside the instance.

In those two minutes, a well-designed application should: stop accepting new connections, finish any in-flight requests, drain from the load balancer target group, save any checkpoint state to S3 or a database, and exit cleanly.

After the notice period, AWS stops, terminates, or hibernates the instance depending on the interruption behaviour you configured. For stateless applications, terminate is the right default. For resumable jobs, stop or hibernate preserves work in progress so the job can continue when the instance restarts elsewhere.

Rebalance recommendations

Before the 2-minute interruption notice, AWS may send an EC2 Instance Rebalance Recommendation signal. This arrives when an instance is at elevated risk of interruption. The Spot pool it is running in is becoming constrained. The rebalance recommendation does not guarantee an interruption is coming, and it does not start the 2-minute clock. But it gives your infrastructure more lead time to act.

The right response is to enable Capacity Rebalancing in your Auto Scaling Group. When Capacity Rebalancing is on, the ASG listens for rebalance recommendations and proactively launches a replacement instance from a healthier Spot pool, only terminating the flagged instance once the replacement is in service. This keeps your fleet size stable and avoids a sudden multi-instance loss when a whole pool tightens.

How to run Spot safely in production

The standard production pattern is a mixed-instance Auto Scaling Group: a guaranteed base of On-Demand instances for reliability, plus a larger share of Spot instances for cost savings. You configure this with a launch template and a mixed instances policy.

Three practices make Spot reliable at scale:

1. Diversify instance types. Include at least 4–6 instance types with similar CPU and memory profiles (for example: m5.large, m5a.large, m4.large, t3.large, t3a.large). If one pool is interrupted, the ASG launches from another type automatically.
2. Spread across multiple AZs. Spot interruptions are AZ-specific. A capacity crunch in a single AZ can take down your entire fleet at once. Always spread across at least two AZs using multiple subnet IDs in your ASG configuration.
3. Keep an On-Demand base. Always run a minimum number of On-Demand instances so you have guaranteed capacity even if all Spot pools are temporarily unavailable. Two is a common minimum for a web tier.

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name mixed-spot-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "web-server-template",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5a.large"},
        {"InstanceType": "m4.large"},
        {"InstanceType": "t3.large"},
        {"InstanceType": "t3a.large"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "price-capacity-optimized"
    }
  }' \
  --capacity-rebalance \
  --min-size 2 \
  --max-size 20 \
  --desired-capacity 6 \
  --vpc-zone-identifier "subnet-abc,subnet-def,subnet-ghi"

What this configuration does:

• Keeps at least 2 On-Demand instances running at all times (OnDemandBaseCapacity)
• Runs 80% of any capacity above that base on Spot, 20% on On-Demand
• Uses price-capacity-optimized to balance interruption risk and cost
• Enables —capacity-rebalance so the ASG proactively replaces at-risk Spot Instances before they are terminated
• Tries 5 instance types so there are always fallback options if one pool is exhausted

Pair this with a well-tuned autoscaling policy to keep your fleet right-sized as load changes throughout the day.

When to use Spot Instances

Spot Instances work well when your workload is stateless or checkpointable, can retry failed units of work, and is not on the critical path for real-time user requests.

• Batch processing: ETL jobs, log processing, image and video transcoding, report generation. Each unit of work is independent. An interrupted instance just re-queues its items.
• CI/CD build runners: Jenkins workers, GitHub Actions runners, and similar agents that run a job and exit. A failed build retries. It is not a service outage.
• Stateless web tiers: API servers behind an Application Load Balancer. If an instance is interrupted, the load balancer stops routing to it and the ASG launches a replacement. With sufficient On-Demand base capacity, this is invisible to users.
• ML training and distributed data processing: Frameworks like PyTorch and TensorFlow support checkpointing, saving model state periodically so a job can resume from the last checkpoint after an interruption rather than starting from scratch.
• Dev and test environments: Non-critical environments that can tolerate a restart and do not need to be running around the clock.

When not to use Spot Instances

• Single-instance databases: A 2-minute notice is not long enough to safely flush and close a database. If you have no replica and the instance is terminated, that data is at risk. Do not run a primary database on Spot without robust replication and a tested failover plan.
• Tightly stateful systems: Applications that store state in memory or local disk without replication. Game servers with live sessions, single-node message brokers, and distributed locks will all lose that state when the instance is replaced.
• Latency-sensitive real-time workloads: If a sudden drain window of up to 2 minutes causes user-visible errors, or if your workload depends on a specific instance staying up, On-Demand is the right answer.
• Anything that cannot handle sudden replacement: Some software breaks when its host disappears mid-operation. Third-party SaaS agents, licence servers, and legacy applications with hard-coded hostnames are common examples. Test carefully before using Spot, and default to On-Demand when in doubt.

Spot vs On-Demand vs Reserved Instances and Savings Plans

There are four main ways to pay for EC2 compute. Each suits a different situation. See the AWS billing guide for a full breakdown of how charges appear in your bill.

In practice, most teams layer all four: Reserved Instances or Savings Plans for the steady-state baseline, On-Demand for variable headroom, and Spot for burst or batch capacity. This gives reliable capacity at a lower average cost than any single option alone.