Spot instanciák teljes útmutatója 2026-ban: akár 90% megtakarítás AWS-en, Azure-on és GCP-n

Bevezetés: miért a spot instanciák a felhőköltség-csökkentés titkos fegyvere?

Ha egyetlen mondatban kellene összefoglalnom a felhőszámítástechnika legegyszerűbb költségcsökkentési trükkjét, az bizony a spot instanciák használata lenne. 2026-ban a globális felhőköltés átlépte az 1 billió dolláros határt, miközben a vállalatok átlagosan 30–35%-ot simán kidobnak az ablakon a felhőbüdzséjükből. Elég fájdalmas szám, nem?

Na de itt jönnek a képbe a spot instanciák, amelyek akár 60–91%-os megtakarítást hozhatnak az on-demand árakhoz képest.

De mi is pontosan egy spot instancia? Egyszerűen fogalmazva: a felhőszolgáltatók (AWS, Azure, Google Cloud) a ki nem használt számítási kapacitásukat kedvezményes áron adják oda. Cserébe viszont bármikor visszavehetik ezeket az erőforrásokat — jellemzően 30 másodperces vagy 2 perces előzetes értesítéssel. Tehát ugyanazt a teljesítményt kapjuk, mint egy on-demand instanciánál, csak töredék áron. Szinte túl szép, hogy igaz legyen — és őszintén szólva, van is néhány csapda, amiről beszélnünk kell.

Ebben az útmutatóban végigmegyünk azon, hogyan működnek a spot instanciák mindhárom nagy felhőszolgáltatónál, hogyan kezeljük a megszakításokat, milyen munkaterhelésekhez ideálisak, és hogyan integrálhatók Kubernetes-környezetekbe. Konkrét kódpéldákat és konfigurációkat is adunk, amiket azonnal használatba lehet venni.

Spot instanciák szolgáltatónként: AWS, Azure és GCP összehasonlítása

AWS EC2 Spot Instances

Az AWS spot instanciái a legrégebbi és legérettebb megoldás a piacon. Évek óta itt tartanak az élen. A legfontosabb tudnivalók:

• Megtakarítás: akár 90% az on-demand árakhoz képest
• Megszakítási értesítés: 2 perces figyelmeztetés az instancia visszavétele előtt
• Allokációs stratégia: price-capacity-optimized (ár-kapacitás-optimalizált) — az AWS automatikusan a legjobb ár-kapacitás arányú instanciákat választja ki
• Szolgáltatások: EC2, ECS, EKS, EMR, SageMaker, AWS Batch

2026 januárjában az AWS bevezette az EC2 Capacity Manager Spot megszakítási metrikákat, amivel végre részletes képet kaphatunk a spot kapacitásról. Három új metrika érhető el: a futó spot instanciák száma (Spot Total Count), a megszakítások száma (Spot Total Interruptions) és a megszakítási arány (Spot Interruption Rate). Ez az összes kereskedelmi AWS-régióban elérhető, alapértelmezetten engedélyezve, és ami a legjobb: külön költség nélkül.

Az alábbi Python-szkript segítségével lekérdezhetjük az aktuális spot árakat egy adott régióban:

import boto3
from datetime import datetime, timezone, timedelta

ec2 = boto3.client('ec2', region_name='eu-central-1')

response = ec2.describe_spot_price_history(
    InstanceTypes=['m5.xlarge', 'm5.2xlarge', 'm6i.xlarge', 'm6i.2xlarge'],
    ProductDescriptions=['Linux/UNIX'],
    StartTime=datetime.now(timezone.utc) - timedelta(hours=6),
    MaxResults=50
)

for price in response['SpotPriceHistory']:
    print(f"{price['InstanceType']} | {price['AvailabilityZone']} | "
          f"${price['SpotPrice']}/óra | {price['Timestamp']}")

Azure Spot VMs

