Spot Instances Multi-Cloud: Ghid Practic AWS, Azure și GCP cu Strategii Anti-Întrerupere

De Ce Spot Instances Sunt Cel Mai Subestimat Instrument de Economisire Cloud

Imaginează-ți că plătești 10 lei pentru un serviciu care costă în mod normal 100 de lei. Sună prea frumos ca să fie adevărat, nu? Ei bine, cam asta oferă Spot Instances — acces la capacitate de calcul cloud la reduceri de până la 90% față de prețurile on-demand. Și cu toate astea, mai puțin de 20% din organizații le folosesc sistematic.

Motivul? Frica de întreruperi. Furnizorii cloud pot revendica aceste resurse oricând au nevoie de capacitate.

Dar hai să fim sinceri — cu arhitectura potrivită și instrumentele corecte, această „frică" devine un non-eveniment. În 2026, instrumentele de gestionare a întreruperilor au evoluat atât de mult încât Spot Instances sunt folosite chiar și în workload-uri de producție, nu doar în medii de dev unde nimeni nu observă dacă pică ceva.

Ghidul ăsta acoperă tot ce ai nevoie: cum funcționează Spot Instances pe AWS, Azure și GCP, strategii concrete de gestionare a întreruperilor cu exemple de cod funcționale pe care le poți adapta direct, și un framework decizional care te ajută să alegi workload-urile potrivite. Deci, hai să intrăm direct în subiect.

Cum Funcționează Spot Instances pe Fiecare Furnizor Cloud

Conceptul de bază e identic la toți trei: capacitate de calcul nefolosită oferită la preț redus. Diferențele apar în mecanismul de preaviz și politicile de evacuare — și, sincer, diferențele contează destul de mult în practică.

AWS EC2 Spot Instances

AWS oferă cel mai matur ecosistem de Spot Instances din piață. Iată punctele cheie:

• Reducere: Până la 90% față de On-Demand
• Preaviz de întrerupere: 2 minute (prin Instance Metadata Service sau EventBridge)
• Acțiuni la întrerupere: Terminate, Stop sau Hibernate
• Instrument nativ: EC2 Spot Fleet, EC2 Auto Scaling cu instanțe mixte
• Strategie de alocare: capacity-optimized (recomandată), lowest-price, diversified

Un avantaj pe care merită să-l menționez: AWS oferă Capacity Rebalancing, care detectează proactiv instanțele cu risc crescut de întrerupere și le înlocuiește înainte de întreruperea efectivă. Practic, cloud-ul face treaba grea în locul tău.

Azure Spot Virtual Machines

Azure a simplificat modelul de Spot VM-uri, dar vine cu câteva particularități de care trebuie să ții cont:

• Reducere: Până la 90% față de pay-as-you-go
• Preaviz de evacuare: Doar 30 de secunde (cel mai scurt din cei trei furnizori — da, ai citit bine)
• Tipuri de evacuare: Capacity-only sau Price-or-capacity
• Politici de evacuare: Deallocate (implicit) sau Delete
• Instrument nativ: VM Scale Sets cu suport Spot

Preavizul de doar 30 de secunde face ca designul pentru fault tolerance să fie critic pe Azure. Nu e imposibil, dar necesită automatizare serioasă.

GCP Spot VMs (fost Preemptible VMs)

Google a migrat de la Preemptible VMs la Spot VMs, eliminând limita fixă de 24 de ore (care era, sincer, destul de enervantă):

• Reducere: Până la 91% față de on-demand (cel mai mare discount potențial din cei trei)
• Preaviz de terminare: 30 de secunde
• Fără limită de timp: Spre deosebire de vechile Preemptible VMs (max 24h), Spot VMs rulează indefinit până la revendicare
• Fără live migration: Spot VMs nu suportă migrare live la evenimente de mentenanță
• Instrument nativ: Managed Instance Groups cu autoscaling

Tabel Comparativ

