Spot Instances AWS Azure GCP Guide (2026)

Какво представляват спот инстанциите и защо толкова много екипи ги залагат в бюджета си

Спот инстанциите (Spot Instances) са виртуални машини от облачните доставчици, които идват на драстично намалени цени — до 90% по-евтини от стандартните on-demand тарифи. Как е възможно? Те просто използват свободен изчислителен капацитет, който иначе би стоял неизползван в центровете за данни. В замяна на тези отстъпки обаче, доставчикът може да прекрати инстанцията ви с кратко предупреждение, когато капацитетът му потрябва за клиенти с по-висок приоритет.

Честно казано, цифрите говорят сами за себе си. През 2026 г. глобалните разходи за облачни услуги надхвърлиха 1 трилион долара, а средно 32% от облачния бюджет се разхищава. В този контекст спот инстанциите са един от най-мощните инструменти за оптимизация — особено ако работите с AI/ML натоварвания, batch обработка или Kubernetes клъстери.

В тази статия ще ви преведем през всичко практически — от основите на спот инстанциите при трите големи облачни доставчика до напреднали Kubernetes стратегии, с работещи Terraform примери и конфигурации, готови за production.

Сравнение на спот инстанциите: AWS vs Azure vs GCP

Всяка платформа предлага спот капацитет, но под различно име и с различни условия. Хайде да разгледаме разликите, защото те са ключови за правилната стратегия.

AWS Spot Instances

AWS има най-зрялата и гъвкава спот екосистема. Spot инстанциите използват свободен EC2 капацитет и могат да ви спестят до 90% спрямо on-demand цените. Ето основните характеристики:

Предупреждение за прекъсване: 2 минути, чрез EC2 metadata и EventBridge събития
Ценообразуване: Динамично — зависи от търсенето и предлагането в момента
Средна честота на прекъсване: Под 5% за повечето типове инстанции (по данни от AWS Spot Instance Advisor)
Allocation стратегии: capacity-optimized, lowest-price, diversified, price-capacity-optimized
Ново за 2026: EC2 Capacity Manager вече включва метрики за Spot прекъсвания — Spot Total Count, Spot Total Interruptions и Spot Interruption Rate — достъпни безплатно във всички комерсиални AWS региони

Azure Spot VMs

Azure Spot Virtual Machines дават достъп до неизползвания Azure капацитет с отстъпки до 90%. Няколко важни неща, които трябва да знаете:

Предупреждение за прекъсване: 30 секунди, чрез Azure Metadata Service
Политики за евикция: Stop/Deallocate или Delete
Ценообразуване: Задавате максимална цена или използвате -1 (текуща пазарна цена)
Ограничение: Без SLA за наличност; Spot node pools не могат да бъдат default pool в AKS
Предимство: Може да ги комбинирате с Azure Hybrid Benefit за допълнителни спестявания

GCP Spot VMs (бивши Preemptible VMs)

Google Cloud преименува Preemptible VMs на Spot VMs и (за щастие) премахна ограничението за 24-часово максимално време на работа. Основни характеристики:

Предупреждение за прекъсване: 30 секунди, чрез metadata server
Отстъпки: До 60-91% спрямо on-demand цените
Предимство: Автоматични Sustained Use Discounts (SUDs) за натоварвания, които не отговарят на CUD условия
Гъвкавост: Ангажиментите са на ниво vCPU и памет, а не за конкретен тип инстанция

Сравнителна таблица

Характеристика	AWS Spot	Azure Spot	GCP Spot
Максимална отстъпка	До 90%	До 90%	До 91%
Предупреждение	2 минути	30 секунди	30 секунди
Автоматични отстъпки	Не	Не	Да (SUDs)
Макс. време на работа	Без лимит	Без лимит	Без лимит (от 2024)
Таксуване при прекъсване	Не за непълен час	По секунда до прекъсването	По секунда до прекъсването

Кои натоварвания са подходящи за спот инстанции

Не всяко натоварване е подходящо за спот. Ключовият въпрос е прост: може ли приложението ви да оцелее при прекъсване без загуба на данни или значителен downtime?

Идеални натоварвания

