Spot VMs w 2026: porównanie AWS, Azure i GCP – koszty, wskaźniki przerwań i najlepsze workloady

Zaktualizowano: 29 sierpnia 2026

Spot VMs w 2026 roku oferują od 60% do 91% zniżki wobec cen on-demand w AWS, Azure i GCP, ale realny wybór dostawcy zależy od wskaźnika przerwań (interruption rate), granularności rozliczeń oraz tego, jak dobrze twój workload znosi ewikcje z 30- lub 60-sekundowym uprzedzeniem. W ostatnim projekcie dla klienta z branży fintech spaliłam dwa tygodnie na debugowaniu evictions AKS-a i sporo z tego, co pokazuję niżej, wynika z tamtej lekcji. W tym przewodniku zestawiam trzy platformy obok siebie (ceny, mechanikę przerwań, integrację z Kubernetes) i realne case'y, w których jeden dostawca wygrywa z pozostałymi. Bez marketingowego lakieru: pokazuję też, kiedy Spot nie ma sensu i lepiej sięgnąć po Savings Plans lub CUD-y.

• AWS Spot średnio 60–90% taniej od on-demand, z 2-minutowym powiadomieniem o przerwaniu i dokładnością rozliczeń per sekundę (min. 60 s).
• Azure Spot oferuje do 90% zniżki, ale tylko 30-sekundowe powiadomienie i opcjonalną „max price" – ryzyko przerwania jest wyższe w regionach z niską pojemnością.
• GCP Spot VMs (dawniej Preemptible) daje 60–91% zniżki, brak limitu 24h (usunięty w 2022), i standardowe 30-sekundowe powiadomienie SIGTERM.
• Dla obciążeń stateless, CI/CD, batch ML training i renderowania Spot to bezdyskusyjny wybór – oszczędność 70%+ przy prawidłowej obsłudze evictions.
• W Kubernetes użyj Karpenter (AWS) lub Cluster Autoscaler z multiple node pools (GKE/AKS), aby automatycznie mieszać Spot i on-demand.
• Nigdy nie stawiaj na Spot: baz danych stateful bez replikacji, licencjonowanego oprogramowania per-VM oraz workloadów real-time z twardym SLA.

Czym są Spot VMs i jak działa model cenowy w 2026?

Spot VMs to zapasowa pojemność chmury sprzedawana z dużym rabatem w zamian za akceptację, że dostawca może odebrać instancję z krótkim uprzedzeniem, gdy zapotrzebowanie on-demand w danym regionie i typie maszyny rośnie. Nazywam to „pojemnością drugiej szansy" – to te same fizyczne serwery, na których działają maszyny on-demand, tyle że sprzedawane po cenie zmiennej, ustalanej przez podaż i popyt w każdej strefie dostępności.

W 2026 roku wszystkie trzy hyperskalery ustabilizowały modele cenowe. AWS zrezygnował z aukcyjnych „bid prices" jeszcze w 2017 i teraz publikuje ceny Spot, które zmieniają się co godzinę na podstawie popytu. Azure zachował opcjonalny mechanizm „max price" – jeśli ustawisz limit powyżej ceny bieżącej, VM zostanie zachowana, dopóki popyt on-demand nie wymusi ewikcji. GCP używa stałej ceny Spot w danym regionie/typie, aktualizowanej co miesiąc, co jest najbardziej przewidywalne dla planowania FinOps.

Warto zapamiętać jedną rzecz: Spot to nie to samo co Preemptible. GCP zmienił nazwę „Preemptible VMs" na „Spot VMs" w 2021 i jednocześnie usunął sztywny limit 24 godzin życia instancji. Dzisiaj GCP Spot VM może żyć w nieskończoność, dopóki nie zostanie preemptowany – to dramatyczna zmiana operacyjna wobec starego modelu.

Porównanie cen: AWS Spot vs Azure Spot vs GCP Spot

Poniżej zestawienie na przykładzie porównywalnych maszyn ogólnego przeznaczenia (~8 vCPU / 32 GB RAM) w regionach europejskich (Frankfurt / West Europe / europe-west3). Ceny to średnie z sierpnia 2026 – sprawdzaj bieżące stawki przed decyzją, bo Spot fluktuuje.

