Azure Spot VMs: Up to 90% Savings for Interruptible Workloads

How Spot pricing and eviction work

Azure operates data centers with more physical capacity than the sum of all reserved and pay-as-you-go allocations. This surplus capacity is offered as Spot VMs at a steep discount. When Azure needs to reclaim that capacity — because regular demand increases — it evicts Spot VMs to make room.

Before eviction, Azure sends a 30-second warning via the Azure Instance Metadata Service (IMDS) endpoint available at 169.254.169.254 from inside the VM. Your application can poll this endpoint and react:

# Poll for eviction notice from inside the VM (run on the Spot VM itself)
curl -s -H "Metadata: true" \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

The eviction rate varies by VM size, region, and time of day. High-demand sizes in popular regions (D-series in East US at peak times) have higher eviction rates. Unusual sizes or off-peak regions are more stable. Azure does not publish exact eviction rate statistics, but the portal shows a rough eviction probability for each size and region when you configure a Spot VM.

Creating a Spot VM

# Create a Spot VM with Delete eviction policy
az vm create \
  --resource-group my-rg \
  --name my-spot-vm \
  --image Ubuntu2204 \
  --size Standard_D4s_v5 \
  --priority Spot \
  --eviction-policy Delete \
  --max-price -1 \
  --admin-username azureuser \
  --generate-ssh-keys

The key flags:

• —priority Spot — marks this as a Spot VM
• —eviction-policy Delete — deletes the VM and disk on eviction. Use Deallocate to preserve the disk.
• —max-price -1 — sets the maximum price you are willing to pay to the current Spot price, which changes dynamically. Setting -1 means you pay whatever the current Spot price is and are not evicted purely for exceeding a price cap. Azure can still evict for capacity reasons.

Spot VMs in Scale Sets

Spot VMs are most useful in Scale Sets, where the Scale Set can automatically replace evicted instances. When a Spot instance in a Scale Set is evicted, the autoscale engine detects the reduced instance count and provisions a new Spot instance — or falls back to pay-as-you-go if Spot capacity is not available, depending on your configuration.

# Create a Scale Set using Spot instances
az vmss create \
  --resource-group my-rg \
  --name my-spot-scale-set \
  --image Ubuntu2204 \
  --vm-sku Standard_D4s_v5 \
  --instance-count 3 \
  --priority Spot \
  --eviction-policy Delete \
  --max-price -1 \
  --zones 1 2 3 \
  --admin-username azureuser \
  --generate-ssh-keys

For critical batch workloads, configure a mixed-mode Scale Set that uses Spot instances as the primary pool but can fall back to regular instances. This is called a Spot priority mix and is configured through the Scale Set’s spot priority mixing policy — you specify what percentage of instances should be Spot vs regular when Spot capacity is unavailable.

Workload patterns that suit Spot

The eviction model limits Spot VMs to workloads that can tolerate interruptions:

Batch processing

Image processing, data transformation pipelines, log analysis — any job that can be broken into units of work, checkpointed, and resumed after interruption. Each batch job reads from a queue, processes, writes results to Blob Storage, and acknowledges completion. If the VM is evicted mid-job, the unacknowledged job returns to the queue and a new instance picks it up.

Machine learning training

Training jobs that checkpoint model state to Azure Blob Storage or Azure Files every N epochs. When the Spot VM is evicted, the next instance resumes training from the last checkpoint. Azure Machine Learning has native Spot VM support with automatic checkpointing for common training frameworks.

CI/CD build agents

Build jobs have a defined start and end. If a Spot VM is evicted mid-build, the build fails and is retried on a new instance. For most CI/CD systems, this means a delayed build rather than data loss. The cost savings on a large build agent fleet running 12 hours per day can be significant.

Dev/test environments

A developer environment that gets evicted can be restarted from a Spot VM snapshot or rebuilt from a custom image. The developer loses whatever they had in memory but keeps committed code. For exploration workloads where the developer is present and can restart quickly, the 90% cost reduction is compelling.

Designing for eviction

The two design patterns that make Spot VMs practical are checkpoint-and-resume and queue-based work distribution.

Checkpoint-and-resume: Your application writes progress to external storage (Blob Storage, a database, Azure Files) at regular intervals. On startup, it checks for an existing checkpoint and resumes from there. The 30-second eviction warning gives you time to flush the current checkpoint before the instance is deleted.

Queue-based work: Work items sit in a queue (Azure Storage Queue, Azure Service Bus). Workers dequeue an item, process it, then delete it from the queue when complete. The queue’s visibility timeout ensures that if a worker is evicted without acknowledging completion, the item becomes visible again and another worker picks it up.

Both patterns work together: queue-based work distribution means no task is lost when a VM is evicted, and periodic checkpointing means long-running tasks resume from a recent point rather than starting over.