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

+----------------------------------------------------------------------------+
| SPOT INSTANCE EVICTION VS MICROSRV LIVE MIGRATION                          |
+----------------------------------------------------------------------------+
|                                                                            |
|  [1] RAW SPOT INSTANCE EVICTION (Without Orchestration)                    |
|                                                                            |
|      +-----------+                                                         |
|      |  Host-17  | --- Eviction Notice / Host Reclaimed ---> X             |
|      +-----------+                                                         |
|            |                                                               |
|            +-- In-Memory RAM State -------------- ERASED                   |
|            +-- Application Processes ------------ KILLED                   |
|            +-- Private & Public IPs ------------- LOST                     |
|            +-- Active Network Connections ------- DROPPED                  |
|            +-- Outcome -------------------------- CRASH & COLD RESTART     |
|                                                                            |
|  [2] MICROSRV LIVE MIGRATION (Automated Platform)                          |
|                                                                            |
|      Host-17 (Evicting)                    Host-42 (New Spot)              |
|      +-----------+     Live RAM Migration    +-----------+                 |
|      | Guest VM  | ========================> | Guest VM  |                 |
|      +-----------+     Disks & eBPF Network  +-----------+                 |
|            |                                       |                       |
|            +-- Memory (RAM) & Processes --------- PRESERVED & ACTIVE       |
|            +-- Application Workload ------------- NO RESTART REQUIRED      |
|            +-- Network IP & Domain (app.ru) ----- UNCHANGED                |
|            +-- Active TCP Connections ----------- KEPT ALIVE               |
|                                                                            |
+----------------------------------------------------------------------------+

Cloud providers — ranging from hyper-scalers like Microsoft Azure and AWS to specialized clouds like Nebius, RunPod, and Vast.ai — offer preemptible virtual machines (Spot / Preemptible VMs) at discounts between 50% and 80–90% compared to standard On-Demand rates.

Here is a breakdown of where this spare compute capacity comes from, why it costs so much less, what constraints it imposes on engineering teams, and how to run workloads on it effectively.

1. Where Spot Capacity Comes From

Every cloud provider builds data centers with significant excess capacity (unallocated compute). This buffer is required to meet SLA commitments, absorb sudden customer demand spikes, and instantly provision new On-Demand VMs upon request.

If a physical server sits powered on in a rack without an active customer, the provider incurs ongoing depreciation, power, and cooling costs without generating revenue.

To monetize this idle hardware, clouds offer it at steep discounts with one primary condition: as soon as a standard On-Demand customer requires those resources, the provider reclaims the server.

2. How Eviction Mechanics Work

Preemptible VMs continue running as long as surplus capacity is available in a given availability zone or server pool.

Pricing Models

Fixed Discount (Preemptible): The provider sets a fixed discounted price (typically −50% to −70% off standard rates). The VM is preempted only when On-Demand demand requires the capacity.
Spot Market / Bidding (Spot / Max Price): In clouds like Azure Spot, RunPod, or Vast.ai, prices fluctuate dynamically based on supply and demand. You can specify a maximum bid price (Max Price). If the current market price exceeds your bid, your instance is evicted.

Eviction Notices

When a provider reclaims a host, it broadcasts an eviction notice via its internal Instance Metadata Service (IMDS) or system agents.

Response Window: Providers typically give between 30 seconds (Azure Spot, AWS) and 2 minutes before shutdown. In some GPU-focused clouds during sudden demand spikes, eviction can occur almost instantaneously.
Eviction Policies:
- Stop / Deallocate: The VM is stopped and its vCPU/RAM are freed, but its configuration and attached disk remain intact. You only pay for disk storage.
- Delete / Terminate: The VM and its ephemeral local disks are permanently destroyed.

3. Key Benefits of Spot Resources

Drastic Compute Cost Savings (up to 80%): Run 3 to 5 times more compute capacity for the same infrastructure budget.
Ideal for Fault-Tolerant & Batch Workloads:
- AI / Machine Learning: Model training jobs designed with regular state checkpointing (PyTorch / TensorFlow).
- CI/CD Build Farms: Ephemeral build nodes for test suites, code compilation, and Docker image builds.
- Data Processing & Rendering: Video transcoding, 3D rendering, web scraping, and large-scale data analytics.
- Kubernetes Spot Node Pools: Secondary worker node pools for background tasks that can easily be rescheduled.

4. Limitations and Trade-Offs

Despite the cost savings, running workloads directly on Spot instances involves significant operational challenges:

Zero Uptime SLA: Providers offer no SLA or availability guarantees. An instance may run undisturbed for weeks or be reclaimed 10 minutes after boot.
Loss of In-Memory State: Forced shutdowns erase un-checkpointed RAM state and local ephemeral disk contents.
Network Session Drops: When an instance is evicted, its IP address is released, breaking active TCP connections, SSH sessions, and open sockets.
Correlated / Mass Evictions: During regional demand surges, providers may evict dozens of instances across your cluster simultaneously.

5. Architectural Patterns for Spot Resources

To run reliably on interruptible hardware, applications must adhere to Stateless & Fault-Tolerant principles:

Externalize State: Never store persistent data on local ephemeral disks. Store all state in external databases, Redis, or object storage (S3).
Intercept Shutdown Signals: Poll provider metadata endpoints to catch eviction notices (SIGTERM / Scheduled Events), stop accepting new traffic, and perform a graceful shutdown.
Instance & Location Diversity: Avoid locking workloads to a single instance type or zone. Configure autoscalers to draw from diverse instance families across multiple availability zones.

6. How microsrv Eliminates Spot Drawbacks

Adopting traditional Spot instances requires re-architecting applications: writing custom graceful shutdown logic, handling dynamic IP changes, and accepting application restarts with loss of in-memory cache. For many engineering teams, the development and operational overhead outweighs the compute savings.

The microsrv platform eliminates these trade-offs directly at the infrastructure layer:

Live RAM & Process Migration: The orchestrator live-migrates memory state on the fly. Your application running inside the VM does not restart, retaining its in-memory state and executing seamlessly across host changes.
Persistent State Protection: Storage volumes are replicated continuously. When a host is reclaimed, your filesystem and data remain 100% intact.
Network Identity Continuity via eBPF: An eBPF-powered network layer transparently rebinds traffic when compute moves. Private IPs, <vm>.microsrv.ru domain names, and active TCP sockets persist without client reconnection drops.
Zero Code Modifications Required: Applications run exactly as they would on traditional standard VMs — with dedicated vCPUs, persistent storage, and reliable networking.

You get about 40% savings compared to standard cloud rates without the operational headaches and risks of raw Spot instances.