CI/CD пайплайни: Паралелно изпълнение на тестове, build процеси и деплойменти — при прекъсване задачата просто се рестартира
Batch обработка: Финансово моделиране, научни симулации, медийно кодиране — данните се четат от и записват в устойчиво хранилище
AI/ML тренировъчни задачи: GPU-базираните спот инстанции могат да свалят разходите за тренировка със 70-80%; стига да използвате checkpointing за запазване на прогреса
Big Data и аналитика: Apache Spark, Hadoop и EMR клъстери — разпределените фреймуърци понасят загуба на възли
Stateless микросервизи: Реплицирани web услуги зад load balancer, които лесно се преразпределят
Event-driven обработка: Lambda-подобни функции и queue consumers

Натоварвания, които НЕ са подходящи

Тук нещата са категорични — не правете компромис:

Бази данни: Singleton инстанции на PostgreSQL, MySQL, MongoDB — използвайте Reserved Instances или on-demand
Message brokers: Kafka, RabbitMQ — загубата на брокер може да причини загуба на съобщения
Stateful приложения: Всичко, което съхранява състояние само в паметта без external persistence
Latency-критични услуги: Приложения, при които дори кратък downtime е неприемлив

Стратегии за управление на прекъсванията

Успешното използване на спот инстанции изисква архитектура, проектирана за устойчивост. От личен опит мога да кажа, че екипите, които инвестират в тези пет стратегии предварително, спят доста по-спокойно.

1. Диверсификация на типовете инстанции

Вероятността за прекъсване намалява драстично, когато разпределите натоварването между множество типове инстанции и зони на наличност. AWS данните показват, че спот инстанциите обикновено се прекратяват в групи — ако m5.large в AZ1 бъде прекратена, вероятно цялата група m5.large в AZ1 ще бъде засегната.

Ето Terraform конфигурация с attribute-based instance type selection (ABS) за максимална диверсификация:

# AWS: Използвайте attribute-based instance type selection (ABS)
# за максимална диверсификация

resource "aws_autoscaling_group" "spot_asg" {
  name                = "spot-workload-asg"
  desired_capacity    = 10
  max_size            = 20
  min_size            = 5
  vpc_zone_identifier = [
    aws_subnet.az1.id,
    aws_subnet.az2.id,
    aws_subnet.az3.id
  ]

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 20
      spot_allocation_strategy                 = "price-capacity-optimized"
    }

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

      override {
        instance_requirements {
          memory_mib {
            min = 8192
            max = 16384
          }
          vcpu_count {
            min = 4
            max = 8
          }
          instance_generations = ["current"]
          burstable_performance = "excluded"
        }
      }
    }
  }

  tag {
    key                 = "Environment"
    value               = "production"
    propagate_at_launch = true
  }
}

2. Checkpoint pattern за дълготрайни задачи

За AI/ML тренировки и batch обработка трябва да записвате прогреса на регулярни интервали в устойчиво хранилище (S3, GCS, Azure Blob). При прекъсване задачата може да се рестартира от последния checkpoint, вместо да започвате от нулата.

Ето един Python клас, който илюстрира подхода:

import boto3
import signal
import json
from datetime import datetime

class SpotCheckpointManager:
    """Управлява checkpointing за ML тренировки на спот инстанции."""

    def __init__(self, bucket, prefix, checkpoint_interval=300):
        self.s3 = boto3.client("s3")
        self.bucket = bucket
        self.prefix = prefix
        self.checkpoint_interval = checkpoint_interval
        self.last_checkpoint = datetime.now()
        # Регистрация на SIGTERM handler за спот прекъсвания
        signal.signal(signal.SIGTERM, self._handle_interruption)

    def _handle_interruption(self, signum, frame):
        print("Получено спот прекъсване! Записване на checkpoint...")
        self.save_checkpoint(self.current_state, emergency=True)

    def save_checkpoint(self, state, emergency=False):
        checkpoint_key = f"{self.prefix}/checkpoint_latest.json"
        self.s3.put_object(
            Bucket=self.bucket,
            Key=checkpoint_key,
            Body=json.dumps({
                "state": state,
                "timestamp": datetime.now().isoformat(),
                "emergency": emergency
            })
        )
        self.last_checkpoint = datetime.now()
        print(f"Checkpoint записан: {checkpoint_key}")

    def load_checkpoint(self):
        try:
            response = self.s3.get_object(
                Bucket=self.bucket,
                Key=f"{self.prefix}/checkpoint_latest.json"
            )
            data = json.loads(response["Body"].read())
            print(f"Checkpoint зареден от {data['timestamp']}")
            return data["state"]
        except self.s3.exceptions.NoSuchKey:
            print("Няма наличен checkpoint. Започване от начало.")
            return None

    def should_checkpoint(self):
        elapsed = (datetime.now() - self.last_checkpoint).total_seconds()
        return elapsed >= self.checkpoint_interval


