Spot Instances Explained (2026): 2 Minutes vs 30 Seconds, Up to 91% Off

The usual spot story goes like this: a team turns spot instances on, enjoys a smaller bill for a month, then turns them off after an interruption takes out a stateful service nobody had pinned to on-demand. The pricing was never the problem. Treating spot instances as cheap servers, rather than servers on a revocable lease, was. This post explains spot instances on AWS, Google Cloud and Azure as they work in November 2026: what the discount really is, how much warning you get before the capacity is reclaimed, how often interruptions happen according to the providers' own data, which allocation strategy to choose, and which workloads (including AI training) belong on spot. If you want the hands-on Kubernetes version, the companion guide is How to Run Kubernetes on Spot Instances: Interruption Handling.

What is a spot instance?

A spot instance is a virtual machine running on a provider's unused capacity, sold at a discount on the condition that the provider can take it back. AWS calls them Spot Instances, Google Cloud calls them Spot VMs (the successor to preemptible VMs), and Azure calls them Azure Spot Virtual Machines. Once running, a spot VM is the same hardware and the same image as its on-demand twin. What differs is the contract: no SLA, no guarantee you can launch one, and a short notice period before eviction.

The pricing mechanics have changed since the bidding era, and a lot of advice online still describes auctions. On AWS, the Spot price for each instance type in each Availability Zone is set by EC2 and, in the words of the EC2 user guide, "adjusted gradually based on the long-term supply of and demand". You can still set a maximum price, but the interruption docs warn that doing so makes interruptions more frequent. Google Cloud says Spot prices can change up to once every day. Azure keeps a real max-price setting: -1 means you are never evicted for price, only for capacity, and you never pay above the standard rate (Azure docs).

So on all three clouds you mostly lose spot VMs to capacity, not price, and capacity is something you can engineer around by spreading across instance types and zones.

AWS Spot vs GCP Spot VMs vs Azure Spot: how do they compare?

The headline discounts are close. The notice periods are not, and that is the number that decides what you can safely run.

	AWS EC2 Spot	Google Cloud Spot VMs	Azure Spot VMs
Maximum discount claimed	up to 90% vs on-demand (AWS)	up to 91% (Google Cloud)	up to 90% vs pay-as-you-go (Azure)
Warning before reclaim	2 minutes, plus an earlier best-effort rebalance recommendation (AWS)	default 0 s notice plus 30 s best-effort shutdown; notice configurable to 120 s (Google Cloud)	up to 30 s via Scheduled Events, best effort (Azure)
What happens to the VM	terminate, stop or hibernate (your choice)	STOP (default) or DELETE	Deallocate (default) or Delete
Price changes	gradually, long-term trends	up to once a day	variable; optional max price, -1 disables price eviction
Maximum runtime	none	none (the old 24-hour preemptible limit is gone)	none
Billing quirk	no charge if EC2 interrupts in the first hour (Linux, Windows) (AWS)	Free Tier credits do not apply	deallocated VMs keep disk charges and count against quota
Kubernetes node label	eks.amazonaws.com/capacityType: SPOT or karpenter.sh/capacity-type: spot	cloud.google.com/gke-spot=true (GKE)	kubernetes.azure.com/scalesetpriority=spot, tainted NoSchedule (AKS)

Two details in that table catch people. First, AWS Spot is not covered by Savings Plans, and spot spend does not count towards your Compute Savings Plan commitment. If you buy a large commitment and then move most of your fleet to spot, you will pay for a commitment you no longer use. Size commitments for the on-demand floor you will keep. Second, the Azure and Google notice periods are short enough that "drain the node gracefully" is mostly aspirational. Thirty seconds is enough to stop accepting traffic, not to finish a request queue.

How often do spot instances get interrupted?

AWS publishes the most data, through the Spot Instance Advisor. The page states that the average interruption frequency across all Regions and instance types "has historically been <5%". Behind the page is a public JSON file that the advisor loads in your browser, and it buckets every instance type, per Region and operating system, into five interruption bands: <5%, 5-10%, 10-15%, 15-20% and >20%, alongside an estimated saving. I pulled it on 10 November 2026 with the script below; it needs no AWS credentials.

#!/usr/bin/env python3
# Summarise the public EC2 Spot Instance Advisor data. Python 3.10+, stdlib only.
# The advisor web page loads this same file; no AWS account or credentials needed.
import json, statistics, urllib.request
from collections import Counter

URL = "https://spot-bid-advisor.s3.amazonaws.com/spot-advisor-data.json"
data = json.load(urllib.request.urlopen(URL, timeout=30))
labels = [r["label"] for r in data["ranges"]]       # ['<5%', '5-10%', '10-15%', '15-20%', '>20%']