Az Azure spot virtuális gépei hasonló elven működnek, de van néhány fontos különbség, amire érdemes odafigyelni:

• Megtakarítás: akár 90% az on-demand árakhoz képest
• Megszakítási értesítés: mindössze 30 másodperc (igen, ez fele annyi, mint az AWS-nél)
• Kilakoltatási szabályzat: választhatunk a deallokáció (VM megőrzése leállított állapotban) és a törlés között
• Maximális ár beállítása: megadhatunk egy felső árhatárt, amelyet nem vagyunk hajlandóak meghaladni

Érdekes módon az Azure spot VMs a 2025 Kubernetes Cost Benchmark Report szerint stabilabb a megszakítások szempontjából, mint az AWS — kevesebb megszakítást tapasztaltak az összes mért időszakban, különösen az első 12 órában. Ez sokakat meglephet, de a számok magukért beszélnek.

Azure spot VM létrehozása az Azure CLI-vel:

az vm create \
  --resource-group MyResourceGroup \
  --name MySpotVM \
  --image Ubuntu2204 \
  --size Standard_D4s_v5 \
  --priority Spot \
  --eviction-policy Deallocate \
  --max-price 0.08 \
  --admin-username azureuser \
  --generate-ssh-keys

Google Cloud Spot VMs

A Google Cloud spot virtuális gépei (amelyek a korábbi Preemptible VM-eket váltották le) néhány egyedi sajátossággal bírnak:

• Megtakarítás: fix 60–91% kedvezmény az on-demand árakhoz képest
• Megszakítási értesítés: 30 másodperc
• Fix árazás: a GCP spot árak nem ingadoznak a kereslet-kínálat alapján — ez kiszámítható költségeket jelent, ami a tervezés szempontjából hatalmas előny
• Nincs maximális futásidő-korlát: a régi Preemptible VM-ekhez képest (amelyeknek 24 órás limitjük volt) a Spot VM-ek korlátlan ideig futhatnak

GCP Spot VM létrehozása a gcloud CLI-vel:

gcloud compute instances create my-spot-vm \
  --zone=europe-west1-b \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --maintenance-policy=TERMINATE \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Megszakítások kezelése: a spot instanciák legnagyobb kihívása

Rendben, beszéljünk a spot instanciák árnyoldaláról. A legnagyobb kockázat egyértelműen a megszakítás — a felhőszolgáltató bármikor visszaveheti az instanciát, ha szüksége van a kapacitásra. Az AWS-statisztikák szerint a megszakítási arány átlagosan 5% alatt marad havonta, de ez instanciatípusonként, régiónként és rendelkezésre állási zónánként nagyon eltérő lehet.

A GPU-alapú spot instanciáknál — különösen az H100-asoknál — a helyzet drasztikusabb: a megszakítási arány elérheti a 20%-ot is, mivel az AI/ML munkaterhelések iránti kereslet folyamatosan nő. Ezt érdemes szem előtt tartani, ha GPU-intenzív feladatokra tervezünk spotot.

Megszakítás-kezelési stratégiák

Az alábbi Python-szkript egy egyszerű megszakítás-kezelőt valósít meg AWS-en. Figyeli a spot megszakítási értesítéseket és lefuttat egy graceful shutdown folyamatot:

import requests
import time
import signal
import sys

METADATA_URL = "http://169.254.169.254/latest/meta-data/spot/instance-action"
CHECK_INTERVAL = 5  # másodperc

def graceful_shutdown():
    """Alkalmazás-specifikus leállítási logika"""
    print("Spot megszakítás észlelve! Graceful shutdown indítása...")
    # Folyamatban lévő feladatok mentése
    # Kapcsolatok lezárása
    # Checkpoint létrehozása
    print("Shutdown befejezve.")
    sys.exit(0)

