Azure Spot Virtual Machines let you run workloads on Azure's spare compute capacity for a deeply reduced price, in exchange for accepting that the machine can be evicted when Azure needs that capacity back or the price moves past your limit. For interruption-tolerant workloads, the discount against pay-as-you-go rates is large, often in the range of 70 to 90 percent. The whole game is putting the right workloads on Spot and keeping everything that cannot tolerate eviction off it.
This article is part of our Azure cluster. Start with the complete guide to Azure cost optimization, the pillar this piece links up to. Spot is a Cut lever in our See, Cut, Lock, Run method: it changes the rate you pay for compute that does not need guaranteed uptime.
You give up guaranteed availability and get a large discount. Everything about using Spot well follows from that trade: design the workload so an eviction is a shrug rather than an incident, and Spot becomes nearly free money. Design it so an eviction loses work or takes down a user-facing service, and the discount is not worth it.
How eviction actually works
Azure evicts a Spot VM in one of two situations: capacity, when Azure needs the hardware back for pay-as-you-go demand, or price, when the current Spot price rises above the maximum price you set. You choose an eviction policy when you create the VM. Deallocate stops the machine and preserves the disk so you can restart it later when capacity returns, holding state but continuing to pay for the disk. Delete removes the machine entirely, which suits stateless fleet members that you would simply replace. Azure surfaces a short eviction notice through scheduled-event signals, giving the workload a brief window to checkpoint or drain before the machine goes away.
Which workloads belong on Spot
The fit comes down to one question: can this workload lose its compute at any moment without causing harm? When the answer is yes, Spot is a strong default.
- Batch and queue workers that pull jobs and can have a job re-queued if the worker disappears.
- CI and build agents where a failed run simply reruns.
- Dev and test environments that nobody depends on overnight.
- Big-data and rendering jobs that checkpoint progress and resume.
- Stateless scale-out tiers behind a load balancer where losing a node is invisible.
What does not belong on Spot: databases and stateful services, single points of failure, and anything user-facing without a guaranteed-capacity fallback. The discount never justifies an outage.
Sure which workloads can move to Spot?
Our Azure cost audit identifies the interruption-tolerant workloads in your estate, models the Spot saving against eviction risk, and designs the fallback so production never depends on capacity you do not control. On the performance model, you pay only from realized savings. No savings, no fee.
Book an Azure cost audit →Spot inside AKS and scale sets
Spot is most powerful when it is orchestrated rather than run as one-off VMs. In a Virtual Machine Scale Set you can run a Spot-backed set that scales out cheaply and tolerates nodes coming and going. In Azure Kubernetes Service you can add a Spot node pool and let the scheduler place interruption-tolerant pods there while keeping system and stateful pods on regular nodes. That split, cheap Spot capacity for the workloads that can take it and stable capacity for the workloads that cannot, is the pattern that captures the saving safely. We cover the cluster side in AKS cost optimization: node pools, Spot, and autoscaling.
Setting a maximum price, and why -1 is usually right
When you create a Spot VM you set a maximum price you are willing to pay per hour. Set it too low and the VM gets evicted on price more often than you want; set a value of -1 and you pay the current Spot price up to the pay-as-you-go rate, meaning you are only ever evicted for capacity reasons, never price. For most workloads, -1 is the sensible choice because it maximizes uptime while still capping the cost at the on-demand rate you would have paid anyway. A hard price cap only makes sense when you genuinely will not run the workload above a certain rate.
Spot is a rate lever, not a substitute for the others
Spot reduces the rate on flexible compute, but it does not replace the rest of the optimization stack. You still rightsize the machines so you are not running oversized Spot instances, and you still buy reservations or savings plans for the steady, must-run baseline that should never be on Spot. The strongest estates layer all three: commitments for the predictable core, Spot for the interruption-tolerant burst, and rightsizing underneath both. For where Spot sits against committed pricing, see Azure Reservations vs Azure Savings Plan for compute.
Eviction policies, the scheduled-event eviction signal, and the -1 maximum-price behavior described above reflect Azure Spot Virtual Machines as of May 2026. Verify current eviction behavior, supported VM sizes, and regional capacity in Azure documentation before moving production-adjacent workloads onto Spot, as these change.
The Azure Cost Optimization Field Guide includes the Spot suitability checklist and the eviction-handling patterns we deploy on engagements. It is the downloadable companion to this article.
The short version
Azure Spot VMs trade guaranteed availability for a discount of up to around 90 percent. Put batch, CI, dev and test, and stateless scale-out tiers on Spot; keep databases and user-facing single points of failure off it. Use a -1 maximum price to be evicted only on capacity, orchestrate Spot through scale sets and AKS node pools, and keep rightsizing and commitments working alongside it. To place Spot inside a full pass, follow how to run an Azure cost optimization assessment. When you want the Spot strategy designed and the fallbacks built so nothing breaks, that is exactly what our Azure cost optimization service delivers.