Wymiar	AWS EC2 Spot	Azure Spot VM	GCP Spot VM
Typ maszyny (przykład)	m6i.2xlarge	D8s v5	n2-standard-8
Cena on-demand (USD/h)	0,384	0,392	0,388
Cena Spot (USD/h, średnia)	0,061 (~84% zniżki)	0,047 (~88% zniżki)	0,093 (~76% zniżki)
Powiadomienie o przerwaniu	2 minuty	30 sekund	30 sekund (SIGTERM)
Granularność rozliczeń	per sekundę (min. 60 s)	per sekundę	per sekundę (min. 60 s)
Mechanizm limitu ceny	opcjonalny (spot request)	opcjonalny „max price"	brak (cena stała miesięcznie)
Maks. czas życia	bez limitu	bez limitu (od 2020)	bez limitu (od 2022)
Dostępność GPU Spot	tak (p4, g5, g6)	tak (NC, ND – ograniczone)	tak (A2, G2, A3)

Kilka obserwacji z terenu: Azure zwykle wygrywa cenowo na maszynach D/E-series, ale traci na GPU – pojemność Spot dla NC/ND jest sporadyczna w europejskich regionach. AWS ma najszerszy katalog rodzin dostępnych w Spot (przez capacity-optimized allocation strategy) oraz największą deep pool pojemności zapasowej. GCP jest droższy per rdzeń, ale bezkonkurencyjny w przewidywalności – ta sama cena Spot przez cały miesiąc upraszcza forecasting w FinOps.

Wskaźniki przerwań – który dostawca jest stabilniejszy?

Cena to tylko połowa równania. Druga połowa to interruption rate – jak często faktycznie odbierają ci maszynę. Dane, które publikują dostawcy, to średnie 30-dniowe per typ instancji i region.

AWS udostępnia Spot Placement Score i publiczny Spot Instance Advisor z bucketem „<5%", „5–10%", „10–15%", „15–20%" i „>20%" częstości przerwań. W 2026 dla popularnych rodzin (m6i, c6i, r6i) we Frankfurcie widujemy zwykle 3–7% – bardzo stabilnie. Rzadsze typy (m6a.16xlarge) potrafią skoczyć do 15–20% w godzinach szczytu.

Azure w portalu pokazuje „eviction rate" w tych samych widełkach. W West Europe standardowe D-series trzymają się poniżej 10%, ale H-series (HPC) i NC-series (GPU) potrafią przekraczać 20% w tygodniach z dużym zapotrzebowaniem AI. Mój benchmark: Azure jest bardziej „szarpany" niż AWS – długie okresy stabilności przerywane nagłymi falami evictions.

GCP nie publikuje wskaźników publicznie, ale doświadczalnie n2-standard i e2-standard w europe-west3 utrzymują się w okolicach 5–12%. GCP wprowadził jednak nową opcję Spot VM z reservation affinity w połowie 2025, która pozwala Spot korzystać z niewykorzystanej zarezerwowanej pojemności – daje to ~50% niższą częstość przerwań kosztem lekko wyższej ceny.

Jak obsługiwać przerwania Spot w praktyce?

Prawidłowa obsługa evictions decyduje o tym, czy Spot oszczędza ci 70% budżetu, czy generuje incydent produkcyjny. Wzorzec jest identyczny u wszystkich trzech dostawców: nasłuchuj metadata endpoint, wykonaj graceful shutdown, przekaż pracę dalej.

Dla AWS metadata endpoint zwraca instrukcję spot/instance-action gdy nadchodzi przerwanie. Poniżej minimalny handler w Pythonie, który odczytuje sygnał i uruchamia procedurę odłączenia workloadu:

# spot_watcher.py – lekki daemon monitorujący sygnał przerwania AWS Spot
import time
import requests
import subprocess

METADATA_URL = "http://169.254.169.254/latest/meta-data/spot/instance-action"
TOKEN_URL = "http://169.254.169.254/latest/api/token"

def get_imdsv2_token():
    # IMDSv2 jest wymagane od 2024 – bez tokena metadata zwraca 401
    resp = requests.put(
        TOKEN_URL,
        headers={"X-aws-ec2-metadata-token-ttl-seconds": "21600"},
        timeout=2,
    )
    return resp.text

def check_interruption(token):
    resp = requests.get(
        METADATA_URL,
        headers={"X-aws-ec2-metadata-token": token},
        timeout=2,
    )
    # 404 = wszystko OK, brak przerwania. 200 = mamy 2 minuty.
    return resp.status_code == 200

def drain_workload():
    # Zdejmij node z pool loadbalancera, zakończ aktualne zadania,
    # wyślij metryki do CloudWatch i wykonaj commit stanu do S3.
    subprocess.run(["/opt/scripts/graceful-drain.sh"], check=False)

def main():
    token = get_imdsv2_token()
    while True:
        if check_interruption(token):
            print("Otrzymano sygnał Spot interruption – rozpoczynam drain.")
            drain_workload()
            break
        time.sleep(5)

if __name__ == "__main__":
    main()