Caracteristică	AWS Spot	Azure Spot VM	GCP Spot VM
Reducere maximă	~90%	~90%	~91%
Preaviz întrerupere	2 minute	30 secunde	30 secunde
Acțiune la întrerupere	Terminate/Stop/Hibernate	Deallocate/Delete	Terminate
Instrument de fleet	Spot Fleet, ASG	VM Scale Sets	Managed Instance Groups
Rebalansare proactivă	Da (Capacity Rebalancing)	Nu nativ	Nu nativ

Strategia 1: Gestionarea Întreruperilor AWS cu EventBridge și Lambda

Cea mai robustă abordare pe AWS este folosirea Amazon EventBridge pentru a captura evenimentele de întrerupere Spot și a declanșa acțiuni automate prin Lambda. Am folosit configurația asta în mai multe proiecte și funcționează foarte bine — iată implementarea completă:

Pasul 1: Regula EventBridge (Terraform)

# Regula EventBridge pentru capturarea avertismentelor de întrerupere Spot
resource "aws_cloudwatch_event_rule" "spot_interruption" {
  name        = "spot-interruption-handler"
  description = "Captureaza avertismente de intrerupere EC2 Spot"

  event_pattern = jsonencode({
    "source"      = ["aws.ec2"]
    "detail-type" = ["EC2 Spot Instance Interruption Warning"]
  })
}

resource "aws_cloudwatch_event_target" "lambda_target" {
  rule      = aws_cloudwatch_event_rule.spot_interruption.name
  target_id = "SpotInterruptionHandler"
  arn       = aws_lambda_function.spot_handler.arn
}

resource "aws_lambda_permission" "allow_eventbridge" {
  statement_id  = "AllowEventBridgeInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.spot_handler.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.spot_interruption.arn
}

Pasul 2: Funcția Lambda Handler (Python)

import boto3
import json
import os

ec2 = boto3.client("ec2")
asg = boto3.client("autoscaling")
sns = boto3.client("sns")

SNS_TOPIC_ARN = os.environ["SNS_TOPIC_ARN"]

def lambda_handler(event, context):
    instance_id = event["detail"]["instance-id"]
    action = event["detail"]["instance-action"]

    print(f"Spot interruption: {instance_id}, action: {action}")

    # 1. Obtine detalii despre instanta
    response = ec2.describe_instances(InstanceIds=[instance_id])
    instance = response["Reservations"][0]["Instances"][0]

    # 2. Verifica daca face parte dintr-un ASG
    asg_name = None
    for tag in instance.get("Tags", []):
        if tag["Key"] == "aws:autoscaling:groupName":
            asg_name = tag["Value"]
            break

    # 3. Detaseaza din ASG (declanseaza inlocuire automata)
    if asg_name:
        asg.detach_instances(
            InstanceIds=[instance_id],
            AutoScalingGroupName=asg_name,
            ShouldDecrementDesiredCapacity=False
        )
        print(f"Instanta {instance_id} detasata din ASG {asg_name}")

    # 4. Deregistreaza din target group (daca exista)
    try:
        elbv2 = boto3.client("elbv2")
        target_groups = elbv2.describe_target_health(
            Targets=[{"Id": instance_id}]
        )
        # Deregistrare se face automat la terminare
    except Exception:
        pass

    # 5. Trimite notificare
    sns.publish(
        TopicArn=SNS_TOPIC_ARN,
        Subject=f"Spot Interruption: {instance_id}",
        Message=json.dumps({
            "instance_id": instance_id,
            "action": action,
            "asg": asg_name,
            "az": instance.get("Placement", {}).get("AvailabilityZone"),
            "instance_type": instance.get("InstanceType")
        }, indent=2)
    )

    return {"statusCode": 200, "body": "Handled"}

Pasul 3: ASG cu Instanțe Mixte și Capacity Rebalancing

