Spot and Preemptible Capacity

Spot and preemptible capacity refers to spare cloud compute capacity that a provider sells at a steep discount and can reclaim with little advance notice when that capacity is needed elsewhere. This pricing model gives platform teams one of the largest discount levers in cloud cost optimization, but only for workloads whose retry, checkpointing, and fallback costs don't erode the savings. AWS calls this Spot Instances, Google Cloud calls it Spot VMs (the current version of what it originally launched as Preemptible VMs), and Azure calls it Spot Virtual Machines: the same discount-for-availability trade under three different names, with different constraints on each provider.

How Spot and Preemptible Capacity Works

Cloud providers maintain spare compute capacity that isn't committed to On-Demand or reserved customers at a given moment. Spot and preemptible capacity is that spare capacity, sold at a discount in exchange for the provider's right to reclaim it when On-Demand or reserved demand needs it back.

AWS Spot Instances price this spare EC2 capacity based on real-time supply and demand for the specific instance type and Availability Zone, so the discount can shift over time. Azure Spot Virtual Machines work similarly: the price moves with supply and demand, capped at the standard On-Demand rate. Google Cloud Spot VMs instead apply a discount that stays fixed relative to the On-Demand rate for a given machine type, rather than tracking a live market price.

Reclamation is different from a workload shutting itself down. When a provider reclaims spot or preemptible capacity, it sends an interruption signal, AWS's two-minute Spot Instance interruption notice, Azure's 30-second eviction notice, or Google Cloud's short shutdown signal to a Spot VM, and then stops or terminates the instance regardless of what the workload was doing. This differs from On-Demand pricing, where the provider keeps the instance running until the customer stops it, and from committed discount instruments such as Reserved Instances, Savings Plans, and Committed Use Discounts, which lower the rate in exchange for a spend or usage commitment rather than accepting interruption risk.

How Spot Pricing and Reclamation Differ by Provider

The table above summarizes the naming and notice period, but the reclamation mechanics also differ in ways that affect how a workload should be designed:

• AWS Spot Instances: priced dynamically per instance type and Availability Zone; interruption is signaled through an EC2 Spot Instance interruption notice (via EventBridge or instance metadata) roughly two minutes before termination.

• Google Cloud Spot VMs: priced at a discount that is fixed relative to the On-Demand rate rather than a live bid; the older Preemptible VM offering always stopped within 24 hours even when capacity was available, while current Spot VMs carry no fixed runtime limit and can keep running as long as capacity is available.

• Azure Spot Virtual Machines: priced dynamically, capped at the standard VM rate; eviction is signaled through Azure Scheduled Events roughly 30 seconds before the VM is evicted.

These differences matter operationally. A workload built around AWS's two-minute warning may not have enough time to gracefully drain connections on Google Cloud or Azure's much shorter notice, so interruption handling has to be designed for the shortest notice period a workload might actually run under, not the most generous one.

Spot and Preemptible Capacity in FinOps Cost Optimization

Spot and preemptible capacity is a direct optimization lever: the same compute work costs less, often substantially less, than running it on On-Demand pricing. AWS states that Spot Instances are available at a discount of up to 90% off On-Demand pricing, and Google Cloud and Azure publish comparable discount ranges for their own spot and preemptible offerings. The exact figure depends on instance type, region, and, for AWS and Azure, real-time supply and demand.

That discount is not free. The FinOps discipline here is modeling the operational cost of interruption, retries, checkpoint and restore time, and occasional job failure, against the savings, rather than treating the discount as a guaranteed reduction in spend. A batch job that fails and reruns from scratch every time it's interrupted can quietly erase the savings that made spot capacity attractive in the first place.

Spot and preemptible capacity also carries a governance dimension. Deciding which workloads are approved to run on spot or preemptible capacity is an architecture and policy decision, not just a pricing one. Production-critical, stateful workloads that can't tolerate a sudden restart are poor candidates regardless of the discount available, and teams that skip this review risk visible downtime instead of the cost savings they expected.

Best Practices for Running Workloads on Spot and Preemptible Capacity

Teams that use spot and preemptible capacity successfully tend to follow a consistent set of practices:

• Diversify across instance types, families, and Availability Zones. Spreading a workload across multiple spot pools reduces the odds that a single reclamation event takes out most of the fleet at once.

