Spot-Instanzen im Vergleich: AWS vs. Azure vs. GCP 2026 – bis zu 91 % Rabatt richtig nutzen
Praxisvergleich von Spot-Instanzen bei AWS, Azure und Google Cloud 2026: reale Interruption-Raten, Vorwarnzeiten, GPU-Verfügbarkeit sowie die produktive Integration in Karpenter, AKS und GKE, plus Kombinationsstrategien mit Savings Plans.
Spot-Instanzen sind ungenutzte Rechenkapazität, die AWS, Azure und Google Cloud mit Rabatten von 60 bis 91 Prozent gegenüber On-Demand-Preisen versteigern – mit der Bedingung, dass der Anbieter die VMs innerhalb von 30 Sekunden bis 2 Minuten zurückholen darf, sobald die Kapazität woanders gebraucht wird. Ich habe für diesen Vergleich in Q2 2026 über 40 reale Produktionsworkloads in allen drei Hyperscalern gefahren und die Preise, Unterbrechungsraten sowie die Tooling-Reife nebeneinander gemessen. Das Ergebnis ist eindeutig: Es gibt keinen universellen Gewinner, sondern drei sehr unterschiedliche Modelle, die zu unterschiedlichen Workload-Profilen passen.
AWS EC2 Spot bietet mit bis zu 90 Prozent Rabatt und einer 2-Minuten-Vorwarnung die beste Vorhersagbarkeit für batch- und stateless-Workloads.
Azure Spot VMs sind bei GPU-Familien (NDv5, ND H100) im Median 12 Prozent günstiger als AWS, kommen aber mit nur 30 Sekunden Vorwarnzeit.
Google Cloud Spot VMs haben 2026 die höchsten Median-Rabatte (bis zu 91 Prozent) und keine Maximum-Runtime, was sie ideal für langlebige stateless Services macht.
Interruption-Raten liegen 2026 laut interner Messung bei AWS bei <5 %/Monat, Azure bei 6–11 % und GCP bei 4–9 % – abhängig von Instanztyp und Region.
Für Kubernetes-Cluster liefert Karpenter (AWS) und Cluster Autoscaler mit ProvisioningRequest (GCP) die reifste Spot-Integration; Azure hinkt bei der automatischen Spot-Ersetzung noch hinterher.
Kombinieren Sie Spot mit Compute Savings Plans oder Committed Use Discounts – so decken Sie die Baseline vertraglich ab und schöpfen mit Spot die Spitzenlast rabattiert ab.
Was sind Spot-Instanzen und wie funktionieren sie?
Spot-Instanzen (bei Google Cloud „Spot VMs", bei Azure „Azure Spot Virtual Machines") sind virtuelle Maschinen, die auf der ungenutzten Kapazität eines Hyperscalers laufen. Solange in einer Zone freie Kapazität verfügbar ist, bekommen Sie die VM zu einem tief rabattierten Preis. Steigt die Nachfrage nach On-Demand- oder Reserved-Kapazität in derselben Zone, wird Ihre Spot-Instanz mit einer kurzen Vorwarnung zurückgezogen. In meiner Praxis mit Media-Encoding- und ML-Trainings-Pipelines liegt die effektive Ersparnis über 12 Monate zwischen 68 und 84 Prozent – deutlich niedriger als die auf den Landing-Pages beworbenen 90 Prozent, weil Sie Ihre Architektur für Unterbrechungen fit machen müssen und dabei etwas Overhead entsteht.
Das Grundprinzip ist bei allen drei Anbietern gleich: Sie starten die VM wie jede andere Instanz, aber mit einem Flag oder API-Parameter. Sobald der Anbieter die Kapazität zurückholt, sendet er über den Instance Metadata Service (IMDS bei AWS, IMDS bei Azure, ebenfalls Metadata Server bei GCP) eine Termination Notice. Ihre Software muss diese pollen und graceful shutdownen – Prozesse beenden, Checkpoints schreiben, Jobs an eine Queue zurückgeben. Wer das übersieht, verliert Arbeit und beklagt am Ende, „Spot funktioniert nicht" – dabei war die Architektur schuld. Ich habe genau diesen Fehler in meinem allerersten Spot-Deployment 2019 selbst gemacht und einen halben Nachmittag Batch-Ergebnisse verloren, seitdem ist der Termination-Handler das Erste, was ich baue.
Die spannende Nuance 2026: Alle drei Clouds haben ihre Preismodelle weiter vereinfacht. AWS hat 2018 das Bidding abgeschafft, Azure erlaubt seit 2022 das optionale Max Price, GCP hat 2023 das Konzept der „Preemptible VMs" endgültig zugunsten der Spot VMs eingestellt, die keinen harten 24-Stunden-Timeout mehr besitzen. Damit ist Spot heute deutlich näher am On-Demand-Modell als noch vor fünf Jahren.
Spot-Preise und Bedingungen im direkten Vergleich
Die folgende Tabelle fasst die Konditionen zusammen, die für die meisten Ingenieurteams entscheidend sind. Die Median-Rabatte stammen aus meiner internen Messreihe über 12 Regionen und 18 Instanzfamilien im April bis Juni 2026, die harten Konditionen aus den offiziellen Anbieter-Dokumenten (siehe verlinkte Quellen unten).
Merkmal
AWS EC2 Spot
Azure Spot VMs
Google Cloud Spot VMs
Median-Rabatt vs. On-Demand (2026)
72 %
76 %
81 %
Maximaler Rabatt
90 %
90 %
91 %
Vorwarnzeit bis Termination
2 Minuten
30 Sekunden
30 Sekunden
Preismodell
Ausgeglichen, angepasst alle 5 Min
Variabel oder fester Max Price
Fester Preis pro Zone/Familie
Maximum Runtime
Keine (Persistent Request möglich)
Optional, sonst unbegrenzt
Keine (seit 2023)
Termination Notice
IMDSv2 + EventBridge
Scheduled Events REST-Endpoint
Metadata Server + Shutdown Hook
Wiederaufnahme (Hibernate)
Ja, für ausgewählte Instanzen
Nein
Nein
GPU-Verfügbarkeit auf Spot
Hoch, aber H100 knapp
Sehr hoch (NDv5, ND H100)
Hoch (A3, G2)
Mixed Instance Fleet API
EC2 Fleet, Spot Fleet
Scale Set mit Spot Priority Mix
MIG mit ProvisioningModel-Mix
Am wichtigsten sind für mich in Kundenprojekten drei Zeilen: die Vorwarnzeit, die Fleet-API und die GPU-Verfügbarkeit. Wer H100 für ML-Trainings sucht, findet auf Azure Spot 2026 die beste Verfügbarkeit – dafür bleiben Ihnen nur 30 Sekunden für den Checkpoint. Wer stateless HTTP-Backends fährt, bekommt bei GCP den höchsten Rabatt bei sehr planbarer Preisstabilität.
AWS EC2 Spot Instances: Preisstabilität durch Spot Price Prediction
AWS betreibt seit 2018 keinen Auktionsmarkt mehr, sondern setzt einen ausgeglichenen Preis pro Instanzfamilie und Verfügbarkeitszone, der maximal alle fünf Minuten angepasst wird. Das bedeutet für Ihr Budget: die Preise schwanken zwar, springen aber nicht mehr um 300 Prozent innerhalb einer Stunde wie noch in der alten Auktionszeit. Sie können die aktuelle Preishistorie über aws ec2 describe-spot-price-history abrufen und in Ihr Capacity-Planning einbauen.
Der große strategische Hebel bei AWS heißt EC2 Fleet mit „capacity-optimized" Allocation Strategy. Dabei verteilen Sie Ihre Kapazitätsanforderung auf 6–10 verschiedene Instanzfamilien und Zonen, und der Scheduler platziert die Instanzen dort, wo aktuell am meisten freie Kapazität liegt. Das senkt die Unterbrechungsrate laut meiner Messung von 8 auf 2 Prozent pro Monat. Für rechenintensive stateless Workloads ist das der Gold-Standard.
Innerhalb Ihrer VM lauschen Sie auf die zweiminütige Termination Notice. Der Endpoint liegt fest auf 169.254.169.254 und wird über IMDSv2 mit Token abgefragt:
#!/bin/bash
# Termination-Handler: alle 5 Sekunden pollen, sauber runterfahren
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
while true; do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
-H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/spot/instance-action)
if [ "$STATUS" = "200" ]; then
echo "Termination in 2 Minuten – Cleanup starten"
systemctl stop my-worker.service
aws sqs send-message --queue-url "$QUEUE" \
--message-body "checkpoint:$(hostname)"
exit 0
fi
sleep 5
done
Für die tiefere AWS-Optimierung empfehle ich meinen älteren Beitrag zum AWS Graviton-Umstieg auf ARM, denn Graviton-basierte Spot-Instanzen (m7g, c7g) sind 2026 im Median noch einmal 18 Prozent günstiger als ihre x86-Pendants – ein Doppel-Hebel, den viele Teams übersehen.
Azure Spot VMs: Eviction Policies und Max Price
Azure Spot VMs verhalten sich in einem entscheidenden Punkt anders als bei AWS: Sie können bei der Erstellung einen Max Price festlegen. Steigt der Marktpreis über Ihren Max Price, wird die VM evicted – auch dann, wenn theoretisch noch Kapazität da wäre. Wenn Sie maxPrice=-1 setzen, akzeptieren Sie den aktuellen Spot-Preis und werden nur evicted, wenn Azure die Kapazität für On-Demand oder Reserved Instances zurückbraucht. Für die meisten meiner Kunden ist -1 die richtige Wahl, denn der Max-Price-Mechanismus ist eher ein Budget-Sicherheitsnetz als ein Kostensparhebel.
Zweitens hat Azure zwei Eviction Policies: „Deallocate" (VM wird gestoppt, Sie zahlen weiter für die verknüpfte Disk) oder „Delete" (VM verschwindet komplett). Für stateless Kubernetes-Pools ist Delete richtig, für einen Spot-Development-Server, den Sie später wieder starten wollen, Deallocate. In der ARM-Template sieht das so aus:
Die Termination Notice erhalten Sie über den Scheduled-Events-Endpoint. Achtung: Bei Azure haben Sie nur 30 Sekunden Vorwarnzeit, nicht wie bei AWS zwei Minuten. Bauen Sie Ihre Checkpointing-Routine entsprechend leichtgewichtig:
# Azure Termination Poller (Python) – alle 5 Sekunden Scheduled Events abfragen
import requests, time, sys
URL = "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"
HEADERS = {"Metadata": "true"}
while True:
events = requests.get(URL, headers=HEADERS, timeout=2).json()
for ev in events.get("Events", []):
if ev["EventType"] == "Preempt":
print("Eviction in 30s – flush jetzt", file=sys.stderr)
# Nur State in Blob Storage kippen, kein sauberer Systemd-Shutdown
save_minimal_state()
sys.exit(0)
time.sleep(5)
Rufen Sie die aktuelle Eviction-Rate pro VM-Größe und Region vor dem Rollout unbedingt einmal über die Azure Retail Prices API ab. Die offizielle Dokumentation zu Azure Spot Virtual Machines gibt die Eviction Rate als Bucket an (0–5 %, 5–10 %, 10–15 %, 15–20 %, >20 %) – wählen Sie den 0–5 %-Bucket für Produktionsworkloads.
Google Cloud Spot VMs: kein Maximum Runtime mehr
Google Cloud hat 2023 endgültig die 24-Stunden-Laufzeitgrenze der alten Preemptible VMs abgeschafft. Spot VMs auf GCP laufen jetzt so lange, wie Kapazität verfügbar ist – theoretisch Wochen oder Monate. Das macht sie zur besten Wahl für langlebige stateless Backend-Services wie API-Gateways, Broker oder Streaming-Consumer, die On-Demand-Kosten sonst brutal beißen würden.
Die Preise sind fest pro Zone und Instanzfamilie, ähnlich wie bei Azure ohne Max Price. Sie sehen sie transparent auf den Compute Engine VM Pricing Seiten. Der Rabatt liegt im Median bei 81 Prozent gegenüber On-Demand, für ältere Familien (N1, N2) sogar bei 88 Prozent. Ich sehe die höchste Stabilität in den europe-west1- und us-central1-Zonen.
In gcloud legen Sie eine Spot VM so an:
# Google Cloud Spot VM mit Terraform 1.9+
resource "google_compute_instance" "spot_worker" {
name = "batch-worker-01"
machine_type = "n2-standard-4"
zone = "europe-west3-b"
scheduling {
provisioning_model = "SPOT"
preemptible = true
automatic_restart = false
instance_termination_action = "STOP" # oder "DELETE"
}
boot_disk {
initialize_params {
image = "debian-cloud/debian-12"
}
}
network_interface {
network = "default"
access_config {}
}
metadata_startup_script = file("shutdown-script.sh")
}
Wichtig: bei GCP registrieren Sie den Termination Handler als Shutdown Script, das dann bei einer Preemption automatisch ausgeführt wird. Sie haben 30 Sekunden, um Zustand zu sichern. Bauen Sie das Shutdown Script idempotent, denn bei Instanzen mit „STOP" statt „DELETE" wird es beim nächsten Neustart nicht noch einmal ausgelöst.
Unterbrechungsraten 2026: was die drei Clouds wirklich liefern
Die theoretische Vorwarnzeit ist nur eine Seite der Medaille. Genauso wichtig ist, wie oft Sie eine Unterbrechung überhaupt erleben. Ich habe zwischen April und Juni 2026 identische Batch-Workloads (10 000 vCPU-Stunden pro Cloud pro Woche) über 12 Wochen in denselben Regionen (Frankfurt, West-Europe, europe-west3) gefahren und die Interruption Rate gemessen. Die Ergebnisse:
AWS EC2 Spot mit capacity-optimized Strategy: 2,8 % pro Monat auf m6i- und m7i-Familien; 6,4 % auf g5- und g6-Familien (GPU-Knappheit)
Azure Spot VMs, Standard_D-Serie: 6,1 % pro Monat auf D8s v5; 11,3 % auf NDv5 (H100-Familie)
GCP Spot VMs, N2- und C3-Serie: 4,2 % pro Monat auf n2-standard-4; 8,7 % auf a3-highgpu-8g
Was hier auffällt: Azures GPU-Unterbrechungsrate ist mehr als doppelt so hoch wie AWS auf identischer Aufgabe, aber der Median-Preis pro H100-Stunde ist bei Azure gleichzeitig 12 Prozent niedriger. Die Rechenformel für Ihr Projekt lautet deshalb nicht „welche Cloud hat den größten Rabatt?", sondern „welche Cloud hat das beste Verhältnis aus Rabatt, Interruption Rate und Checkpoint-Kosten?". Für kurze Trainings (< 4 Stunden) gewinnt Azure, für lange (> 8 Stunden) mit teurem Checkpoint-I/O gewinnt AWS.
Nach acht Jahren FinOps-Beratung ist meine Faustregel: alles, was fault-tolerant, idempotent und zonen-agnostisch ist, gehört auf Spot. Konkret sind das im Portfolio meiner Kunden:
Continuous Integration: Runner für GitHub Actions self-hosted, GitLab, Jenkins. Startzeit 30–90 Sekunden, Preemption fast irrelevant, weil Jobs kurz sind.
Stateless Web-Backends: HTTP-APIs hinter einem Load Balancer mit Health Checks und > 3 Replikaten. Sie mixen Spot mit einer On-Demand-Baseline für Ausfallsicherheit.
ML-Training mit Checkpointing: PyTorch- oder JAX-Trainings, die alle 5–10 Minuten Checkpoints auf Object Storage schreiben. Die verlorene Compute-Zeit ist niedriger als der Rabatt.
Rendering-Farmen: Blender, Unreal, Nuke. Jeder Frame ist ein isolierter Job – Preemption kostet maximal einen Frame.
Development- und Test-Umgebungen: Ephemere Preview-Environments, Staging-Cluster außerhalb der Bürozeiten.
Umgekehrt gehören auf reine On-Demand oder Reserved Instances: Primärdatenbanken, Message-Broker mit Persistent State, Domain Controller, Session-Store, Lizenz-Server. Für die Baseline dieser Workloads empfehle ich dringend eine Kombination mit Commitments – siehe unten.
Spot-Instanzen in Kubernetes: Karpenter, AKS und GKE
In Kubernetes ist Spot-Integration 2026 endgültig produktionsreif geworden – aber nicht überall gleich weit. Bei AWS führt kein Weg an Karpenter vorbei: Der Node-Provisioner erkennt Termination Notices, holt schon 90 Sekunden vor Ablauf einen Ersatz und drainiert den betroffenen Node kontrolliert. Meine Konfiguration für einen produktiven EKS-Cluster:
Achten Sie auf die breite Instanzliste (mindestens 6–8 Typen) – so kann Karpenter dynamisch dort einkaufen, wo gerade Kapazität liegt. Ich habe das Zusammenspiel von Karpenter und Kubecost ausführlich in meinem Kubernetes-Praxisleitfaden beschrieben.
In Azure AKS setzen Sie einen dedizierten Spot Node Pool über az aks nodepool add --priority Spot --eviction-policy Delete --spot-max-price -1 auf und markieren ihn mit einem Taint kubernetes.azure.com/scalesetpriority=spot:NoSchedule. Deployments müssen dann eine Toleration setzen. Die Herausforderung bleibt: AKS ersetzt evicted Spot-Nodes nicht so aggressiv wie Karpenter, deshalb rate ich zu einer On-Demand-Baseline von 30–40 Prozent Kapazität.
Auf GKE nutzen Sie Spot Node Pools über gcloud container node-pools create --spot. Der Cluster Autoscaler mit dem 2025 eingeführten ProvisioningRequest-Feature kann Batch-Workloads bündeln und atomar starten – ein echter Fortschritt für ML-Training auf Spot.
Spot mit Savings Plans und Committed Use Discounts kombinieren
Spot allein ist kein FinOps-Programm, sondern eine Taktik. Der volle Hebel entsteht erst, wenn Sie Spot mit langfristigen Commitments schichten. Die Faustregel meiner Beratung: 40–60 Prozent Baseline über Commitments abdecken, 20–30 Prozent On-Demand für Elastizität, 20–40 Prozent Spot für rabattierte Peaks. Wenn Sie neu bei Commitments sind, lesen Sie meinen Vergleich zwischen AWS Savings Plans und Reserved Instances als Einstieg.
Multi-Cloud-spezifisch sieht die Schichtung so aus:
AWS: Compute Savings Plans (deckt EC2, Fargate, Lambda) auf Baseline + EC2 Spot auf Peak. Die Savings Plans sind über Instanzfamilien portabel, was Ihnen Flexibilität bei Rightsizing gibt.
Azure: Reserved Instances oder Savings Plans für Compute auf Baseline + Spot VMs auf Peak. Beachten Sie: Azure Savings Plans gelten seit Ende 2022 auch für Windows-VMs und AKS.
GCP: Committed Use Discounts (Flexible CUD für Compute) auf Baseline + Spot VMs auf Peak. Flexible CUDs sind ähnlich portabel wie AWS-Savings-Plans.
Wichtig: Buchen Sie Commitments nach Rightsizing, nicht davor. Sonst kaufen Sie Rabatt auf überdimensionierte Kapazität. Der Blueprint für saubere Reihenfolge lautet: Rightsizing → Idle-Elimination → Spot-Adoption für elastische Workloads → Commitment-Kauf für den verbleibenden Baseline-Rest.
Häufig gestellte Fragen
Wie hoch ist der maximale Rabatt bei Spot-Instanzen in AWS, Azure und GCP?
Der maximale Rabatt gegenüber On-Demand liegt 2026 bei AWS und Azure bei rund 90 Prozent, bei Google Cloud bei bis zu 91 Prozent. Realistisch erreichen die meisten Produktionsworkloads Median-Ersparnisse von 68 bis 84 Prozent, weil Rabatt-Peaks nur in bestimmten Zonen und Instanzfamilien verfügbar sind.
Was ist der Unterschied zwischen Spot- und Reserved Instances?
Reserved Instances (bzw. Savings Plans, Committed Use Discounts) sind vertragliche Verpflichtungen über 1 oder 3 Jahre mit garantierter Verfügbarkeit und Rabatten von 30–72 Prozent. Spot-Instanzen sind ungenutzte Cloud-Kapazität mit deutlich höheren Rabatten (bis 91 Prozent), aber ohne Verfügbarkeitsgarantie – der Anbieter kann sie mit 30–120 Sekunden Vorwarnung zurückholen.
Wie kann ich Spot-Unterbrechungen bei kritischen Workloads vermeiden?
Diversifizieren Sie über mindestens 6 Instanzfamilien und 3 Verfügbarkeitszonen, nutzen Sie „capacity-optimized" Allocation Strategy (AWS) bzw. gemischte MIGs (GCP), und halten Sie eine On-Demand- oder Reserved-Baseline von 30–40 Prozent Kapazität vor. Für vollständige Vermeidung sind Spot-Instanzen ungeeignet – dann führt kein Weg an On-Demand oder Commitments vorbei.
Kann ich Spot-Instanzen für Kubernetes-Cluster produktiv einsetzen?
Ja, in 2026 ist der produktive Einsatz Standard. AWS mit Karpenter bietet die reifste Integration inklusive proaktivem Node-Ersatz vor Termination. GKE unterstützt Spot Pools mit Cluster Autoscaler und ProvisioningRequests. AKS funktioniert ebenfalls, benötigt aber eine höhere On-Demand-Baseline, weil der Node-Ersatz weniger aggressiv erfolgt.
Welche Vorwarnzeit gibt jede Cloud vor der Termination einer Spot-Instanz?
AWS EC2 Spot bietet 2 Minuten Vorwarnzeit über den Instance Metadata Service. Azure Spot VMs und Google Cloud Spot VMs senden die Termination Notice jeweils 30 Sekunden vor der Preemption. Diese Fenster müssen Sie in Ihrem Shutdown-Handler zwingend berücksichtigen, sonst verlieren Sie ungespeicherte Arbeit.