resource "aws_autoscaling_group" "spot_optimized" {
  name                = "spot-optimized-asg"
  min_size            = 3
  max_size            = 15
  desired_capacity    = 6
  vpc_zone_identifier = var.private_subnet_ids

  # Activeaza rebalansarea proactiva
  capacity_rebalance = true

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2  # 2 on-demand ca baseline
      on_demand_percentage_above_base_capacity = 0  # Restul = Spot
      spot_allocation_strategy                 = "capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
        version            = "$Latest"
      }

      # Diversifica pe minim 6 tipuri de instante
      override {
        instance_type     = "m6i.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m6a.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m5.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "m5a.xlarge"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "r6i.large"
        weighted_capacity = "1"
      }
      override {
        instance_type     = "r5.large"
        weighted_capacity = "1"
      }
    }
  }
}

Strategia capacity-optimized este recomandarea oficială AWS — alocă instanțe din pool-urile cu cea mai mare disponibilitate, reducând frecvența întreruperilor cu până la 60-70% comparativ cu strategia lowest-price. Am testat ambele variante și diferența se simte.

Strategia 2: Azure Spot VMs cu VM Scale Sets și Eviction Handling

Pe Azure, preavizul de doar 30 de secunde face esențială automatizarea completă. Nu ai timp să reacționezi manual — totul trebuie să fie automatizat dinainte. Iată cum configurezi un Scale Set cu Spot VMs folosind Bicep:

Configurare VM Scale Set cu Spot (Bicep/ARM)

// Azure Bicep: VM Scale Set cu Spot VMs
resource vmss 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = {
  name: 'app-spot-vmss'
  location: resourceGroup().location
  sku: {
    name: 'Standard_D4s_v5'
    tier: 'Standard'
    capacity: 5
  }
  properties: {
    overprovision: true
    upgradePolicy: {
      mode: 'Rolling'
    }
    virtualMachineProfile: {
      priority: 'Spot'
      evictionPolicy: 'Delete'      // Delete la evacuare
      billingProfile: {
        maxPrice: -1                  // Pay-as-you-go max (risc minim de evacuare pe pret)
      }
      osProfile: {
        computerNamePrefix: 'spot'
        adminUsername: 'azadmin'
        // ... configurare SSH/parola
      }
      storageProfile: {
        osDisk: {
          createOption: 'FromImage'
          managedDisk: {
            storageAccountType: 'Standard_LRS'
          }
        }
      }
      networkProfile: {
        networkInterfaceConfigurations: [
          {
            name: 'nic-config'
            properties: {
              primary: true
              ipConfigurations: [
                {
                  name: 'ip-config'
                  properties: {
                    subnet: {
                      id: subnetId
                    }
                    loadBalancerBackendAddressPools: [
                      {
                        id: lbBackendPoolId
                      }
                    ]
                  }
                }
              ]
            }
          }
        ]
      }
    }
    automaticRepairsPolicy: {
      enabled: true
      gracePeriod: 'PT10M'
    }
  }
}

Script de Monitorizare a Evenimentelor de Evacuare (Python)

# Monitorizare Azure Scheduled Events pentru preaviz evacuare
import requests
import time
import subprocess
import sys

METADATA_URL = "http://169.254.169.254/metadata/scheduledevents"
HEADERS = {"Metadata": "true"}
PARAMS = {"api-version": "2020-07-01"}

def check_for_eviction():
    """Verifica daca exista un eveniment de evacuare programat."""
    try:
        response = requests.get(
            METADATA_URL,
            headers=HEADERS,
            params=PARAMS,
            timeout=2
        )
        data = response.json()
        for event in data.get("Events", []):
            if event.get("EventType") == "Preempt":
                return event
    except requests.RequestException:
        pass
    return None

def graceful_shutdown(event):
    """Executa shutdown graceful in 30 secunde."""
    print(f"EVACUARE DETECTATA: {event}")

    # 1. Opreste acceptarea de trafic nou
    subprocess.run(["systemctl", "stop", "nginx"], timeout=5)

    # 2. Salveaza starea aplicatiei
    subprocess.run([
        "python3", "/app/checkpoint.py", "--save-state"
    ], timeout=15)

    # 3. Flush loguri si metrici
    subprocess.run(["sync"], timeout=5)

    print("Shutdown graceful complet.")
    sys.exit(0)