for region in ["us-east-1", "us-west-2", "eu-west-1", "ap-south-1"]:
    types = data["spot_advisor"][region]["Linux"]   # {instance_type: {'s': savings %, 'r': band index}}
    bands = Counter(v["r"] for v in types.values())
    share = {labels[i]: round(100 * bands[i] / len(types), 1) for i in range(len(labels))}
    print(region, len(types), "types", share,
          "median saving", statistics.median(v["s"] for v in types.values()), "%")

# Look up individual types you actually run
for t in ["m7i.xlarge", "c7g.xlarge", "g5.xlarge", "p5.48xlarge"]:
    print(t, data["spot_advisor"]["us-east-1"]["Linux"].get(t))

The result is less comforting than "<5%" suggests. In us-east-1, 41% of the 1,145 Linux instance types listed sat in the >20% band and only 21% in <5%. In eu-west-1 the picture flips: 47.5% of 929 types were in <5% and 20% above 20%. Median estimated savings were 63% in us-east-1, 64% in us-west-2, 56% in eu-west-1 and 63% in ap-south-1, and the highest single figures were 83 to 90%. The "up to 90%" headline is real, but it is the tail, not the typical case.

Two cautions about this data. AWS does not document the window behind each band, and a band describes an instance type in a Region, not a capacity pool in a specific zone, so treat it as a ranking, not a forecast. And it counts types, not instances: the busy general-purpose families everyone asks for are where interruption rates are highest. In us-east-1, all nine r6g sizes sat above 20%, while all nine c7g sizes sat at 10% or below. Google publishes no equivalent table. Azure shows per-size eviction rates in the portal and in the SpotResources table of Azure Resource Graph, quoted per hour from the last 7 days in the portal and 28 days in Resource Graph.

Is the 2-minute warning really 2 minutes?

For the instance, yes, give or take best effort. For your pods, often not. The EKS managed node group documentation is unusually candid: there is a delay between the notice and the start of eviction, evictions are sequential to protect the API server, and during simultaneous reclamations "Pods may be forcibly terminated without receiving termination signals" (EKS docs). AWS recommends termination grace periods of 30 seconds or less for spot workloads and no long preStop hooks.

GKE is stricter by design. With the default 30-second shutdown, regular pods get 15 seconds and system pods the other 15, and setting a larger terminationGracePeriodSeconds in the pod spec does not extend it; the ceiling is 120 seconds if you configure the longer notice (GKE docs). On Azure you have up to 30 seconds, delivered on a best-effort basis.

AWS also emits an EC2 instance rebalance recommendation when an instance is at elevated risk. It can arrive well before the 2-minute notice or together with it, and it is not guaranteed. EKS managed node groups use it to launch a replacement node early. Karpenter, as of its current disruption docs, does not drain on rebalance recommendations; it only publishes an event, because draining on every recommendation causes a lot of churn for interruptions that often never come.

The engineering conclusion is the same on every cloud: design for the case where a pod gets SIGKILL with no warning, then treat the notice as a bonus that lets you do it more politely.

Which allocation strategy should you use for spot?

On AWS, the allocation strategy decides which capacity pools (instance type plus zone) your fleet draws from. The EC2 docs list five options and recommend price-capacity-optimized for most workloads: it picks the pools with the most spare capacity, then the cheapest of those. capacity-optimized ignores price and is meant for workloads with an expensive restart, such as long CI jobs, rendering and deep learning. lowest-price is explicitly not recommended because it "has the highest risk of interruption", and it is still the default when you call the API from the CLI without saying otherwise.

You rarely set this by hand on Kubernetes. EKS managed node groups use price-capacity-optimized for new Spot node groups on Kubernetes 1.28 or later and turn on Capacity Rebalancing. Karpenter uses price-capacity-optimized through EC2 CreateFleet, which is covered in my Karpenter setup guide. What you control is the size of the menu. Every instance type you allow is another pool; a node group with one instance type in one zone is a single pool, and a single pool is how you get "all our spot nodes vanished at once". AWS's Spot placement score will rate a Region or zone from 1 to 10 for a given request, but it insists on at least three instance types (except for P, G, Trn and Inf families) and explicitly guarantees nothing about interruption.

Which workloads should run on spot instances?

The test is simple to state: if the process were killed with no warning right now, would anything be lost that cannot be recomputed, and would a user notice? Workloads that pass are good spot candidates. The EKS docs list batch and ML training, Spark-style ETL, queue workers and stateless API endpoints, and recommend keeping cluster management tools, StatefulSets and databases on on-demand.