# Използване при ML тренировка
manager = SpotCheckpointManager(
    bucket="ml-training-checkpoints",
    prefix="model-v2/run-42",
    checkpoint_interval=600  # На всеки 10 минути
)

initial_state = manager.load_checkpoint()
epoch_start = initial_state["epoch"] if initial_state else 0

for epoch in range(epoch_start, total_epochs):
    manager.current_state = {"epoch": epoch, "loss": current_loss}
    train_one_epoch(model, data_loader)
    if manager.should_checkpoint():
        manager.save_checkpoint({"epoch": epoch + 1, "loss": current_loss})

3. Гаранция за минимална наличност с on-demand baseline

Тук подходът е хибриден: 20-40% on-demand инстанции като стабилна основа и 60-80% спот за мащабируемост. Така гарантирате, че критичното минимално натоварване винаги работи — дори при масово спот прекъсване. Простичко, но ефективно.

4. Pod Disruption Budgets (PDB) в Kubernetes

Задължително настройте PDB за всяко deployment на спот възли. Те контролират колко pod-а могат да бъдат прекъснати едновременно:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: "60%"
  selector:
    matchLabels:
      app: web-app
---
# За batch задачи — ограничаване на едновременните прекъсвания
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: batch-worker-pdb
spec:
  maxUnavailable: 2
  selector:
    matchLabels:
      app: batch-worker

5. Chaos Engineering за валидация

Не чакайте реално прекъсване, за да разберете дали системата ви издържа. Сериозно — използвайте AWS Fault Injection Simulator (FIS), Chaos Mesh или LitmusChaos, за да симулирате спот прекъсвания в staging среда. По-добре е да откриете проблемите по ваш график, отколкото в 3 сутринта.

Конфигуриране на спот node pools в Kubernetes: EKS, AKS и GKE

Kubernetes е естествената среда за спот инстанции — оркестраторът автоматично преразпределя pod-ове при загуба на възел. Нека видим как се конфигурират спот node pools на трите основни платформи.

Amazon EKS с Karpenter

Karpenter е препоръчителният автоскалер за EKS от 2025 г. насам и на практика замени Cluster Autoscaler за повечето случаи. Той е по-бърз и значително по-гъвкав при избора на инстанции:

# Karpenter NodePool за спот инстанции в EKS
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m6i.xlarge
            - m6i.2xlarge
            - m7i.xlarge
            - m7i.2xlarge
            - c6i.xlarge
            - c6i.2xlarge
            - r6i.xlarge
        - key: topology.kubernetes.io/zone
          operator: In
          values:
            - eu-west-1a
            - eu-west-1b
            - eu-west-1c
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      taints:
        - key: spot-instance
          value: "true"
          effect: NoSchedule
  limits:
    cpu: "200"
    memory: 400Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s
---
# On-demand NodePool за критична инфраструктура
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: on-demand-critical
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m6i.xlarge
            - m6i.2xlarge
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "50"
    memory: 100Gi

Azure AKS Spot Node Pool

При AKS конфигурацията е сравнително директна — създавате клъстера с on-demand system pool и после добавяте спот node pool:

# Създаване на AKS клъстер с on-demand system pool
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --generate-ssh-keys