Dla Azure ekwiwalent to endpoint http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01 zwracający zdarzenia typu Preempt. Dla GCP to http://metadata.google.internal/computeMetadata/v1/instance/preempted z nagłówkiem Metadata-Flavor: Google, plus dodatkowo system wysyła SIGTERM do wszystkich procesów PID 1. W Kubernetes tę pracę wykonują za ciebie Karpenter disruption controllers lub AWS Node Termination Handler dla Cluster Autoscaler.

Które workloady najlepiej pasują do Spot VMs?

Po pięciu latach benchmarkowania multi-cloud utrzymuję prostą listę: Spot świetnie sprawdza się tam, gdzie praca jest podzielna na małe porcje z checkpointami, a strata pojedynczej maszyny nie kosztuje więcej niż 5 minut przeliczeń.

Świetne dopasowanie do Spot:

• Trenowanie ML z checkpointami co N kroków (np. PyTorch Lightning, HuggingFace Trainer) – GPU Spot na A100/H100 daje 60–70% oszczędności wobec on-demand.
• Rendering wideo/3D w batch (Blender, Nuke, Houdini) – zadania są stateless i naturalnie retriable.
• CI/CD workery – GitHub Actions self-hosted runners, GitLab runners, Jenkins agents.
• Przetwarzanie danych typu Spark/Ray/Dask, gdy używasz frameworków z tolerancją na utratę węzła.
• Stateless web frontendy za load balancerem, gdy autoscaler potrafi szybko dodać pojemność zastępczą.

Złe dopasowanie do Spot:

• Pojedyncze bazy danych bez replikacji (PostgreSQL primary, MongoDB standalone).
• Workloady z licencjami per-VM lub per-core, gdzie restart kasuje aktywację (niektóre wersje SAP, Oracle).
• Gaming servers z sesjami w pamięci trwającymi >30 min.
• Systemy real-time z twardym SLA <100 ms latency i bez fallbacku on-demand.

Konkretnie dla obciążeń AI/ML polecam głęboki materiał o FinOps dla obciążeń AI/ML i optymalizacji GPU w chmurze – tam pokazuję pełny wzór na break-even Spot vs on-demand dla treningu H100.

Spot vs Reserved Instances vs Savings Plans – kiedy używać czego?

Najczęstsze pytanie od zespołów FinOps: „Skoro Spot daje 80% zniżki, po co komukolwiek Savings Plans?". Odpowiedź: bo Spot i commit-based discounts rozwiązują różne problemy. Spot to zniżka za elastyczność (godzę się stracić maszynę), Savings Plans/RI to zniżka za zobowiązanie (obiecuję wydać X przez 1 lub 3 lata).

W praktyce budujemy warstwową strategię pojemności: Reserved Instances / Savings Plans na 60–70% baseline'u (rzeczy, które i tak będą działać 24/7), on-demand na 10–15% burst i Spot na 20–30% pojemności elastycznej. Nakładam ten wzór na klienta produkującego wideo w Warszawie i schodzimy z 47 tys. USD/mies do 18 tys. USD/mies – większa część oszczędności pochodzi od Spot na farmie renderującej, ale bez commit-based discounts na infra kontrolną (bazy, orkiestracja) całość by się posypała.

Szczegółowe porównanie modeli commit-based dla AWS opisałam w artykule AWS Savings Plans vs Reserved Instances 2026. Analogiczne mechanizmy w Azure to Reservations + Savings Plans for compute (wprowadzone w 2022), a w GCP – Committed Use Discounts (CUD-y) resource-based i spend-based (te ostatnie od 2023).

Spot w Kubernetes: Karpenter, Cluster Autoscaler i node pools

Kubernetes to naturalne środowisko dla Spot, bo scheduler i tak zakłada, że pody mogą być przeniesione. Trzy dostawcy oferują różne tooling:

