How to Use AWS Spot Instances to Cut Compute Costs

AWS Spot Instances offer the same EC2 instance types at discounts of 50-90% compared to On-Demand pricing, with a single trade-off: AWS can reclaim capacity with two minutes notice when demand from On-Demand customers exceeds available supply. For workloads designed to handle interruptions—batch processing, stateless web services with redundancy, CI/CD pipelines, data processing—this trade-off is trivial. The cost savings are transformational, turning workloads that cost thousands per month into hundreds.

Most teams avoid Spot Instances because they assume interruption risk makes them unsuitable for production workloads. This assumption is outdated. Modern Spot Instance best practices, AWS's capacity allocation improvements, and tooling like Spot Instance interruption handling in Auto Scaling Groups make Spot viable for a far wider range of workloads than most engineers realize. Production web services, real-time data processing, and long-running tasks all run successfully on Spot with proper architecture.

This guide covers how Spot Instance pricing and interruption actually works, which workload patterns benefit most from Spot, and concrete implementation patterns using Auto Scaling Groups, Spot Fleets, and EKS managed node groups. You'll learn how to handle interruptions gracefully, how to diversify instance types to reduce interruption frequency, and how to measure actual cost savings versus theoretical maximums.

Understanding Spot Instance Pricing and Interruption

Spot Instance 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. When capacity tightens, Spot prices rise. If Spot price exceeds your maximum bid price or AWS needs capacity for On-Demand customers, your instance gets interrupted.

The critical misconception: Spot interruptions aren't random or frequent for most instance types. Interruption rates vary dramatically by instance type, region, and time. A c5.large instance in us-east-1a might have 5% monthly interruption rate while a c5.24xlarge in the same zone has 0.5% interruption rate. Larger instances experience fewer interruptions because fewer customers request them, meaning less competition for capacity.

AWS provides two minutes warning before interruption via CloudWatch Events and instance metadata. This warning is sufficient to gracefully shutdown most workloads: drain connections from a web server, checkpoint a batch processing job, or save work-in-progress to S3. Workloads that handle this two-minute warning properly experience interruption as a minor inconvenience, not a catastrophic failure.

Workload Patterns Ideal for Spot Instances

Spot Instances work best for workloads with specific characteristics: fault-tolerant (can handle interruption), flexible (can run on multiple instance types), and time-flexible (can be delayed or paused if needed). Understanding where your workloads fit on these dimensions determines which should run on Spot.

Batch Processing and Data Analytics

Batch jobs that process data in discrete chunks are ideal Spot candidates. Each chunk can complete independently, and interrupted jobs simply resume processing remaining chunks. AWS Batch, EMR, and custom batch processing systems all support Spot with minimal configuration changes.

For data processing with Apache Spark on EMR, configure core nodes as On-Demand (to maintain HDFS data) and task nodes as Spot (for compute only). Task node interruptions don't lose data—Spark automatically reschedules work to remaining nodes. A typical EMR cluster with 1 master node (On-Demand), 2 core nodes (On-Demand), and 10 task nodes (Spot) costs approximately 60-70% less than an all On-Demand cluster while maintaining the same processing capability.

Machine learning training workloads benefit enormously from Spot. Training jobs that checkpoint progress to S3 every N minutes can resume from the last checkpoint if interrupted. SageMaker supports managed Spot training that automatically handles interruptions and resumes training on new capacity. For GPU-intensive training that would cost $500/day on p3.8xlarge On-Demand instances, Spot pricing averages $100-150/day—a savings of $250-400 daily.

CI/CD Build Agents

Build agents are nearly perfect for Spot. Builds are stateless, time-flexible (a 2-minute delay before starting a build is acceptable), and fault-tolerant (interrupted builds simply retry). Configure your CI/CD system with a pool of Spot instances supplemented by a small number of On-Demand instances for fallback.

For GitHub Actions self-hosted runners, deploy an Auto Scaling Group with Spot instances. When a Spot interruption occurs, the build agent receives the termination notice, marks itself as offline, and the build queues to another available agent. The interruption is invisible to developers—they see a build that takes slightly longer to start, not a failed build.