# Добавяне на спот node pool
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name spotnodepool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-count 5 \
  --node-vm-size Standard_D4s_v5 \
  --min-count 2 \
  --max-count 15 \
  --enable-cluster-autoscaler \
  --labels "kubernetes.azure.com/scalesetpriority=spot" \
  --node-taints "kubernetes.azure.com/scalesetpriority=spot:NoSchedule"

Важно: В AKS спот node pool не може да бъде default pool. Винаги създавайте on-demand system pool за критичните системни компоненти (CoreDNS, kube-proxy и подобни).

Google GKE Spot Node Pool

# Terraform конфигурация за GKE спот node pool
resource "google_container_node_pool" "spot_pool" {
  name       = "spot-workloads"
  cluster    = google_container_cluster.primary.name
  location   = "europe-west1"

  autoscaling {
    min_node_count = 2
    max_node_count = 20
  }

  node_config {
    spot         = true
    machine_type = "n2-standard-4"
    disk_size_gb = 50
    disk_type    = "pd-ssd"

    oauth_scopes = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]

    labels = {
      "cloud.google.com/gke-spot" = "true"
    }

    taint {
      key    = "cloud.google.com/gke-spot"
      value  = "true"
      effect = "NO_SCHEDULE"
    }

    metadata = {
      disable-legacy-endpoints = "true"
    }
  }

  management {
    auto_repair  = true
    auto_upgrade = true
  }
}

Deployment с toleration за спот възли

За да насочите натоварванията към спот node pools, използвате tolerations и node affinity. Ето универсален пример, който работи и при трите облачни доставчика:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 5
  selector:
    matchLabels:
      app: batch-processor
  template:
    metadata:
      labels:
        app: batch-processor
    spec:
      tolerations:
        - key: "spot-instance"
          operator: "Equal"
          value: "true"
          effect: "NoSchedule"
        - key: "kubernetes.azure.com/scalesetpriority"
          operator: "Equal"
          value: "spot"
          effect: "NoSchedule"
        - key: "cloud.google.com/gke-spot"
          operator: "Equal"
          value: "true"
          effect: "NoSchedule"
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 80
              preference:
                matchExpressions:
                  - key: karpenter.sh/capacity-type
                    operator: In
                    values:
                      - spot
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - batch-processor
                topologyKey: kubernetes.io/hostname
      containers:
        - name: processor
          image: myregistry/batch-processor:latest
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
            limits:
              cpu: "1"
              memory: "2Gi"

Мониторинг и оптимизация на спот разходите

Конфигурацията е само началото. За да извлечете максимума от спот инстанциите, трябва да наблюдавате какво се случва и да реагирате навреме.

AWS CloudWatch метрики за спот

От януари 2026 г. EC2 Capacity Manager предлага три нови метрики, които доста улесняват нещата:

Spot Total Count: Общ брой спот инстанции (или vCPU) за избрания период
Spot Total Interruptions: Колко от тях са били прекъснати
Spot Interruption Rate: Процентът на прекъсвания — това е метриката, на която трябва да обръщате най-много внимание

Практически dashboard с Prometheus и Grafana

За Kubernetes среди можете да мониторирате спот-специфични метрики с Prometheus. Ето примерни alert правила:

# Prometheus правила за алертиране при висока честота на спот прекъсвания
groups:
  - name: spot-instance-alerts
    rules:
      - alert: HighSpotInterruptionRate
        expr: |
          (
            sum(rate(kube_node_status_condition{
              condition="Ready",
              status="false"
            }[1h])) by (node)
            /
            count(kube_node_info) by (node)
          ) > 0.1
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Висока честота на прекъсвания на спот възли"
          description: "Повече от 10% от спот възлите са били прекъснати в последния час"

      - alert: SpotNodePoolCapacityLow
        expr: |
          sum(kube_node_status_allocatable{
            resource="cpu",
            node=~".*spot.*"
          }) < 20
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Нисък капацитет на спот node pool"
          description: "Наличните CPU ресурси в спот pool са под 20 cores"

Калкулация на реалните спестявания: практически пример

Теорията е хубаво нещо, но нека погледнем конкретни числа. Ето един реалистичен сценарий, който илюстрира какво можете да очаквате.

Сценарий: E-commerce платформа с Kubernetes