def check_spot_interruption():
    """Spot megszakítási értesítés figyelése"""
    while True:
        try:
            # IMDSv2 token lekérése
            token_response = requests.put(
                "http://169.254.169.254/latest/api/token",
                headers={"X-aws-ec2-metadata-token-ttl-seconds": "300"},
                timeout=2
            )
            token = token_response.text

            response = requests.get(
                METADATA_URL,
                headers={"X-aws-ec2-metadata-token": token},
                timeout=2
            )

            if response.status_code == 200:
                action = response.json()
                print(f"Megszakítási értesítés: {action}")
                graceful_shutdown()

        except requests.exceptions.RequestException:
            pass  # Nincs megszakítási értesítés

        time.sleep(CHECK_INTERVAL)

if __name__ == "__main__":
    signal.signal(signal.SIGTERM, lambda s, f: graceful_shutdown())
    check_spot_interruption()

Bevált gyakorlatok a megszakítások kezelésére

Az évek során kialakult néhány alapszabály, amit érdemes betartani:

1. Instanciatípus-diverzifikáció: Használjunk legalább 10–15 különböző instanciatípust. Minél szélesebb a választék, annál kisebb az egyidejű megszakítás esélye. Ez az egyik legfontosabb szabály.
2. Rendelkezésre állási zónák szétterítése: Osszuk el az erőforrásainkat több zóna között, hogy egyetlen zóna kapacitásproblémája ne vigye magával az összes instanciánkat.
3. Checkpointing: Hosszabb futású feladatoknál (például ML-tanítás) rendszeresen mentsük el az aktuális állapotot. Így megszakítás esetén nem kell nulláról kezdeni az egészet.
4. Graceful shutdown: Minden alkalmazásnak legyen tiszta leállítási folyamata, ami a megszakítási értesítés után lefut. Két percből (vagy 30 másodpercből) sokat ki lehet hozni, ha előre felkészültünk.
5. On-demand fallback: A kritikus alapkapacitást on-demand vagy reserved instanciákra helyezzük, a spot-ot pedig csak a burst kapacitáshoz használjuk. Ne tegyük fel az egészet egyetlen lapra.

Spot instanciák Kubernetes-környezetben: EKS, AKS és GKE

A Kubernetes és a spot instanciák szinte egymásnak lettek teremtve. A konténerizált, állapotmentes podok ephemerisek és könnyen áthelyezhetők — pontosan az, amire szükségünk van a spot megszakítások kezeléséhez.

AWS EKS + Karpenter: az ajánlott megoldás 2026-ban

A Karpenter egy nyílt forráskódú Kubernetes autoscaler, amit az AWS fejlesztett ki, és ami 2026-ban egyértelműen a legjobb megoldás spot instanciák kezelésére EKS-en. A hagyományos Cluster Autoscaler-rel szemben a Karpenter gyorsabb, rugalmasabb, és natív spot-támogatással rendelkezik.

Lássuk a gyakorlatban. Az alábbi Karpenter NodePool konfiguráció spot és on-demand instanciákat egyaránt kezel:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-optimized
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.xlarge
            - m5.2xlarge
            - m5a.xlarge
            - m5a.2xlarge
            - m6i.xlarge
            - m6i.2xlarge
            - m6a.xlarge
            - m6a.2xlarge
            - m7i.xlarge
            - m7i.2xlarge
            - c5.xlarge
            - c5.2xlarge
            - c6i.xlarge
            - c6i.2xlarge
            - r5.xlarge
        - key: topology.kubernetes.io/zone
          operator: In
          values:
            - eu-central-1a
            - eu-central-1b
            - eu-central-1c
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s
  limits:
    cpu: "200"
    memory: 800Gi

A Karpenter spot-kezelési képességei igazán lenyűgözőek:

• Spot-to-Spot konszolidáció: Automatikusan lecseréli a spot node-okat olcsóbb spot instanciákra, amikor azok elérhetővé válnak. Ehhez érdemes legalább 15 különböző instanciatípust megadni a konfigurációban.
• Natív megszakítás-kezelés: SQS-soron és EventBridge-en keresztül kezeli a 2 perces spot értesítéseket — nem szükséges külön Node Termination Handler.
• Automatikus fallback: Ha spot kapacitás nem érhető el, automatikusan on-demand instanciákat indít. Nem kell kézzel beavatkoznunk.