if __name__ == "__main__":
    print("Monitor evacuare Azure pornit...")
    while True:
        event = check_for_eviction()
        if event:
            graceful_shutdown(event)
        time.sleep(1)  # Verifica la fiecare secunda

Sfat din experiență: Setează maxPrice: -1 pentru a plăti maxim prețul on-demand. Asta elimină evacuările bazate pe preț — vei fi evacuat doar când Azure chiar are nevoie fizic de capacitate, ceea ce se întâmplă mult mai rar.

Strategia 3: GCP Spot VMs în GKE cu Node Pools Mixte

Pe Google Cloud, integrarea Spot VMs cu GKE (Google Kubernetes Engine) oferă probabil cea mai elegantă abordare din toate cele trei platforme. Kubernetes se descurcă natural cu nodurile care dispar — e practic construit pentru asta.

Creare Node Pool Spot în GKE

# Creare cluster GKE cu node pool on-demand (baseline)
gcloud container clusters create app-cluster \
  --zone europe-west1-b \
  --num-nodes 2 \
  --machine-type e2-standard-4

# Adauga node pool Spot pentru workload-uri tolerante la intreruperi
gcloud container node-pools create spot-pool \
  --cluster app-cluster \
  --zone europe-west1-b \
  --spot \
  --enable-autoscaling \
  --min-nodes 0 \
  --max-nodes 10 \
  --machine-type e2-standard-4 \
  --num-nodes 3

Kubernetes Deployment cu Node Affinity pentru Spot

# deployment-spot.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 5
  selector:
    matchLabels:
      app: batch-processor
  template:
    metadata:
      labels:
        app: batch-processor
    spec:
      # Programeaza DOAR pe noduri Spot
      nodeSelector:
        cloud.google.com/gke-spot: "true"

      # Tolerare pentru taint-ul Spot
      tolerations:
      - key: "cloud.google.com/gke-spot"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

      # Termination grace period - maximizeaza timpul de cleanup
      terminationGracePeriodSeconds: 25

      containers:
      - name: processor
        image: europe-docker.pkg.dev/project/repo/batch:v2
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "1000m"
            memory: "2Gi"

        # Handler pentru SIGTERM (primit la evacuare)
        lifecycle:
          preStop:
            exec:
              command:
              - /bin/sh
              - -c
              - |
                echo "Spot preemption detected, saving checkpoint..."
                /app/save-checkpoint.sh
                sleep 5

PodDisruptionBudget pentru Workload-uri Critice

# pdb.yaml - Limiteaza disruption-ul simultan
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: batch-processor-pdb
spec:
  minAvailable: 2  # Minim 2 pod-uri disponibile mereu
  selector:
    matchLabels:
      app: batch-processor

O precizare importantă: PodDisruptionBudget nu garantează protecție în cazul evacuărilor Spot — evacuarea e involuntară și nu respectă PDB. Folosește PDB ca strat adițional de protecție pentru disrupții voluntare (upgrade-uri, drain), nu te baza exclusiv pe el.

Framework Decizional: Ce Workload-uri Să Rulezi pe Spot

Nu orice workload e potrivit pentru Spot Instances. Greșeala pe care o văd cel mai des este entuziasmul de „90% reducere!" fără a evalua dacă workload-ul chiar suportă întreruperi. Iată un framework practic:

Ideal pentru Spot (Economii 70-90%)

• Batch processing: Job-uri ETL, procesare date, generare rapoarte
• CI/CD pipelines: Build-uri, teste automate, analiză de cod
• Antrenament ML: Training distribuit cu checkpointing (salvare progres la fiecare epocă)
• Rendering video/3D: Frame-uri individuale procesate independent
• Big Data: Apache Spark, Hadoop — framework-uri cu toleranță nativă la eșec
• Web servers stateless: Instanțe din spatele unui load balancer, cu sesiuni externalizate