Компонент	Тип инстанция	Брой	On-Demand цена/месец	Спот цена/месец
API сървъри (stateless)	m6i.xlarge	10	$1,401	$420 (70% спестяване)
Background workers	c6i.2xlarge	8	$1,958	$490 (75% спестяване)
ML inference	g5.xlarge	4	$4,867	$1,460 (70% спестяване)
Бази данни (on-demand)	r6i.2xlarge	3	$2,741	$2,741 (без промяна)
Системни компоненти	m6i.large	3	$630	$630 (без промяна)

Общо on-demand: $11,597/месец
С хибридна спот стратегия: $5,741/месец
Месечно спестяване: $5,856 (~50%)
Годишно спестяване: $70,272

При по-агресивна стратегия с 80% спот покритие за подходящите натоварвания, годишните спестявания могат да стигнат $80,000-90,000. Не е лошо, нали?

Топ 5 грешки при използване на спот инстанции

Ако избегнете тези грешки, ще си спестите и пари, и безсънни нощи:

Разчитане на един тип инстанция: Ако използвате само m5.large и тази pool бъде прекъсната — губите всичко. Винаги конфигурирайте поне 4-5 различни типа.
Липса на on-demand fallback: Чиста спот конфигурация без on-demand baseline рискува пълен downtime при масово прекъсване. Не си заслужава да спестите още 10%, ако рискувате наличността.
Пренебрегване на checkpointing: Дълготрайни задачи без checkpoint записване загубват целия прогрес при прекъсване — часове или дни работа, хвърлени на вятъра.
Singleton услуги на спот възли: Бази данни, message brokers и други stateful singletons никога не трябва да работят на спот. Точка.
Липса на мониторинг: Без наблюдение на честотата на прекъсвания летите на сляпо и не можете да коригирате стратегията навреме.

Често задавани въпроси

Колко можем реално да спестим със спот инстанции?

Спот инстанциите предлагат отстъпки от 60% до 90% спрямо on-demand цените — зависи от региона, типа инстанция и текущото търсене. Средните спестявания за организации с хибридна стратегия (спот + on-demand) са около 50-70% от разходите за compute. Според Kubernetes Cost Benchmark Report 2025, клъстери с микс от on-demand и спот постигат средно 59% спестяване, а клъстери само със спот — 77%.

Безопасно ли е да използваме спот инстанции в production?

Да, при правилна архитектура. Ключът е да проектирате за устойчивост: използвайте реплики (минимум 3-5 за всяка услуга), Pod Disruption Budgets, Node Termination Handlers, и винаги поддържайте on-demand baseline за критичните компоненти. Много организации успешно работят със спот за 60-80% от production натоварванията си.

Каква е разликата между спот инстанции и Reserved Instances?

Reserved Instances (RI) дават отстъпки до 72% срещу 1-3 годишен ангажимент и гарантирана наличност. Спот инстанциите предлагат по-големи отстъпки (до 90%), но без гаранция. Оптималната стратегия е комбинирана: RI за базовото натоварване (предвидимо, 24/7), спот за променливи и fault-tolerant натоварвания, и on-demand за върхови моменти.

Как да се справим с прекъсване по време на ML тренировка?

Checkpoint pattern е отговорът. Записвайте състоянието на модела (weights, optimizer state, epoch) в S3/GCS/Azure Blob на всеки 5-15 минути. При прекъсване новата инстанция зарежда последния checkpoint и продължава от там. Frameworks като PyTorch Lightning и TensorFlow поддържат вграден checkpointing. Не забравяйте да регистрирате SIGTERM handler за аварийно записване при сигнал за прекъсване.

Кой облачен доставчик предлага най-добрите спот инстанции?

Зависи какво търсите. AWS има най-зрялата екосистема с 2-минутно предупреждение и най-богат набор от инструменти (Karpenter, Spot Instance Advisor, EC2 Capacity Manager). GCP предлага автоматични SUDs и по-опростено ценообразуване. Azure е силен при хибридни сценарии с Azure Hybrid Benefit. За Kubernetes натоварвания конкретно — AWS EKS с Karpenter е водещият избор през 2026 г., а GCP GKE предлага най-лесната интеграция от кутията.