What Are Preemptible (Spot) Virtual Machines? Benefits, Risks, and Architecture

Microsoft Azure and AWS sell them. So do specialized clouds like Nebius, RunPod, and Vast.ai. Preemptible virtual machines (Spot or preemptible VMs) cost 50% to 80–90% less than standard On-Demand rates.

In short: a Spot VM is cheap capacity a provider can reclaim at any moment. For batch jobs it’s nearly free compute; stateful services need orchestration on top (such as microsrv).

Below: where this spare capacity comes from, why it costs so little, and how to run on it without losing data.

1. Where Spot Capacity Comes From

Every cloud provider carries a pool of unallocated compute. The buffer exists for three reasons: SLA commitments, sudden demand spikes, and provisioning new On-Demand VMs without a wait.

That idle server in the rack is powered on, connected, and losing money. Depreciation and cooling run whether or not a customer is paying.

So providers sell the idle hardware at steep discounts. One condition applies: as soon as an On-Demand customer needs those resources, the provider reclaims the host.

2. How Eviction Mechanics Work

A preemptible VM keeps running while surplus capacity lasts in its availability zone or server pool.

Pricing Models

Fixed discount (preemptible): The provider sets a fixed price, typically 50% to 70% below standard rates. Preemption happens when On-Demand workloads need the capacity.
Spot market or bidding (Spot / maximum price): In clouds like Azure Spot, RunPod, and Vast.ai, prices fluctuate with demand. You set a maximum bid. The market price crosses it, and your instance is evicted.

Eviction Notices

When a provider reclaims a host, it sends an eviction notice through its metadata service (IMDS) or system agents.

Response window: Usually 30 seconds (Azure Spot, AWS) up to two minutes. In some GPU clouds, a sudden demand spike can mean eviction with almost no warning at all.
Eviction policies:
- Stop / deallocate: The VM stops, its vCPU and RAM are freed, but configuration and attached disks remain. You pay for disk storage only.
- Delete / terminate: The VM and its ephemeral local disks are destroyed permanently.

3. Key Benefits of Spot Resources

Compute savings up to 80%. The same workload budget buys several times more capacity.
A natural fit for batch workloads:
- AI and machine learning: Model-training jobs that checkpoint regularly (PyTorch / TensorFlow).
- CI/CD build farms: Ephemeral build nodes for test suites, compilation, and Docker image builds.
- Data processing and rendering: Video transcoding, 3D rendering, web scraping, large-scale analytics.
- Kubernetes Spot node pools: Secondary worker nodes for background tasks you can afford to reschedule.

4. Limitations and Trade-Offs

Running a regular service directly on Spot instances carries real risk:

No uptime SLA. Providers guarantee nothing about how long a VM lives. It may run undisturbed for weeks or die 10 minutes after boot.
Loss of in-memory state. When the host goes down, uncheckpointed RAM state and local ephemeral disks go with it.
Dropped network sessions. The VM’s public and private IPs are released, breaking active TCP connections, SSH sessions, and open sockets.
Correlated evictions. During a regional demand surge, the provider can reclaim dozens of cluster nodes at once.

5. Architectural Patterns for Spot Resources

Applications built for interruptible capacity share two properties: no local state and tolerance for sudden restarts.

Externalize state. Nothing critical on local disks. State lives in a database, Redis, or object storage (S3).
Handle shutdown signals. Poll the provider’s metadata endpoint for eviction notices (SIGTERM / Scheduled Events), stop accepting new traffic, and shut down gracefully.
Diversify instance types and locations. Don’t tie workloads to one instance type or zone. Configure autoscalers to draw from multiple instance families across several availability zones.

6. How microsrv Eliminates Spot Drawbacks

The traditional path into Spot means rearchitecting: custom graceful-shutdown logic, network reconfiguration, and accepting restarts that wipe in-memory caches. For many teams the development and operational overhead eats the compute savings.

The microsrv platform removes these constraints at the infrastructure layer:

Live RAM and process migration: The orchestrator migrates memory state on the fly. The application inside the VM doesn’t restart, keeps its in-memory state, and keeps working after the host changes. See the deep dive on live migration.
Persistent state protection: Storage volumes replicate continuously. When a host is reclaimed, the filesystem and its data stay fully intact. The replicated storage overview explains how.
Network identity continuity through eBPF: The network layer transparently rebinds traffic when the VM moves. Private IPs, <vm>.msrv.space domain names, and active TCP sockets persist, and clients don’t reconnect. The architecture is covered in the eBPF networking overview.
No code changes required: Applications run exactly as they would on a conventional VM, with dedicated vCPUs, persistent storage, and reliable networking.

The result: about 25% savings compared to standard cloud rates without the operational headaches of raw Spot, with SSH, a hostname, and TLS included. For how list-price discounts differ from realized savings after downtime, see Spot vs On-Demand.

Sources and further reading

AWS — Spot Instance interruptions and interruption notices (2-minute warning)
Microsoft Azure — Spot Virtual Machines eviction policy
Google Cloud — Spot VMs overview
KVM/QEMU — Live migration documentation

Field note: This post is based on my own experience running Spot capacity in production and on the microsrv orchestrator described in live migration and replicated storage. The “about 25% vs standard rates” figure comes from public provider calculators at /go/cloud-a and /go/cloud-b for 3×(4 vCPU·8 GB·40 GB SSD); the full methodology is in Spot vs On-Demand.