Jenkins supports Spot through the EC2 Fleet plugin, which manages a mixed fleet of On-Demand and Spot agents. Configure the fleet to maintain a minimum number of On-Demand agents for immediate availability and scale up with Spot agents under load. For a team running 500 builds per day that previously cost $800/month on On-Demand instances, switching to 80% Spot coverage typically reduces costs to $250-350/month.

Stateless Web Services with Auto Scaling

Web services that maintain no local state and run behind load balancers work well on Spot when configured for graceful interruption handling. The application must handle connection draining and health check failures smoothly, but most modern web frameworks support this by default.

Deploy web services using Auto Scaling Groups configured with multiple Spot capacity pools (different instance types). When an instance receives termination notice, it deregisters from the load balancer and stops accepting new connections while completing in-flight requests. The load balancer routes new traffic to remaining healthy instances. From the user perspective, nothing changes—requests continue succeeding without interruption.

A production API serving 10,000 requests per minute can run on a mixed fleet of 20% On-Demand instances (for baseline capacity that's never interrupted) and 80% Spot instances (for cost-efficient scaling). This configuration maintains service availability while reducing compute costs by 40-60% compared to all On-Demand.

Implementing Spot Instances with Auto Scaling Groups

Auto Scaling Groups provide the most reliable way to manage Spot Instances for most workloads. ASG Spot best practices revolve around diversifying across multiple instance types and availability zones to minimize interruption risk.

Create a launch template with multiple instance types that have similar performance characteristics. Instead of requesting only c5.2xlarge Spot instances, request c5.2xlarge, c5a.2xlarge, c5n.2xlarge, and c5d.2xlarge. These instances deliver equivalent compute performance with different underlying hardware, meaning they have independent interruption patterns. If one type experiences high demand and interruptions, others likely remain available.

{
  "LaunchTemplate": {
    "LaunchTemplateName": "spot-web-service",
    "VersionDescription": "Multi-instance Spot template",
    "LaunchTemplateData": {
      "ImageId": "ami-0c55b159cbfafe1f0",
      "InstanceType": "c5.2xlarge",
      "SecurityGroupIds": ["sg-0123456789abcdef0"],
      "IamInstanceProfile": {"Arn": "arn:aws:iam::123456789012:instance-profile/web-service"},
      "UserData": "IyEvYmluL2Jhc2gKL29wdC9hcHAvc3RhcnQuc2g="
    }
  }
}

Configure the Auto Scaling Group with a MixedInstancesPolicy that specifies instance type weights and allocation strategy:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name spot-web-asg \
  --min-size 4 \
  --max-size 20 \
  --desired-capacity 8 \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-tg/abc123 \
  --vpc-zone-identifier "subnet-abc123,subnet-def456,subnet-ghi789" \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "spot-web-service",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "c5.2xlarge"},
        {"InstanceType": "c5a.2xlarge"},
        {"InstanceType": "c5n.2xlarge"},
        {"InstanceType": "c5d.2xlarge"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 0,
      "SpotAllocationStrategy": "capacity-optimized"
    }
  }'

This configuration maintains 2 On-Demand instances as guaranteed baseline capacity and scales with Spot instances. The capacity-optimized allocation strategy selects Spot pools with the most available capacity, minimizing interruption likelihood. This is superior to the older lowest-price strategy which often selected marginal capacity pools with high interruption rates.

Handling Spot Interruptions Gracefully

Configure instances to monitor for Spot interruption notices and execute graceful shutdown procedures. The interruption notice appears in instance metadata at http://169.254.169.254/latest/meta-data/spot/instance-action 120 seconds before termination.

Implement a monitoring script that polls this endpoint every few seconds and triggers shutdown procedures when interruption is detected:

