Spot Instances for Cost Savings in AWS

What Spot Instances are

AWS operates large fleets of EC2 instances. At any given time, a portion of that capacity is unused — instances that are provisioned and available but not currently allocated to any customer. Spot Instances let you bid for and use that spare capacity at a fraction of the On-Demand price.

The pricing is determined by supply and demand within each instance type, size, and Availability Zone combination (called a Spot pool). When spare capacity is plentiful, Spot prices drop. When demand spikes, prices rise. Historically, most Spot prices have been stable, and many pools offer consistent 60–90% discounts over On-Demand.

The trade-off: AWS can reclaim a Spot Instance with a two-minute warning when they need the capacity back. Your application must be designed to handle this gracefully.

Real cost comparison

r5.xlarge in us-east-1 (memory-optimised, 4 vCPU, 32GB RAM):

• On-Demand: $0.252/hour = $184/month (continuous)
• Spot (recent typical price): ~$0.075/hour = $55/month

For a batch processing job that runs continuously across 10 instances:

• On-Demand: 10 × $184 = $1,840/month
• Spot: 10 × $55 = $550/month
• Monthly saving: $1,290

Over a year: $15,480 saved on a single workload.

For a CI/CD build farm running 20 c5.2xlarge build runners:

• On-Demand: 20 × $0.34/hr × 730hr = $4,964/month
• Spot (~$0.10/hr): 20 × $0.10 × 730hr = $1,460/month
• Saving: $3,504/month

CI/CD build jobs are almost ideal for Spot: they’re short-lived, self-contained, and interruption just means the build retries on a new instance.

Workloads that work well on Spot

Batch processing — data transformation, ETL pipelines, analytics jobs. If interrupted, restart from the last checkpoint. S3 or DynamoDB checkpointing makes this straightforward.

CI/CD build and test runners — a failed build just triggers a retry. GitHub Actions, GitLab CI, and Jenkins all support Spot-based runners through configuration or plugins.

Stateless web tier — an Auto Scaling Group with mixed On-Demand and Spot instances. The load balancer distributes traffic; a Spot interruption removes one node and traffic shifts to others. Maintain a minimum On-Demand base (e.g., 2 On-Demand + N Spot) to ensure some capacity survives simultaneous interruptions.

Machine learning training — most modern ML frameworks support checkpointing. PyTorch Lightning, TensorFlow, and SageMaker all support saving training state periodically so a Spot interruption restarts from the last checkpoint rather than the beginning.

HPC and simulation workloads — scientific computing, financial modelling, rendering. Jobs that can be decomposed into independent chunks work well; each chunk runs independently and a lost chunk is retried.

Workloads that should not run on Spot

Databases — a Spot interruption on a primary database node risks data corruption or data loss, and at minimum causes downtime. Production databases should always run On-Demand or on Reserved Instances.

Long-running stateful processes without checkpointing — a 48-hour simulation with no checkpoints that gets interrupted at hour 47 loses all 47 hours of work. Only use Spot for long-running jobs if you can checkpoint frequently.

Control plane infrastructure — Kubernetes masters, etcd nodes, NAT Gateways, bastion hosts. These need to be stable and available. Put them on On-Demand.

Services with strict SLAs and no redundancy — if you have a single-instance service with an SLA commitment and no failover, Spot interruption violates that SLA. Add redundancy first, then move to Spot.

Handling Spot interruptions gracefully

When AWS decides to reclaim a Spot Instance, it posts an interruption notice two minutes before termination. You can receive this notice in two ways:

Instance Metadata Service (IMDS):

# Poll this from within the instance
curl http://169.254.169.254/latest/meta-data/spot/interruption-action
# Returns "terminate" when interruption notice is issued

EventBridge (formerly CloudWatch Events): AWS automatically fires a EC2 Spot Instance Interruption Warning event. You can create an EventBridge rule to trigger a Lambda that:

• Deregisters the instance from the load balancer (allowing in-flight requests to complete)
• Sends a signal to the application to stop accepting new work
• Saves a checkpoint
• Sends an alert

For a well-designed Spot workload, the two-minute window is enough to drain connections and checkpoint state. The key is implementing this handling in advance, not waiting until an interruption happens in production.

Instance type diversification

The reliability of Spot depends on having options. If you request only m5.large Spot in a single AZ, you’re at the mercy of that one pool. When it’s unavailable or expensive, you have no fallback.

Spot best practice: request across multiple instance types and AZs.

Instances with similar vCPU and memory profiles are interchangeable for most workloads. For an m5.large equivalent, you could diversify across:

• m5.large, m5a.large, m5n.large, m4.large
• m6i.large, m6a.large
• In multiple AZs (us-east-1a, us-east-1b, us-east-1c)

With 3 instance types × 3 AZs = 9 Spot pools. The chance of all 9 pools being simultaneously unavailable is very low.

Auto Scaling Groups support this with the mixed instances policy:

{
  "MixedInstancesPolicy": {
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "capacity-optimized"
    },
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateId": "lt-1234567890abcdef0"
      },
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5a.large"},
        {"InstanceType": "m6i.large"},
        {"InstanceType": "m5n.large"}
      ]
    }
  }
}

The OnDemandBaseCapacity: 2 ensures 2 On-Demand instances always run. Above that, 80% Spot and 20% On-Demand. The capacity-optimized allocation strategy picks the Spot pool with the most available capacity — generally correlated with lower interruption rates.

See Auto Scaling Groups for more on configuring mixed-instance fleets.

Spot Fleet for managed instance fleets

EC2 Spot Fleet is an alternative to Auto Scaling Groups for managing Spot fleets. You specify a target capacity (in units you define, e.g., vCPUs) and a list of instance types and weights. Spot Fleet maintains the target capacity by requesting instances across the pools you specify.

Spot Fleet is useful for batch workloads that need a fixed amount of compute capacity without the dynamic scaling behaviour of Auto Scaling Groups. For most web-tier use cases, Auto Scaling Groups with mixed instances policy are the preferred approach.

Using the Spot Instance Advisor

The AWS Spot Instance Advisor (available at aws.amazon.com/ec2/spot/instance-advisor/) shows interruption frequency and savings for each instance type, size, and region combination.

The interruption frequency is categorised as:

• Less than 5% — very low risk
• 5–10%
• 10–15%
• 15–20%
• Greater than 20%

For production Spot usage, prefer instance types with less than 5% interruption frequency. For batch workloads where interruptions just mean a retry, higher interruption rates are acceptable because the per-hour cost is lower.

Check the Spot Advisor when selecting instance types — some newer generation types have very low interruption rates and the same or better performance than older types.