Spot VMs: when to use them

Start with interruption, not the discount

Spot VMs are useful when the workload can survive interruption. Azure can evict the VM when it needs the capacity back, and Spot does not provide the same availability guarantee as standard capacity. That is the whole bargain: lower compute price in exchange for uncertainty.

The strongest Spot candidates are not defined by industry or technology stack. They are defined by behaviour. The work can be retried, split into smaller units, recreated from code, or picked up by another worker. If eviction creates a customer outage, data loss, manual cleanup, or a long restart, the discount is probably hiding more risk than it removes.

• Spot can reduce cost for work that is fault-tolerant, stateless, or easy to restart.
• Eviction is not an exception to plan around later; it is the central design condition.
• A 30-second eviction notice can help graceful shutdown, but it should not be the only protection.
• Deallocate and Delete policies suit different operating models and cost expectations.
• Spot works best as part of a mixed capacity model, not as the only capacity behind a critical service.

What Spot VMs actually trade

Spot uses unused Azure capacity. When Azure needs that capacity back, the VM can be evicted. The platform can send a Scheduled Events notification with about 30 seconds of notice, which gives the workload a short window to stop accepting work, save progress, release locks, or signal an orchestrator. That notice is useful, but it is not the same as a long maintenance window.

The eviction policy shapes what happens next. With Deallocate, the VM is stopped and the attached disks remain. Compute billing stops, but storage remains. With Delete, the VM and OS disk are removed, which fits more ephemeral patterns where the environment can be recreated and no important state lives on the VM.

Spot should be planned as a separate capacity pattern, not as a discount toggle on an existing VM. Regular VMs and Spot VMs are not something to casually convert back and forth during production operations, so the decision belongs in workload design, scaling strategy, and recovery planning.

• Capacity eviction happens when Azure needs the unused capacity back.
• Price eviction can happen when the Spot price exceeds the maximum price configured for the VM.
• Setting max price to -1 avoids price-based eviction, but capacity eviction can still happen. A custom max price can add price eviction risk if the Spot price rises above it.
• Spot pricing and eviction rates vary by region, VM size, and available capacity.
• Eviction history and price history are planning signals, not availability guarantees.

Where Spot is a strong fit

Spot works best where work can be divided, retried, or reassigned without damaging the result. The business value is not only a lower VM price. It is the ability to run elastic compute cheaply because the workload already has a way to handle interruption.

• Batch processing, data transformation, and analytics jobs where work can be split into tasks and resumed from checkpoints.
• CI/CD runners and build agents where failed jobs can be retried and agents are naturally disposable.
• Rendering, encoding, image processing, and simulation workloads where independent units of work can return to a queue.
• Development and test environments where interruption does not affect customers and the productivity cost of restart is acceptable.
• Worker fleets behind a queue where another instance can pick up unfinished work after eviction.

Azure Batch and Virtual Machine Scale Sets are common patterns because they can treat workers as replaceable capacity. In mature designs, a worker does not hold business-critical state. The queue, checkpoint, or orchestrator carries the work state and recovery path, and the VM is only one temporary place where work happens.

Where Spot becomes a risk

Spot becomes dangerous when the VM carries responsibility that cannot be interrupted. That can be local state, customer-facing availability, critical control-plane services, or long-running work that cannot resume from a checkpoint. In those cases, eviction turns a discount into an outage.

A workload can be technically non-critical and still be a poor Spot candidate if eviction creates too much manual work. Lost build agents, half-finished jobs, stale locks, corrupted local output, or queues full of duplicate work can erase the financial benefit quickly.

Designing for eviction

Good Spot design assumes eviction will happen. The purpose is not to predict every eviction perfectly. It is to make interruption boring: stop taking new work, preserve enough progress, let unfinished tasks return to a queue, and recreate capacity when the pool is available again.

• Checkpointing reduces the amount of work lost when a VM disappears.
• Queue-based distribution lets another worker take over unfinished work.
• Idempotent processing makes retries safe when the same task runs more than once.
• Stateless images and infrastructure definitions make replacement faster and cleaner.
• Scheduled Events handling gives the workload a short best-effort window for graceful shutdown.
• Post-eviction monitoring shows whether Spot is saving money or simply causing too many restarts.

Where Spot fits in the capacity mix

Spot is one pricing model inside a wider capacity strategy. It should be compared with reservations and pay-as-you-go based on workload stability, interruption tolerance, and the maturity of the operating model. Many estates need all three.

The clean pattern is separation. Critical services do not depend on Spot. Stable baseline capacity can use commitments. Interruptible workers can use Spot. Peaks and uncertainty can stay pay-as-you-go until the pattern is proven.

Keeping Spot savings usable

Spot savings remain useful only while the operational signal stays healthy. If eviction rates climb, jobs retry too often, queues build up, or developers spend time cleaning failed work, the nominal discount no longer tells the whole story.

• Track eviction frequency, average worker lifetime, job retry rate, failed task rate, and queue backlog.
• Review VM size and region choices when eviction becomes frequent.
• Keep fallback capacity for work that must finish inside a business deadline.
• Separate Spot cost savings from productivity loss caused by failed or repeated work.
• Revisit the design when workloads become more critical, more stateful, or more time-sensitive.