Azure Spot VMs let you run on Azure's spare capacity at a price well below pay as you go, often a large discount, in exchange for one hard condition: Azure can evict the VM when it needs the capacity or when the price exceeds the maximum you set, giving only a short eviction notice of around 30 seconds. That trade makes Spot excellent for a specific class of work and dangerous for the rest. The work it fits is interruptible by design: batch processing, rendering, CI and build agents, big data and analytics jobs, machine learning training that checkpoints, and stateless workers behind a queue that can lose a node without losing the job. The work it does not fit is anything stateful or latency critical that cannot tolerate a sudden eviction: primary databases, single instance services, and synchronous user facing tiers with no fallback. The way to capture the saving safely is to architect for eviction from the start, run Spot inside scale sets with a fallback to standard capacity, spread across zones and instance types to lower the chance of a simultaneous reclaim, and checkpoint long jobs so an eviction costs minutes, not the whole run. The discount is real, but only the workloads that can shrug off an eviction get to keep it.
Here is how Spot pricing and eviction work, which workloads fit, and the patterns that make the saving safe to bank.
How do Azure Spot VMs price and evict?
Spot VMs run on Azure's unused capacity and are priced at a variable rate that sits well below the pay as you go rate for the same size, with the exact discount depending on the size, region, and current spare capacity, so treat any specific percentage as indicative and check the live Spot price. You set a maximum price you are willing to pay; if the Spot price rises above it, or if Azure simply needs the capacity back, the VM is evicted. You choose the eviction policy, either deallocate, which stops the VM and preserves the disk so you can restart later, or delete, which removes it entirely. The eviction notice is short, on the order of 30 seconds through scheduled events, which is enough to drain a queue worker or checkpoint a job but not enough to migrate a stateful service gracefully.
Which workloads fit Spot, and which do not?
The test is simple: can this workload lose a node at any moment without losing work or breaching a latency promise. If yes, it is a Spot candidate. Batch and ETL jobs, media rendering, CI and build fleets, analytics and big data processing, and machine learning training that writes checkpoints all qualify, as do stateless workers pulling from a durable queue. If no, keep it on standard or reserved capacity: primary and single instance databases, stateful services without replication, synchronous request tiers that users wait on, and anything with a hard latency SLA that an eviction would breach. A mixed system can still use Spot for the interruptible tier while the critical tier stays on standard capacity.
How do you architect for eviction?
Design so an eviction is a non event. Run Spot through Virtual Machine Scale Sets with a flexible orchestration and a fallback to standard priority VMs, so when Spot capacity disappears the scale set backfills with on demand instances and the service keeps running. Diversify across multiple instance sizes and across availability zones to reduce the odds that a single capacity reclaim takes all your nodes at once. Handle the scheduled events eviction signal to drain connections and checkpoint in the notice window. For long jobs, checkpoint frequently so an eviction costs the work since the last checkpoint rather than the entire run. With these in place, Spot becomes a discount with a known, bounded downside rather than a gamble.
How does Spot compare with reservations and burstable VMs?
Spot, Reservations, and burstable B series VMs solve different problems and often combine. Reservations and the Azure Savings Plan discount steady, predictable capacity in exchange for a commitment and are the right tool for your always on base. Spot discounts interruptible capacity with no commitment but with eviction risk, and is the right tool for the elastic, fault tolerant layer above that base. Burstable B series VMs suit low average load with occasional spikes by banking CPU credits. A well built estate uses commitments for the bedrock, Spot for the interruptible elastic layer, and burstable sizes for spiky low utilisation services, rather than forcing one instrument to do every job. The sibling note on scale sets and autoscaling for cost, linked below, shows how the elastic layer is wired.
What is the realistic saving and the realistic risk?
The saving on the interruptible portion of an estate can be large, because the Spot discount to pay as you go is steep, but the saving only applies to the workloads you can safely run there, so the estate level impact depends on how much of your compute is genuinely interruptible. The risk is operational, not financial: an estate that puts the wrong workload on Spot trades a discount for an outage and a postmortem. Measure the interruptible share honestly, put only that share on Spot with proper fallback, and the result is a durable reduction on that slice with the critical path untouched.
A worked example
A European SaaS company ran a nightly analytics pipeline and a CI fleet on standard priority VMs and assumed the cost was unavoidable. Both workloads were interruptible: the pipeline checkpointed between stages and the CI jobs could rerun. Moving them to Azure Spot VMs inside scale sets, diversified across zones and sizes with a fallback to standard priority, cut the cost of that compute steeply while a handful of evictions over the first month cost only minutes of rerun thanks to checkpointing. The latency critical application tier stayed on reserved capacity untouched. Figures are verified against billing data and anonymised.
Frequently asked questions
How much do Azure Spot VMs save?
What happens when an Azure Spot VM is evicted?
Which workloads should not run on Azure Spot?
Capture the Spot discount safely
We help Azure teams measure the genuinely interruptible share of their estate, move it to Spot with proper fallback and checkpointing, and keep the critical path on the right committed capacity, across AWS, Azure, GCP, and OCI. We take zero provider commissions and answer only to you, on a Fixed Fee or a no risk Gainshare basis, with a simple guarantee: we reduce your cloud spend or we reimburse our service fee. Download the compute playbook, and read the full Azure method below.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.