Workload	Spot fit	Why	Source for the guidance
Stateless web/API replicas (3 or more, behind a load balancer)	Good, with PDBs and spread	lose one replica, the rest serve	EKS managed node groups
CI runners and build agents	Good	jobs are retryable; use capacity-optimized for long builds	EC2 allocation strategies
Batch, ETL, queue consumers	Good	idempotent units of work, re-queued on loss	EKS managed node groups
ML training with checkpoints	Good if checkpoints are frequent	restart from last checkpoint, not from zero	SageMaker managed spot training
Databases, StatefulSets, Kafka brokers	Poor	recovery is slow and replication storms hurt	EKS managed node groups
Cluster add-ons (CoreDNS, ingress, Karpenter itself)	Poor	losing them breaks everything else	GKE Spot VMs
Singletons with no replica	Poor	one interruption is a full outage	general practice

This is where the platform discipline of the last decade pays off. Spot works when pods have honest resource requests, replicas, readiness probes, PodDisruptionBudgets and graceful SIGTERM handling. Teams that already do those things for rolling deploys get spot almost free; teams that do not discover every gap at once, at 2 a.m. Kubernetes Cost Optimization in 2026 covers the requests side.

Is AI training on spot instances a good idea in 2026?

It can be, with three conditions. You checkpoint often enough that a lost node costs minutes, not hours. Your job can resume on a different instance, possibly in a different zone. And you can tolerate waiting when GPU spot capacity is not there at all.

The snapshot data cuts both ways. In us-east-1 on 10 November, p5.48xlarge (8x H100) sat in the <5% band with an estimated 57% saving, while seven of the eight g5 sizes were above 20%. That is one day and one Region, not a trend. On Google Cloud, GPUs on Spot VMs are preempted during host maintenance by default and cannot restart automatically, whereas standard GPU VMs get an hour's notice (Google Cloud). And the very largest machines may simply not be offered: Spot VMs are not supported on the A4X, A4X Max and A5X series.

Managed services hide some of this. SageMaker managed spot training claims savings of up to 90%, copies checkpoints to S3 for you, and makes you set MaxWaitTimeInSeconds greater than MaxRuntimeInSeconds. Note the honest caveat in its docs: it never falls back to on-demand, so a job can wait for spot capacity until the timeout and then stop. For multi-node distributed training, where losing one node stalls the whole collective, reserved capacity is often the saner buy; AWS sells EC2 Capacity Blocks for ML for up to six months, bookable up to eight weeks ahead, for P4d, P5, P5e, P5en, P6 and Trainium instances. Spot is a better fit for single-node fine-tuning, hyperparameter sweeps, batch inference and evals. If you are weighing GPU options more broadly, GPU Clouds in 2026 covers the neocloud prices.

FAQ

What is the difference between spot and preemptible VMs on Google Cloud?

Spot VMs are the current version of preemptible VMs. The practical difference is that Spot VMs have no maximum runtime, while Compute Engine always stops preemptible VMs after 24 hours. Both run on excess capacity, have no SLA and can be preempted at any time.

How much notice do you get before a spot instance is terminated?

AWS gives a 2-minute interruption notice through instance metadata and EventBridge, sometimes preceded by a rebalance recommendation. Azure gives up to 30 seconds through Scheduled Events. Google Cloud gives a 30-second best-effort shutdown by default, and you can configure a 120-second preemption notice ahead of it. All three are best effort, so code for zero.

Do Savings Plans or Reserved Instances apply to spot instances?

No. On AWS, Savings Plans give no extra discount on Spot, and Spot spend does not count towards a Compute Savings Plan commitment. Commit only for the on-demand baseline you expect to keep.

Are spot instances safe for production Kubernetes?

For stateless, replicated services with PodDisruptionBudgets, topology spread and an on-demand fallback, generally yes. Keep the control-plane add-ons, databases and singletons on on-demand nodes. The companion guide walks through the setup on EKS with Karpenter or managed node groups.

If I were starting this quarter, I would not begin with the cluster. I would run the advisor script against the Regions I use, list the instance families my workloads could tolerate, and check that every candidate workload already has at least two replicas, a PDB and a SIGTERM handler. Then I would move CI runners and batch first, put stateless services on a mixed spot and on-demand pool second, and shrink any Savings Plan renewal to the on-demand floor that remains. Spot rewards boring operational hygiene far more than clever bidding, and in 2026 there is no bidding left to be clever about anyway.

Related: How to Set Up Karpenter on EKS: NodePools, Spot and Consolidation (2026), Why Is My AWS Bill So High? 9 Hidden Charges and 2026 Prices and Kubernetes Autoscaling Explained (2026): HPA, VPA, KEDA and Karpenter.