Posibil pe Spot (cu precauții)

• Microservicii stateless: Cu replici suficiente și health checks agresive
• Workload-uri Kubernetes: Cu node pools mixte (Spot + On-Demand)
• Medii de dezvoltare/testare: Cu automatizare de recreare la evacuare

Nu folosi Spot pentru:

• Baze de date primare: PostgreSQL, MySQL, MongoDB primare — riscul e prea mare, nu merită
• Aplicații single-instance: Fără redundanță, evacuarea = downtime garantat
• Workload-uri cu latență critică: Trading, gaming real-time
• Job-uri lungi fără checkpoint: Risc de a pierde ore de procesare într-o secundă

Strategia Hibridă: Combinarea Spot cu Reserved Instances

Cele mai mari economii vin din combinarea inteligentă a modelelor de preț. Nu e vorba de „Spot sau Reserved" — ci de „Spot și Reserved, fiecare unde are sens". Iată framework-ul pe care îl recomand:

# Exemplu de strategie hibrida de pricing
# -------------------------------------------
# Structura recomandata pentru un workload tipic:
#
# Nivel 1 - Baseline (30-40% din capacitate)
#   → Reserved Instances / Savings Plans
#   → Commitment 1-3 ani
#   → Economie: 30-72% vs on-demand
#   → Pentru: workload-uri stabile, predictibile
#
# Nivel 2 - Variabil (40-50% din capacitate)
#   → Spot Instances
#   → Fara commitment
#   → Economie: 60-90% vs on-demand
#   → Pentru: workload-uri tolerante la intreruperi
#
# Nivel 3 - Burst (10-20% din capacitate)
#   → On-Demand Instances
#   → Fara commitment
#   → Pret full, dar flexibilitate totala
#   → Pentru: spike-uri neprevazute, workload-uri critice
#
# Economie totala estimata: 45-65% vs full on-demand

Strategia asta pe trei niveluri oferă echilibrul ideal între economii și fiabilitate. Dacă ai citit deja articolul nostru despre Reserved Instances, Savings Plans și CUDs, Spot Instances completează acel puzzle adăugând stratul de economii maxime pentru workload-uri flexibile.

Monitorizare și Observabilitate pentru Spot Instances

Fără monitorizare adecvată, zbori pe orbește. Nu poți ști cât economisești efectiv sau cât de frecvent sunt de fapt întreruperile. Iată ce trebuie să urmărești:

Metrici Esențiale

• Spot Interruption Rate: Procentul de instanțe întrerupte pe zi/săptămână
• Spot Savings Rate: Economii efective vs on-demand (după overhead-ul de întreruperi)
• Time-to-Replace: Timpul mediu de înlocuire a unei instanțe întrerupte
• Diversification Score: Câte tipuri de instanțe și AZ-uri folosești
• Fallback Frequency: Cât de des cazi pe On-Demand ca backup

Alerting cu CloudWatch (AWS)

# CloudWatch Alarm pentru rata de intreruperi Spot
resource "aws_cloudwatch_metric_alarm" "spot_interruption_rate" {
  alarm_name          = "high-spot-interruption-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  threshold           = 5  # Alerta daca > 5 intreruperi pe ora

  metric_query {
    id          = "interruptions"
    return_data = true

    metric {
      metric_name = "SpotInterruptionCount"
      namespace   = "Custom/SpotMetrics"
      period      = 3600
      stat        = "Sum"
    }
  }

  alarm_actions = [var.ops_sns_topic_arn]
  alarm_description = "Rata de intreruperi Spot depaseste pragul normal"
}

Greșeli Frecvente și Cum Să Le Eviți

Am văzut aceleași greșeli repetându-se în implementări multi-cloud. Iată cele mai comune (și cum le eviți):