AWS + EKS: od 2024 rekomendacją jest Karpenter zamiast Cluster Autoscaler. Karpenter samodzielnie wybiera najtańsze rodziny Spot spełniające constraints poda, robi bin-packing i automatycznie zamienia węzły podczas evictions. Poniżej przykładowa konfiguracja NodePool, która preferuje Spot z fallbackiem na on-demand:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: batch-workers
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]  # spot z fallbackiem
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m6i", "m6a", "m7i", "c6i", "c7i"]
        - key: karpenter.k8s.aws/instance-size
          operator: In
          values: ["2xlarge", "4xlarge", "8xlarge"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: "1000"

Azure + AKS: stwórz osobny node pool ze --priority Spot --eviction-policy Delete. Cluster Autoscaler skaluje pool niezależnie. Użyj nodeSelector: kubernetes.azure.com/scalesetpriority: spot w podach, żeby scheduler świadomie kładł tam workload.

GCP + GKE: tworzysz node pool z --spot (Autopilot ma dedykowaną klasę Spot od 2023). GKE dodaje automatycznie taint cloud.google.com/gke-spot=true:NoSchedule, więc pody muszą mieć jawny toleration. To dobra domyślna higiena – zabezpiecza cię przed przypadkowym zaparkowaniem stateful poda na Spot.

Głębiej temat Kubernetes cost opisuję w przewodniku po optymalizacji kosztów Kubernetes – tam pokazuję również, jak łączyć Spot z KEDA i skalowaniem na podstawie kolejek SQS/PubSub/ServiceBus.

FinOps: mierzenie oszczędności i governance dla Spot

Bez pomiaru Spot to hazard, nie strategia. Trzy metryki, które trzymam na dashboardzie klienta:

1. Spot coverage % – ile godzin vCPU pochodzi ze Spot / całkowite godziny vCPU. Cel: 30–50% dla platform dev/test, 15–25% dla produkcji ogólnej.
2. Effective savings vs on-demand – (godziny × cena on-demand) − (godziny × cena Spot). Raportuj miesięcznie, bo cena Spot się zmienia.
3. Interruption impact – ile zadań musieliśmy zrestartować / wznowić z checkpointa w danym tygodniu. Jeśli >5% zadań, twój Spot mix jest za agresywny.

Do raportowania używaj natywnych narzędzi: AWS Cost Explorer ma widok „Purchase option: Spot", Azure Cost Management ma filtr PricingModel = Spot, GCP Billing eksportuje flagę usage_end_time per SKU (Spot ma osobne SKU). W FOCUS 1.1 (FinOps Open Cost and Usage Specification, listopad 2025) wszystkie trzy chmury raportują Spot jednolicie w kolumnie PricingCategory=Dynamic – to znacznie upraszcza raporty multi-cloud. Dokumentacja specyfikacji dostępna jest w FinOps FOCUS project.

Ostatnia rada: przypnij governance policy w kodzie. Terraform + Sentinel, Azure Policy albo GCP Organization Policy – wymuszaj, żeby produkcyjne workloady miały tag spot-allowed=true zanim jakikolwiek Spot request przejdzie. Dobra referencja to dokumentacja AWS Spot Fleet, która pokazuje wzorce allocation strategies (capacity-optimized, price-capacity-optimized) – ta druga jest domyślną rekomendacją AWS od 2023 i minimalizuje wskaźnik przerwań przy dobrej cenie.

Najczęściej zadawane pytania

Ile realnie można zaoszczędzić na Spot VMs w 2026?

Realistyczne oszczędności to 60–85% wobec on-demand, jeśli twój workload toleruje przerwania i masz zbudowaną obsługę graceful shutdown. Reklamowane 90% zniżki zdarzają się głównie w rzadszych rodzinach maszyn poza godzinami szczytu. Zaplanuj model finansowy na 70% oszczędności, żeby mieć bufor.

Czy Spot VMs nadają się do produkcji?

Tak, ale tylko dla warstw stateless z autoscalerem i replikacją. Nigdy nie kładź na Spot pojedynczej bazy danych, węzła kontrolnego Kubernetesa ani workloadu z twardym SLA latencji. Sprawdza się natomiast dla web tier za load balancerem, kolejek workerów i renderowania.

Jaka jest różnica między Spot VMs a Preemptible VMs w GCP?

Preemptible VMs to poprzednia nazwa – w 2021 GCP przemianował je na Spot VMs i usunął twardy limit 24 godzin życia instancji. Dzisiaj GCP Spot VM może działać bez limitu, dopóki nie zostanie preemptowana. Zniżki wzrosły też do 60–91% wobec dawnych 80%.

Który dostawca ma najniższy wskaźnik przerwań Spot?

W europejskich regionach AWS zwykle wygrywa dzięki najgłębszej puli zapasowej i strategii capacity-optimized allocation, utrzymując 3–7% dla popularnych rodzin. Azure jest tańszy per godzinę, ale bardziej „szarpany". GCP z opcją reservation affinity od 2025 dogonił AWS w stabilności.

Czy warto mieszać Spot z Reserved Instances i Savings Plans?

Zdecydowanie tak – to najbardziej efektywna kosztowo strategia. Pokryj 60–70% baseline'u zobowiązaniami (RI/SP/CUD), 10–15% zostaw jako on-demand na burst i 20–30% pojemności elastycznej przenieś na Spot. Taki miks minimalizuje ryzyko przerwań i maksymalizuje zniżkę.