#!/bin/bash
while true; do
  NOTICE=$(curl -s http://169.254.169.254/latest/meta-data/spot/instance-action)

  if [ -n "$NOTICE" ]; then
    echo "Spot interruption notice received"

    # Deregister from load balancer
    INSTANCE_ID=$(ec2-metadata --instance-id | cut -d ' ' -f 2)
    aws elbv2 deregister-targets --target-group-arn $TG_ARN \
      --targets Id=$INSTANCE_ID

    # Wait for connection draining (max 120 seconds)
    sleep 30

    # Stop accepting new work
    kill -TERM $(cat /var/run/app.pid)

    # Exit
    break
  fi

  sleep 5
done

Deploy this script as a background service that runs continuously on Spot instances. When interruption is detected, it gracefully removes the instance from service before AWS terminates it. This prevents user-facing errors from abrupt termination.

Using Spot Fleets for Advanced Capacity Management

EC2 Spot Fleet provides more sophisticated capacity management than Auto Scaling Groups, with support for complex allocation strategies, heterogeneous instance types with different performance characteristics, and fine-grained cost optimization.

Spot Fleet works by defining target capacity in terms of units—you can specify that a c5.large equals 1 unit, c5.xlarge equals 2 units, and c5.2xlarge equals 4 units. The fleet maintains your target unit count by launching appropriate combinations of instance types based on current Spot pricing and availability.

This is valuable when instance types have meaningfully different performance. For data processing workloads, memory-intensive tasks might run best on r5 instances while compute-intensive tasks prefer c5 instances. Spot Fleet can maintain a heterogeneous mix, selecting optimal instance types based on current Spot market conditions.

{
  "SpotFleetRequestConfig": {
    "IamFleetRole": "arn:aws:iam::123456789012:role/spot-fleet-role",
    "TargetCapacity": 100,
    "SpotPrice": "0.50",
    "AllocationStrategy": "diversified",
    "LaunchSpecifications": [
      {
        "ImageId": "ami-0c55b159cbfafe1f0",
        "InstanceType": "c5.2xlarge",
        "KeyName": "my-key",
        "WeightedCapacity": 4,
        "SpotPrice": "0.20"
      },
      {
        "ImageId": "ami-0c55b159cbfafe1f0",
        "InstanceType": "c5.xlarge",
        "KeyName": "my-key",
        "WeightedCapacity": 2,
        "SpotPrice": "0.10"
      },
      {
        "ImageId": "ami-0c55b159cbfafe1f0",
        "InstanceType": "c5.large",
        "KeyName": "my-key",
        "WeightedCapacity": 1,
        "SpotPrice": "0.05"
      }
    ]
  }
}

The diversified allocation strategy spreads capacity across all specified pools, reducing interruption risk. If you request 100 units of capacity, Spot Fleet might launch a mix of 5 c5.2xlarge (20 units), 10 c5.xlarge (20 units), and 60 c5.large (60 units), distributing risk across multiple instance types.

Spot Fleet's primary advantage over Auto Scaling Groups is handling heterogeneous workloads. Its main disadvantage is less tight integration with Application Load Balancers and less automatic lifecycle management. For most web services and applications, Auto Scaling Groups remain simpler and sufficient. For complex batch processing or data analytics workloads with variable performance requirements, Spot Fleet provides valuable flexibility.

Spot Instances on Amazon EKS

Kubernetes on Amazon EKS supports Spot Instances through managed node groups or self-managed node groups configured with Spot. The Kubernetes scheduler automatically handles pod rescheduling when nodes terminate, making EKS particularly well-suited for Spot.

Create a managed node group configured for Spot instances:

aws eks create-nodegroup \
  --cluster-name production-cluster \
  --nodegroup-name spot-workers \
  --subnets subnet-abc123 subnet-def456 subnet-ghi789 \
  --instance-types c5.2xlarge c5a.2xlarge c5n.2xlarge \
  --capacity-type SPOT \
  --scaling-config minSize=3,maxSize=20,desiredSize=6 \
  --disk-size 100

This creates a node group that exclusively uses Spot instances, diversified across multiple instance types for reliability. EKS automatically configures appropriate taints and labels so you can target pods to Spot nodes selectively.

Configuring Workloads for Spot Nodes

Not all Kubernetes workloads should run on Spot. Stateful applications, critical system services, and pods that can't tolerate interruption should run on On-Demand nodes. Stateless applications, batch jobs, and scalable services work well on Spot.

Use node affinity and tolerations to control pod scheduling. For workloads that can run on Spot:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-service
spec:
  replicas: 10
  template:
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: eks.amazonaws.com/capacityType
                operator: In
                values:
                - SPOT
      tolerations:
      - key: "eks.amazonaws.com/capacityType"
        operator: "Equal"
        value: "SPOT"
        effect: "NoSchedule"
      containers:
      - name: web-service
        image: web-service:v1.0

This configuration prefers Spot nodes but allows scheduling on On-Demand nodes if Spot capacity is unavailable. For critical workloads that must never run on Spot, use requiredDuringSchedulingIgnoredDuringExecution with nodeAffinity selecting only SPOT nodes, then invert the logic for On-Demand requirement.

Handling Node Termination with AWS Node Termination Handler

AWS Node Termination Handler is a DaemonSet that monitors for Spot interruption notices and gracefully drains nodes before termination. When termination is detected, it cordons the node (prevents new pod scheduling), drains existing pods (allowing them to reschedule to other nodes), and ensures the node shuts down cleanly.

Install with Helm:

helm repo add eks https://aws.github.io/eks-charts
helm install aws-node-termination-handler \
  --namespace kube-system \
  eks/aws-node-termination-handler \
  --set enableSpotInterruptionDraining=true

With the termination handler, Spot interruptions become nearly invisible. Pods reschedule to available nodes within seconds, maintaining service availability. For a cluster with 50% Spot nodes, you might experience one Spot interruption per week affecting 1-2 nodes, with zero user-facing impact due to automatic pod rescheduling.

Measuring and Optimizing Spot Savings

Theoretical Spot savings of 70-90% rarely match actual savings due to interruption management overhead, need for On-Demand baseline capacity, and instance type availability constraints. Measure actual savings to understand real ROI.

Calculate effective cost per hour for your Spot fleet accounting for both Spot instance hours and fallback On-Demand hours:

Effective Cost = (Spot Hours × Spot Rate + OnDemand Hours × OnDemand Rate) / Total Hours

For example, if you run a service averaging 1000 instance-hours per month, 850 on Spot at $0.08/hour and 150 on On-Demand at $0.40/hour:

Effective Cost = (850 × $0.08 + 150 × $0.40) / 1000 = ($68 + $60) / 1000 = $0.128/hour

Compared to pure On-Demand ($0.40/hour), this represents 68% savings. Not the theoretical 80% (if 100% Spot), but still substantial. The 150 On-Demand hours provide reliability that makes the overall solution production-viable.

Using AWS Cost Explorer for Spot Analysis

AWS Cost Explorer can filter costs by purchase option (On-Demand vs Spot), showing exact spending breakdown. Navigate to Cost Explorer → Service: EC2-Instances → Purchase Option filter, and compare Spot vs On-Demand spending over time.

Track these metrics monthly:

• Spot percentage: hours run on Spot vs total hours
• Effective savings rate: percentage saved vs pure On-Demand
• Interruption rate: Spot interruptions per 1000 instance-hours
• Fallback frequency: times workloads failed over to On-Demand due to Spot unavailability

A well-optimized Spot implementation achieves 70-85% Spot coverage with 60-70% cost savings and interruption rates below 5% monthly. If your Spot coverage is below 50%, investigate instance type diversification and allocation strategies. If interruption rates exceed 10%, you're likely using high-demand instance types—diversify to larger or less popular types.

Advanced Patterns: Spot for Long-Running Tasks

Long-running tasks like multi-hour data processing jobs or machine learning training traditionally seem incompatible with Spot due to interruption risk. Modern checkpointing strategies make Spot viable even for tasks requiring days to complete.

Implement regular checkpointing: save job state to S3 or EFS every 5-15 minutes. When interruption notice arrives, perform one final checkpoint, save state, and shut down gracefully. When the job restarts (automatically via Auto Scaling Group replacement or manually), it loads the last checkpoint and continues from that point.

For PyTorch training jobs:

import torch
import boto3
import time

s3 = boto3.client('s3')

def save_checkpoint(model, optimizer, epoch, checkpoint_path):
    torch.save({
        'epoch': epoch,
        'model_state': model.state_dict(),
        'optimizer_state': optimizer.state_dict()
    }, checkpoint_path)

    # Upload to S3
    s3.upload_file(checkpoint_path, 'my-checkpoints', f'checkpoint_{epoch}.pt')

def load_checkpoint(checkpoint_path):
    if os.path.exists(checkpoint_path):
        checkpoint = torch.load(checkpoint_path)
        return checkpoint['epoch'], checkpoint['model_state'], checkpoint['optimizer_state']
    return 0, None, None

# Training loop
for epoch in range(start_epoch, num_epochs):
    train_model(model, dataloader, optimizer)

    if epoch % 5 == 0:  # Checkpoint every 5 epochs
        save_checkpoint(model, optimizer, epoch, 'checkpoint_latest.pt')

    # Check for Spot interruption
    if check_spot_interruption():
        save_checkpoint(model, optimizer, epoch, 'checkpoint_latest.pt')
        break

This pattern works for any long-running task with serializeable state. The overhead of frequent checkpointing (typically 1-5% of total runtime) is negligible compared to 70-80% cost savings from Spot.

Combining Spot with Reserved Instances and Savings Plans

Spot, Reserved Instances, and Savings Plans aren't mutually exclusive—they complement each other for comprehensive cost optimization. Use Reserved Instances or Compute Savings Plans for baseline capacity you'll run continuously, then scale variable workloads with Spot.

A typical optimization strategy for a web service with variable traffic:

• Purchase Compute Savings Plans covering baseline capacity (minimum instance count during lowest traffic periods)
• Scale with On-Demand instances for predictable daily/weekly traffic patterns not covered by commitments
• Scale further with Spot instances for cost-efficient handling of traffic spikes and unpredictable load

This three-tier strategy minimizes costs: Savings Plans provide 40-65% discounts on baseline, On-Demand handles predictable variation without commitment risk, and Spot captures 70-90% savings on variable load. The combined savings often reach 50-60% versus pure On-Demand, higher than any single strategy alone.

Spot Instance Best Practices Summary

Successful Spot adoption requires following specific patterns that maximize savings while maintaining reliability:

Frequently Asked Questions

What's the typical interruption rate for Spot Instances?

Interruption rates vary significantly by instance type and region, but AWS publishes historical data showing that most instance types in most regions experience less than 5% monthly interruption rate. Larger instance sizes (8xlarge, 16xlarge, 24xlarge) typically see interruption rates below 1% because fewer customers compete for that capacity. Smaller sizes (large, xlarge) in popular types like c5 or m5 may see 5-15% interruption rates during high-demand periods. The key: diversification across instance types reduces your effective interruption rate to well below any single type's rate.

Can I run production workloads on Spot Instances safely?

Yes, with proper architecture. Stateless web services behind load balancers, containerized microservices with redundancy, and batch processing systems all run successfully on Spot in production. The requirements: multiple instances providing redundancy so individual interruptions don't impact service, graceful interruption handling to prevent user-facing errors, and appropriate fallback to On-Demand capacity when Spot is unavailable. What doesn't work: single-instance deployments without redundancy, stateful applications without replication, or services that can't tolerate any instance failure.

How much do I actually save with Spot Instances?

Theoretical maximum is 90% but realistic savings range from 50-75% depending on workload characteristics and required On-Demand baseline. Workloads that can run 90%+ on Spot with minimal fallback achieve 70-75% savings. Workloads requiring 20-30% On-Demand baseline for reliability achieve 50-60% savings. Calculate expected savings based on your anticipated Spot percentage and average Spot discount for your instance types (check AWS pricing pages for current Spot rates vs On-Demand).

What happens to my data when a Spot Instance is interrupted?

EBS volumes attached to Spot Instances persist through interruption by default unless you configure otherwise. When an instance is interrupted, the root volume and attached EBS volumes stop being accessible but aren't deleted. If you launch a new instance and attach the same EBS volume, your data is intact. For true ephemeral storage (instance store volumes), data is lost at interruption. Design Spot workloads to store persistent data on EBS, EFS, or S3, not instance store or in-memory only.

Should I use Spot Instances for databases?

Use Spot for read replicas, not primary databases. A primary database on Spot creates availability risk not worth the cost savings—use RDS or EC2 On-Demand with proper backups. For read replicas in multi-replica setups, Spot works well: configure 2-3 On-Demand read replicas for guaranteed capacity and add 2-5 Spot read replicas for cost-efficient read scaling. If Spot replicas get interrupted, read traffic shifts to On-Demand replicas without impact. The cost savings on read scaling offset the On-Demand costs for primary and core replicas.

How do I choose which instance types to include in my Spot diversification?

Select instance types with similar performance characteristics (same vCPU and memory ratios) from different families. For compute-optimized workloads, mix c5, c5a, c5n, and c6i instances of the same size. For general purpose, mix m5, m5a, m5n, and m6i. Include both current and previous generation types if your workload doesn't require latest-gen features. The broader your type diversity within performance equivalence, the lower your interruption risk. Use 4-6 instance types minimum for production workloads.

Can I use Spot Instances with Elastic Load Balancers?

Yes, Spot Instances work seamlessly with Application Load Balancers and Network Load Balancers. Register Spot instances in target groups exactly like On-Demand instances. Implement proper health checks and connection draining (deregistration delay of 30-300 seconds), and the load balancer handles Spot interruptions gracefully—it stops sending new traffic to interrupted instances once they become unhealthy and drains existing connections before termination. Users experience no errors or downtime from Spot interruptions when configured correctly.

What's the difference between Spot Instances and Spot Fleet?

Spot Instances are individual instance requests. Spot Fleet is a higher-level construct that manages a collection of Spot and On-Demand instances to meet target capacity, with sophisticated allocation strategies and automatic replacement of interrupted instances. For most use cases, Auto Scaling Groups with mixed instances policies (supporting both Spot and On-Demand) provide better integration with load balancers and AWS services than Spot Fleet. Use Spot Fleet when you need its specific features like weighted capacity for heterogeneous instance types or when not using Auto Scaling Group integration.

How do I monitor Spot Instance interruptions and costs?

Use CloudWatch Events to track interruption notices in real-time. Create an EventBridge rule matching "EC2 Spot Instance Interruption Warning" events and route to SNS, Lambda, or your monitoring system for alerting. For cost tracking, use AWS Cost Explorer filtering by purchase option (Spot vs On-Demand) to see spending breakdown. Create CloudWatch dashboards showing Spot percentage, effective cost per hour, and interruption frequency. Track these metrics weekly initially to validate your Spot implementation is working as expected.

Conclusion

AWS Spot Instances deliver 50-75% cost savings for workloads architected to handle interruptions gracefully. The modern Spot pricing model, two-minute termination warnings, and tooling like Auto Scaling Group capacity-optimized allocation make Spot viable for a far wider range of production workloads than most teams realize. Stateless web services, containerized applications, batch processing, and CI/CD pipelines all run successfully on Spot with minimal additional complexity.

Success with Spot requires following specific patterns: diversify across multiple instance types to reduce interruption risk, implement graceful shutdown handling to prevent user-facing errors, maintain a small On-Demand baseline for guaranteed capacity, and use capacity-optimized allocation strategies. These practices transform Spot from a risky cost-cutting measure into a reliable production infrastructure component.

Start with non-critical workloads to build confidence and operational patterns, measure actual savings and interruption rates, then expand Spot coverage to additional workloads as you validate the approach. For most engineering teams, Spot can reduce compute costs by 40-60% while maintaining the reliability and performance your applications require.