• Checkpoint state regularly. A job that saves progress can resume from the last checkpoint after an interruption instead of restarting from the beginning, which is what keeps the retry cost from eating the discount.

• Keep a baseline of On-Demand or reserved capacity for the portion of a service that can't tolerate loss, and use spot or preemptible capacity for the portion that can scale up and down.

• Handle the provider's interruption signal programmatically, whether that's AWS's Spot Instance interruption notice, Azure's scheduled eviction event, or Google Cloud's shutdown signal to a Spot VM, so the workload has a chance to drain traffic or save state before the instance is gone.

Tools like Infracost estimate the cost of AWS Spot Instances defined in Terraform, showing the most recent spot price from its Cloud Pricing API, refreshed at least once a day, in a pull request before the resource is provisioned. That gives a platform engineer a cost estimate to review alongside the interruption trade-off, rather than discovering the price only after the instance is running.

Related Concepts

Opportunity Cost: The value given up by choosing spot or preemptible capacity over a guaranteed-availability option, which is the real cost side of the interruption risk a team accepts for the discount.

Reserved Instances: A committed-use discount instrument that trades a spend or term commitment for a lower rate, rather than trading availability for a lower rate the way spot and preemptible capacity does.

Savings Plans: A flexible, commitment-based discount model that lowers the rate on qualifying usage regardless of instance family, offering a different risk profile than the interruption risk of spot capacity.

Committed Use Discounts: Google Cloud's term for committed-use pricing, which reduces cost through a usage commitment rather than through the reclaimable capacity model that Spot VMs use.

On-Demand Pricing: The standard, uncommitted hourly rate that spot and preemptible capacity is discounted against, and the rate a workload falls back to when it can't tolerate interruption.

Frequently Asked Questions (FAQs)

What is a spot instance?

A spot instance is a unit of spare cloud compute capacity that a provider sells at a discount off its On-Demand price, in exchange for the right to reclaim that capacity with little advance notice. AWS uses the term Spot Instance specifically, while Google Cloud and Azure offer the same underlying model as Spot VMs and Spot Virtual Machines. Spot instances suit workloads that can tolerate interruption, not workloads that require guaranteed uptime.

What is the difference between spot instances and preemptible VMs?

Spot instances and preemptible VMs describe the same underlying trade: discounted compute capacity a provider can reclaim with little notice. Preemptible VM was Google Cloud's original name for this offering, and always stopped within 24 hours even when capacity was available; Google Cloud's current Spot VMs use the same discount-for-availability model but carry no fixed runtime limit. AWS uses Spot Instances and Azure uses Spot Virtual Machines for the equivalent offering.

How much can spot and preemptible capacity save compared to on-demand pricing?

Spot and preemptible capacity is commonly discounted well below On-Demand pricing; AWS states that Spot Instances are available at a discount of up to 90% off On-Demand pricing. The exact discount for spot instances or preemptible VMs on any provider depends on instance type, region, and, for AWS and Azure, real-time supply and demand. Teams should check current pricing for a specific instance type rather than assuming a fixed savings percentage.

What happens when a spot instance or preemptible VM is reclaimed?

When a provider reclaims a spot instance or preemptible VM, it first sends an interruption signal: AWS gives a two-minute Spot Instance interruption notice, while Google Cloud and Azure each give roughly 30 seconds before shutdown or eviction. After that window, the provider stops or terminates the instance regardless of what the workload was doing, so any state that wasn't checkpointed or saved is lost.

Which workloads are good candidates for spot and preemptible capacity?

Spot instances and preemptible VMs suit stateless, fault-tolerant, or checkpointable workloads: batch processing, CI/CD build agents, rendering, and horizontally scaled services that can lose an individual node without losing the job. Workloads that hold irreplaceable state in memory, or that can't tolerate a sudden restart, are poor candidates for spot instances regardless of the available discount.

Can spot instances be used safely in production?

Spot instances and preemptible VMs can run production workloads safely when the architecture accounts for interruption: diversifying across instance types and Availability Zones, checkpointing state, and keeping a baseline of On-Demand or reserved capacity for components that can't tolerate loss. Running production traffic entirely on spot instances without that design work risks visible downtime when capacity is reclaimed.