Azure AKS spot node pool

Az AKS-ben dedikált spot node pool-okat hozhatunk létre. Íme a parancs:

az aks nodepool add \
  --resource-group MyResourceGroup \
  --cluster-name MyAKSCluster \
  --name spotnodepool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-count 3 \
  --min-count 1 \
  --max-count 10 \
  --enable-cluster-autoscaler \
  --node-vm-size Standard_D4s_v5 \
  --labels kubernetes.azure.com/scalesetpriority=spot \
  --node-taints kubernetes.azure.com/scalesetpriority=spot:NoSchedule

A taint biztosítja, hogy csak a spot-toleráns podok kerüljenek ezekre a node-okra. A --spot-max-price -1 beállítás azt jelenti, hogy az aktuális on-demand árig hajlandóak vagyunk fizetni — ez maximalizálja a rendelkezésre állást, ami általában a jó választás.

Google GKE spot node pool

A GKE-ben a spot node pool létrehozása szintén egyszerű:

gcloud container node-pools create spot-pool \
  --cluster=my-cluster \
  --zone=europe-west1-b \
  --spot \
  --num-nodes=3 \
  --min-nodes=1 \
  --max-nodes=10 \
  --enable-autoscaling \
  --machine-type=n2-standard-4 \
  --node-taints=cloud.google.com/gke-spot=true:NoSchedule

Pod Disruption Budget: a munkaterhelések védelme

Akármelyik szolgáltatót is használjuk, a Pod Disruption Budget (PDB) konfigurálása elengedhetetlen. Ez biztosítja, hogy a spot megszakítások során mindig legyen elegendő futó replika — vagyis a felhasználók nem fognak semmit észrevenni:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-application

Mikor használjunk spot instanciákat — és mikor ne?

Ideális munkaterhelések

A spot instanciák remekül működnek az alábbi esetekben:

• CI/CD pipeline-ok: A build és teszt feladatok rövid életűek és állapotmentesek. Ha egy node eltűnik, a pipeline egyszerűen újrafut.
• Batch feldolgozás: Adattranszformációk, ETL-folyamatok, jelentéskészítés — ezek párhuzamosíthatók és gond nélkül újraindíthatók.
• ML-modell tanítás: Checkpointing mellett a tanítás folytatható megszakítás után. A GPU spot instanciák különösen nagy megtakarítást hoznak (bár ott magasabbak a megszakítási arányok is, ahogy említettük).
• Állapotmentes webes szolgáltatások: Load balancer mögött futó, horizontálisan skálázható alkalmazások. Ha kiesik egy instancia, a többi átveszi a forgalmat.
• Adatelemzés és big data: Spark, Hadoop és hasonló keretrendszerek natívan tolerálják a node-vesztést.

Kerülendő esetek

Viszont van néhány eset, amikor a spot egyáltalán nem jó ötlet:

• Állapottartó adatbázisok: Relációs adatbázisok, amelyek konzisztens rendelkezésre állást igényelnek. Egy váratlan megszakítás itt katasztrofális lehet.
• Singleton szolgáltatások: Ha egyetlen instancia futtatja a kritikus üzleti logikát, a spot megszakítás azonnali szolgáltatáskiesést jelent.
• Alacsony latenciájú, valós idejű rendszerek: Ahol még a 30 másodperces–2 perces átállási idő sem elfogadható.

Költségoptimalizálási összehasonlítás: spot vs. reserved vs. savings plans

A felhőköltségek csökkentéséhez nem egyetlen módszert kell választanunk — a rétegzett megközelítés hozza a legjobb eredményeket. Személyes tapasztalatom alapján a legtöbb csapat akkor jár a legjobban, ha kombinálják ezeket az opciókat:

Jellemző	Spot instanciák	Reserved Instances	Savings Plans
Megtakarítás mértéke	60–91%	Akár 75%	Akár 72%
Kötelezettség	Nincs	1 vagy 3 év	1 vagy 3 év
Megszakítás kockázata	Igen	Nem	Nem
Rugalmasság	Magas	Alacsony (Standard) / Közepes (Convertible)	Magas
Kapacitás-foglalás	Nem	Igen	Nem
Ideális eset	Fault-toleráns, állapotmentes	Stabil, kiszámítható terhelés	Változó, multi-service terhelés

Az ajánlott stratégia 2026-ban: az alapkapacitást Reserved Instances-szel vagy Savings Plans-szel fedjük le (ez a stabil, kiszámítható terhelés), a burst és változó kapacitást pedig spot instanciákkal bővítjük. A 2025 Kubernetes Cost Benchmark Report szerint a vegyes (on-demand + spot) klaszterek átlagosan 59%-os megtakarítást értek el, míg a tisztán spot klaszterek 77%-osat. Ezek nem elhanyagolható számok.

Gyakran ismételt kérdések (GYIK)

Mennyit lehet ténylegesen megtakarítani spot instanciákkal?

A megtakarítás mértéke szolgáltatónként és instanciatípusonként változik. Az AWS-en akár 90%, az Azure-on akár 90%, a GCP-n 60–91% megtakarítás érhető el az on-demand árakhoz képest. A gyakorlatban, vegyes (spot + on-demand) környezetben átlagosan 59%-os, tisztán spot környezetben 77%-os költségcsökkenés várható a 2025-ös benchmarkok alapján.

Mi történik, ha a felhőszolgáltató megszakítja a spot instanciámat?

A szolgáltató előzetes értesítést küld: az AWS 2 percet, az Azure és a GCP 30 másodpercet biztosít. Ezalatt az alkalmazásnak le kell futtatnia a graceful shutdown folyamatot — menteni a folyamatban lévő munkát, lezárni a kapcsolatokat és szükség esetén checkpointot készíteni. Kubernetes-környezetben az orchestrátor automatikusan átütemezi a podokat más elérhető node-okra, szóval ha jól van beállítva a klaszter, a felhasználók nem is fogják észrevenni.

Használhatom-e spot instanciákat éles (production) környezetben?

Igen, de kizárólag fault-toleráns, állapotmentes munkaterhelésekhez. A kulcs a megfelelő architektúra: horizontális skálázás, Pod Disruption Budgetek, instanciatípus-diverzifikáció és automatikus fallback on-demand kapacitásra. Állapottartó adatbázisokhoz és singleton szolgáltatásokhoz továbbra is on-demand vagy reserved instanciákat használjunk.

Melyik felhőszolgáltató spot megoldása a legjobb?

Őszintén? Ez attól függ, mire használjuk. Az AWS a legérettebb ökoszisztémával rendelkezik (Karpenter, Spot Fleet, EC2 Capacity Manager), az Azure stabilabb megszakítási arányokat mutat, a GCP pedig fix, kiszámítható árazást kínál. Ha multicloud környezetben dolgozunk, érdemes mindhárom szolgáltató spot kapacitását kihasználni — a diverzifikáció itt is kifizetődik.

Hogyan csökkenthetem a spot megszakítások kockázatát?

A legfontosabb lépések: használjunk legalább 10–15 különböző instanciatípust, osszuk el az erőforrásokat több rendelkezésre állási zónába, alkalmazzunk automatikus fallback mechanizmust (például Karpenter az AWS-en), és implementáljunk checkpointing-ot hosszabb futású feladatokhoz. Az AWS Spot Instance Advisor és az EC2 Capacity Manager megszakítási metrikái sokat segítenek a legstabilabb instanciatípusok kiválasztásában.