1. Folosirea unui singur tip de instanță: Diversifică pe minim 6 tipuri diferite și 3 Availability Zones. Pool-urile mai largi oferă stabilitate semnificativ mai mare.
2. Alegerea strategiei lowest-price pe AWS: Strategia capacity-optimized reduce întreruperile cu 60-70%. Diferența de preț e minimă, dar stabilitatea crește dramatic. Merită schimbarea.
3. Neglijarea fallback-ului pe On-Demand: Întotdeauna configurează un baseline de instanțe On-Demand sau Reserved. Spot nu înseamnă „totul sau nimic".
4. Lipsa checkpoint-ului pentru job-uri lungi: Un job de 4 ore fără checkpoint pierde toată munca la întrerupere. Salvează progresul la fiecare 15-30 de minute — e o investiție mică cu impact mare.
5. Ignorarea costurilor de management: Instrumentele și automatizările pentru gestionarea Spot au un cost. Calculează ROI-ul real, nu doar discount-ul brut de pe hârtie.
6. Selectarea prematură a planului Premium pe Azure: Planul Premium pentru Azure Functions funcționează ca infrastructură rezervată — plătești indiferent de utilizare. Evaluează cu atenție înainte de upgrade.

Instrumente Recomandate pentru Gestionarea Spot în 2026

Piața de instrumente s-a maturizat mult în ultimii ani. Iată opțiunile care merită atenție:

Instrument	Tip	Puncte forte	Furnizor suportat
AWS Spot Fleet / ASG	Nativ	Capacity Rebalancing, diversificare automată	AWS
Azure VM Scale Sets	Nativ	Auto-repair, integrare AKS	Azure
GCP Managed Instance Groups	Nativ	Autoscaling, integrare GKE	GCP
CAST AI	Third-party	Optimizare AI multi-cloud, fallback automat	AWS, Azure, GCP
Spot by NetApp (fost Spot.io)	Third-party	Ocean pentru Kubernetes, Elastigroup	AWS, Azure, GCP
Karpenter	Open-source	Node provisioning inteligent pentru Kubernetes	AWS (nativ), alții via adaptoare

Întrebări Frecvente

Ce se întâmplă când o instanță Spot este întreruptă?

Pe AWS, primești un preaviz de 2 minute prin Instance Metadata Service sau Amazon EventBridge. Pe Azure și GCP, preavizul e de doar 30 de secunde. Instanța poate fi terminată, oprită (doar pe AWS) sau dealocată (Azure). Aplicația ta ar trebui să folosească această fereastră de timp pentru a salva starea, a goli conexiunile active și a face un shutdown controlat.

Pot folosi Spot Instances în producție?

Da, absolut — cu condiția să ai o arhitectură tolerantă la eșec. Web servere stateless din spatele unui load balancer, microservicii cu replici multiple și workload-uri Kubernetes cu node pools mixte sunt toate candidați viabili pentru producție. Cheia e redundanța: niciodată o singură instanță Spot pentru un serviciu critic.

Cum reduc frecvența întreruperilor Spot?

Diversifică pe minim 6 tipuri de instanțe diferite și toate Availability Zones disponibile. Pe AWS, folosește strategia capacity-optimized în loc de lowest-price. Pe Azure, setează maxPrice: -1 pentru a elimina evacuările bazate pe preț. Și verifică AWS Spot Instance Advisor pentru a alege instanțe cu rată de întrerupere scăzută.

Care este diferența dintre Spot Instances și Reserved Instances?

Reserved Instances (RI) oferă reduceri de 30-72% în schimbul unui angajament de 1-3 ani — capacitatea e garantată. Spot Instances oferă reduceri de 60-90% fără niciun angajament, dar capacitatea poate fi revendicată oricând. Strategia optimă le combină pe ambele: RI/Savings Plans pentru baseline-ul predictibil, Spot pentru workload-uri variabile.

Cât economisesc efectiv cu Spot Instances după overhead-ul de management?

Economiile nete variază între 50% și 80% față de on-demand, după ce incluzi costurile de automatizare, monitorizare și reprocesările ocazionale cauzate de întreruperi. Cu diversificare adecvată și strategia capacity-optimized, rata de întrerupere scade sub 5%, iar economiile efective rămân substanțiale.