Спот-инстансы в AWS, Azure и GCP: как экономить до 90% на облачных вычислениях в 2026 году

Введение: спот-инстансы — самый недооценённый инструмент экономии

Если вы уже знакомы с Reserved Instances, Savings Plans и CUD, то наверняка понимаете, как экономить на стабильных, предсказуемых нагрузках через обязательства. А если разбирались с оптимизацией затрат на Kubernetes, то знаете про управление ресурсами в контейнерных средах. Но есть ещё один мощный инструмент, о котором многие почему-то забывают — спот-инстансы (Spot Instances).

Если коротко, спот-инстансы — это избыточные мощности облачных провайдеров, которые продаются со скидками от 60% до 90% по сравнению с on-demand ценами. Да, до 90%. Не опечатка.

Облачные провайдеры реально готовы отдать свободные серверы за десятую часть стоимости. Но есть подвох: эти ресурсы могут забрать обратно в любой момент, когда провайдеру понадобится ёмкость для клиентов, платящих полную цену.

По данным аналитических отчётов, в 2026 году средний уровень фактического использования облачных ресурсов составляет около 30–40%. То есть у провайдеров постоянно простаивает огромное количество серверов. Именно эта свободная ёмкость и превращается в спот-инстансы — отличное предложение для тех, кто готов мириться с определённой долей непредсказуемости.

В этой статье мы разберём спот-инстансы во всех трёх крупнейших облаках: AWS, Azure и GCP. Посмотрим, как каждый из них реализует этот механизм, какие нагрузки подходят для спотов, как минимизировать риски прерываний и какие архитектурные паттерны реально работают.

Как работают спот-инстансы: общая механика

Прежде чем погружаться в детали каждого провайдера, давайте разберёмся с общей логикой. Концепция на самом деле довольно простая, но вот реализация у AWS, Azure и GCP различается — и порой весьма существенно.

Базовый принцип

Облачные провайдеры управляют гигантскими дата-центрами с миллионами серверов. В каждый момент времени значительная часть этих серверов простаивает — ждёт on-demand клиентов, которые могут запросить ресурсы в любую секунду. Вместо того чтобы оставлять эту ёмкость пустой, провайдеры предлагают её по сниженной цене, но с одним условием: если появится клиент, готовый платить полную стоимость, ваш спот-инстанс заберут (evicted).

Для провайдера это идеальная модель: деньги за ресурсы, которые иначе бы простаивали. Для вас — возможность получить мощности со скидкой до 90%. Выигрыш-выигрыш, если вы правильно спроектировали архитектуру.

Ключевые характеристики спот-инстансов

• Скидки от 60% до 90% — конкретный размер зависит от типа инстанса, региона, зоны доступности и текущего спроса.
• Возможность прерывания — провайдер может отозвать ваш инстанс с предупреждением от 30 секунд до нескольких минут (зависит от провайдера).
• Динамическое ценообразование — цена может меняться в зависимости от спроса и предложения, хотя у разных провайдеров эта динамика реализована по-разному.
• Идентичные ресурсы — с точки зрения производительности спот-инстансы абсолютно идентичны on-demand. Те же CPU, память, сеть и хранилище. Никаких компромиссов по железу.

AWS Spot Instances: максимальная гибкость и зрелая экосистема

Amazon Web Services — пионер спот-рынка в облаке. AWS предлагает спот-инстансы аж с 2009 года, и за это время экосистема вокруг них стала самой развитой среди всех облачных провайдеров.

Модель ценообразования

С 2017 года AWS отказался от аукционной модели (помните те времена, когда нужно было «торговаться»?) и перешёл к стабильному ценообразованию. Спот-цены теперь плавно меняются в зависимости от долгосрочного спроса и предложения, а не от мгновенных торгов. На практике цена на конкретный тип инстанса в конкретной зоне доступности может оставаться стабильной днями, а иногда и неделями.

Средняя экономия на AWS Spot Instances составляет 60–70% по сравнению с on-demand. Для некоторых типов (особенно старых поколений и менее популярных регионов) скидка может доходить до 90%. Например, c5.xlarge в us-east-1 обычно стоит на 60–65% дешевле, а m5.large в менее загруженных регионах — на 70–75%.

Механизм прерывания

AWS даёт двухминутное предупреждение перед отзывом спот-инстанса. Это предупреждение доступно через:

• Instance Metadata Service (IMDS) — приложение может периодически опрашивать endpoint метаданных для обнаружения предстоящего прерывания.
• EventBridge — для централизованной обработки событий прерывания.
• Rebalance Recommendation — сигнал, который приходит раньше двухминутного уведомления и говорит, что инстанс находится в зоне повышенного риска. Очень полезная штука для проактивной миграции.

По данным AWS, исторически средняя частота прерываний — менее 5% по всем регионам и типам инстансов. Конечно, реальная частота для конкретных нагрузок зависит от текущей доступности ёмкости. Инстансы с частотой прерываний ниже 5% считаются высоконадёжными, от 5% до 15% — умеренно стабильными, а выше 15% — уже высоковолатильными.

Стратегии выделения ресурсов

AWS предлагает несколько стратегий аллокации для Spot Fleet и Auto Scaling Groups:

# Пример конфигурации Spot Fleet с price-capacity-optimized стратегией
aws ec2 request-spot-fleet --spot-fleet-request-config '{
  "IamFleetRole": "arn:aws:iam::123456789012:role/aws-ec2-spot-fleet-role",
  "TargetCapacity": 10,
  "SpotPrice": "0.05",
  "AllocationStrategy": "priceCapacityOptimized",
  "LaunchTemplateConfigs": [
    {
      "LaunchTemplateSpecification": {
        "LaunchTemplateId": "lt-0abcdef1234567890",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.large", "AvailabilityZone": "us-east-1a"},
        {"InstanceType": "m5.xlarge", "AvailabilityZone": "us-east-1a"},
        {"InstanceType": "m5a.large", "AvailabilityZone": "us-east-1b"},
        {"InstanceType": "m6i.large", "AvailabilityZone": "us-east-1b"},
        {"InstanceType": "c5.large", "AvailabilityZone": "us-east-1c"},
        {"InstanceType": "c5a.large", "AvailabilityZone": "us-east-1c"}
      ]
    }
  ]
}'

Рекомендуемая стратегия в 2026 году — priceCapacityOptimized. Она автоматически выбирает пулы с наибольшей доступностью и одновременно наименьшей ценой. По сути, лучшее из двух миров.

Все основные стратегии аллокации:

• priceCapacityOptimized — баланс между ценой и доступностью. Лучший выбор для большинства сценариев.
• capacityOptimized — приоритет пулам с наибольшей ёмкостью. Используйте, когда непрерывность работы важнее минимальной цены.
• lowestPrice — самые дешёвые пулы. Может привести к частым прерываниям, но подходит для короткоживущих batch-задач.
• diversified — равномерное распределение по всем указанным пулам. Хороший вариант для долгоживущих нагрузок.

EC2 Capacity Manager: новинка 2026 года

В январе 2026 года AWS представил новые метрики прерываний Spot в EC2 Capacity Manager. Теперь можно:

• Отслеживать количество работающих спот-инстансов в реальном времени.
• Мониторить прерывания и рассчитывать частоту прерываний.
• Анализировать данные в разрезе регионов, зон доступности и аккаунтов.

Честно говоря, этой фичи не хватало годами. Наконец-то принимать решения о том, какие типы инстансов и регионы использовать для спот-нагрузок, стало намного проще.

Azure Spot VMs: гибкость с нюансами

Microsoft Azure предлагает Spot Virtual Machines (раньше они назывались Low-Priority VMs) со скидками до 90% от pay-as-you-go цен. Однако реализация тут отличается от AWS, и местами — довольно существенно.

Модель ценообразования

Azure использует рыночную модель для Spot VMs. Вы устанавливаете максимальную цену, которую готовы платить (до пяти десятичных знаков в долларах). Если текущая рыночная цена превысит ваш порог — инстанс вытеснят.

У вас два варианта:

• Установить максимальную цену — инстанс вытеснят, когда рыночная цена превысит ваш порог.
• Установить -1 (без ограничения цены) — инстанс вытеснят только из-за нехватки ёмкости, но не из-за цены. Платите всегда текущую спот-цену.

Политики вытеснения

Azure поддерживает две политики вытеснения, и выбор между ними сильно влияет на стоимость и поведение:

• Deallocate (по умолчанию) — VM переводится в состояние «остановлена-деаллоцирована». Можно перезапустить позже, когда ёмкость снова появится. Важный момент: деаллоцированные VM продолжают считаться в квоте, и вы по-прежнему платите за хранилище дисков.
• Delete — VM и её диски удаляются полностью. Никаких дополнительных расходов, но все данные теряются.

Критический нюанс: 30 секунд на подготовку

Это, пожалуй, самое важное отличие Azure от AWS. Azure даёт всего 30 секунд предупреждения перед вытеснением. Сравните с двумя минутами в AWS — разница огромная.

Для многих нагрузок 30 секунд — критически мало. Вашему приложению нужно успеть:

1. Обнаружить событие вытеснения (через Scheduled Events API).
2. Сохранить текущее состояние.
3. Корректно завершить активные соединения.
4. Передать работу другим инстансам.

Проверка статуса вытеснения через Azure Scheduled Events:

# Проверка Scheduled Events для обнаружения вытеснения
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

# Пример ответа при вытеснении:
# {
#   "DocumentIncarnation": 1,
#   "Events": [
#     {
#       "EventId": "A123BC45-67DE-8901-FG23-456789HIJKLM",
#       "EventType": "Preempt",
#       "ResourceType": "VirtualMachine",
#       "Resources": ["mySpotVM"],
#       "EventStatus": "Scheduled",
#       "NotBefore": "2026-02-15T12:30:00Z"
#     }
#   ]
# }

Spot Priority Mix для Scale Sets

А вот это уникальная возможность Azure — Spot Priority Mix для Virtual Machine Scale Sets (VMSS). Эта функция автоматически поддерживает заданное соотношение между спот- и обычными виртуальными машинами в масштабируемом наборе.

Пример конфигурации Scale Set со Spot Priority Mix:

{
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "apiVersion": "2023-09-01",
  "name": "myScaleSet",
  "location": "westeurope",
  "sku": {
    "name": "Standard_D4s_v5",
    "tier": "Standard",
    "capacity": 10
  },
  "properties": {
    "orchestrationMode": "Flexible",
    "spotRestorePolicy": {
      "enabled": true,
      "restoreTimeout": "PT1H"
    },
    "priorityMixPolicy": {
      "baseRegularPriorityCount": 2,
      "regularPriorityPercentageAboveBase": 25
    },
    "virtualMachineProfile": {
      "priority": "Spot",
      "evictionPolicy": "Delete",
      "billingProfile": {
        "maxPrice": -1
      }
    }
  }
}

Что тут происходит:

• baseRegularPriorityCount: 2 — первые 2 VM всегда будут on-demand (для базовой стабильности).
• regularPriorityPercentageAboveBase: 25 — из оставшихся VM 25% будут on-demand, а 75% — спот.
• spotRestorePolicy — автоматически восстанавливает вытесненные спот-VM, когда ёмкость появляется снова (в пределах 1 часа).
• evictionPolicy: Delete — при вытеснении VM удаляется полностью. Для Scale Sets это обычно рекомендуемый вариант.

GCP Spot VMs: простота и предсказуемость

Google Cloud Platform предлагает Spot VMs — эволюцию прежних Preemptible VMs. К 2026 году GCP полностью перешёл на Spot VMs как основной механизм предоставления избыточной ёмкости.

От Preemptible к Spot VMs

Раньше GCP предлагал Preemptible VMs с довольно жёстким ограничением — максимум 24 часа жизни. По истечении этого периода инстанс автоматически останавливался, даже если свободная ёмкость была доступна. Spot VMs убрали это ограничение — теперь они могут работать сколько угодно, пока Google не понадобится ёмкость.

Главные различия между Preemptible и Spot VMs:

• Время жизни — Preemptible VMs: максимум 24 часа. Spot VMs: без ограничений.
• Ценообразование — идентичное для обоих типов.
• Доступность — Preemptible VMs больше не создаются через консоль GCP и постепенно уходят в историю.
• Функциональность — Spot VMs поддерживают дополнительные возможности, недоступные для Preemptible.

Ценообразование и скидки

GCP Spot VMs предлагают скидки до 91% для многих типов машин, GPU, TPU и локальных SSD. Причём цены на споты в GCP могут меняться не чаще одного раза в 30 дней — это делает их заметно более предсказуемыми по сравнению с AWS и Azure.

Интересный нюанс: GCP автоматически предоставляет Sustained Use Discounts (SUD) — скидки до 30% за стабильное использование ресурсов в течение месяца. К Spot VMs они не применяются, но это означает, что разница между Spot и on-demand в GCP может быть меньше, чем у конкурентов, где таких автоматических скидок нет.

Механизм прерывания

GCP Spot VMs могут быть отозваны без предварительного уведомления. Да, формально Google может забрать машину мгновенно. На практике, правда, GCP отправляет 30-секундный ACPI-сигнал, который можно перехватить скриптом завершения (shutdown script). Но полагаться на это как на гарантию я бы не стал.

# Пример создания Spot VM в GCP с shutdown script
gcloud compute instances create my-spot-instance \
  --zone=europe-west1-b \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --metadata=shutdown-script='#!/bin/bash
    # Сохранение состояния при вытеснении
    echo "$(date): Spot VM shutting down" >> /var/log/spot-shutdown.log

    # Сохранение промежуточных результатов в Cloud Storage
    gsutil cp /tmp/checkpoint/* gs://my-bucket/checkpoints/

    # Уведомление системы мониторинга
    curl -X POST https://monitoring.example.com/webhook \
      -d "{\"event\": \"spot_preemption\", \"instance\": \"my-spot-instance\"}"
  '

Параметр instance-termination-action определяет, что произойдёт при вытеснении:

• STOP — VM останавливается, диски сохраняются. Можно перезапустить позже.
• DELETE — VM и диски удаляются полностью.

Spot VMs в GKE

Google Kubernetes Engine позволяет создавать нодпулы из Spot VMs, и это отлично сочетается с подходами к оптимизации Kubernetes:

# Создание нодпула GKE со Spot VMs
gcloud container node-pools create spot-pool \
  --cluster=my-cluster \
  --zone=europe-west1-b \
  --machine-type=n2-standard-4 \
  --spot \
  --num-nodes=3 \
  --enable-autoscaling \
  --min-nodes=0 \
  --max-nodes=10 \
  --node-taints=cloud.google.com/gke-spot=true:NoSchedule

Taint cloud.google.com/gke-spot=true:NoSchedule гарантирует, что на спот-ноды попадут только поды, которые явно толерантны к прерываниям. Остальные нагрузки останутся на стабильных нодах.

Сравнительная таблица: спот-инстансы у трёх провайдеров

Параметр	AWS Spot Instances	Azure Spot VMs	GCP Spot VMs
Максимальная скидка	До 90%	До 90%	До 91%
Средняя скидка	60–70%	60–80%	60–91%
Предупреждение о вытеснении	2 минуты	30 секунд	~30 секунд (ACPI)
Изменчивость цен	Плавная, рыночная	Рыночная, с возможностью установки максимума	Обновление не чаще 1 раза в 30 дней
Максимальное время работы	Без ограничений	Без ограничений	Без ограничений (Spot VM)
Средняя частота прерываний	<5% (исторически)	Варьируется по регионам	Варьируется по зонам
Политика вытеснения	Terminate / Stop / Hibernate	Deallocate / Delete	Stop / Delete
Интеграция с K8s	EKS + Karpenter / Managed Node Groups	AKS + VMSS Spot Node Pools	GKE + Spot Node Pools

Какие нагрузки подходят для спот-инстансов

Не все нагрузки одинаково хорошо переносят прерывания. Вот классификация, основанная на практическом опыте:

Идеальные кандидаты (низкий риск)

• Batch-обработка и ETL — задачи, которые можно разделить на независимые части и перезапустить с контрольной точки. MapReduce, Apache Spark, обработка данных.
• CI/CD пайплайны — сборка, тестирование и деплой обычно безболезненно переносят прерывания. Jenkins-агенты, GitHub Actions self-hosted runners, GitLab runners — всё это идеально ложится на споты.
• Обучение ML-моделей — при условии регулярного чекпойнтинга. PyTorch и TensorFlow поддерживают сохранение и восстановление состояния из коробки.
• Рендеринг и транскодирование — распределённые задачи по кадрам. Каждый кадр — независимая единица работы.
• Нагрузочное тестирование — генерация трафика для стресс-тестов не требует стабильности отдельных инстансов.
• Обработка очередей — воркеры, обрабатывающие сообщения из SQS, Service Bus или Pub/Sub.

Подходят с оговорками (средний риск)

• Stateless веб-серверы за балансировщиком — при наличии достаточного количества реплик и правильной настройки health checks. Балансировщик автоматически перенаправит трафик.
• Микросервисы в Kubernetes — при условии правильной настройки Pod Disruption Budgets, anti-affinity rules и readiness probes.
• Dev/staging окружения — отлично подходят для спотов. Но учитывайте: если среда постоянно «падает», разработчики будут не в восторге.

Не рекомендуется (высокий риск)

• Базы данных без репликации — потеря инстанса с единственной репликой БД может привести к потере данных и простою. Просто не надо.
• Stateful-сервисы с длительными транзакциями — платёжные шлюзы, системы бронирования, где прерывание может привести к несогласованности данных.
• Мониторинг и алертинг — система, которая должна сообщать о проблемах, не может сама быть ненадёжной. Это как нанять пожарного, который боится огня.
• Единственный инстанс критического сервиса — если у вас single point of failure, спот-инстанс многократно усугубляет риск.

Архитектурные паттерны для работы со спотами

Успешное использование спот-инстансов — это не просто «заменить on-demand на spot». Нужен осознанный подход к архитектуре. Вот паттерны, которые реально работают на практике.

Паттерн 1: смешанный флот (On-Demand + Spot)

Самый распространённый и надёжный паттерн. Базовая нагрузка обеспечивается on-demand инстансами (или Reserved Instances / Savings Plans), а пиковая — спотами.

# AWS Auto Scaling Group с Mixed Instances Policy
# CloudFormation-шаблон
Resources:
  MixedASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 2
      MaxSize: 20
      DesiredCapacity: 6
      MixedInstancesPolicy:
        InstancesDistribution:
          OnDemandBaseCapacity: 2
          OnDemandPercentageAboveBaseCapacity: 25
          SpotAllocationStrategy: price-capacity-optimized
          SpotMaxPrice: ""  # Используем on-demand цену как максимум
        LaunchTemplate:
          LaunchTemplateSpecification:
            LaunchTemplateId: !Ref MyLaunchTemplate
            Version: !GetAtt MyLaunchTemplate.LatestVersionNumber
          Overrides:
            - InstanceType: m5.large
            - InstanceType: m5a.large
            - InstanceType: m5n.large
            - InstanceType: m6i.large
            - InstanceType: m6a.large
            - InstanceType: c5.large
            - InstanceType: c5a.large
            - InstanceType: c6i.large

Что тут важно:

• Первые 2 инстанса всегда on-demand — это ваша «подушка безопасности».
• Из оставшихся: 25% on-demand, 75% спот.
• 8 типов инстансов для максимальной диверсификации — и это критически важно для снижения частоты прерываний.

Паттерн 2: чекпойнтинг для долгих вычислений

Для задач, которые выполняются часами или даже днями (обучение ML-моделей, научные вычисления), необходимо регулярно сохранять промежуточное состояние. Без этого — даже не начинайте работать со спотами для таких нагрузок.

# Python-скрипт для чекпойнтинга при обучении ML-модели на спот-инстансе
import signal
import json
import urllib.request
import torch

class SpotCheckpointManager:
    def __init__(self, checkpoint_dir, check_interval=5):
        self.checkpoint_dir = checkpoint_dir
        self.check_interval = check_interval
        self.is_preempted = False

        # Обработчик сигнала SIGTERM (для GCP и Azure)
        signal.signal(signal.SIGTERM, self._handle_sigterm)

    def _handle_sigterm(self, signum, frame):
        print("Получен SIGTERM — начинаем экстренное сохранение")
        self.is_preempted = True

    def check_aws_spot_interruption(self):
        """Проверка прерывания через AWS IMDS"""
        try:
            url = "http://169.254.169.254/latest/meta-data/spot/instance-action"
            req = urllib.request.Request(url, method="GET")
            req.add_header("X-aws-ec2-metadata-token-ttl-seconds", "21600")
            response = urllib.request.urlopen(req, timeout=2)
            data = json.loads(response.read())
            if data.get("action") in ["stop", "terminate", "hibernate"]:
                self.is_preempted = True
                return True
        except urllib.error.HTTPError:
            pass  # 404 означает, что прерывания нет
        return False

    def save_checkpoint(self, model, optimizer, epoch, loss):
        """Сохранение контрольной точки"""
        checkpoint = {
            "epoch": epoch,
            "model_state_dict": model.state_dict(),
            "optimizer_state_dict": optimizer.state_dict(),
            "loss": loss
        }
        path = f"{self.checkpoint_dir}/checkpoint_epoch_{epoch}.pt"
        torch.save(checkpoint, path)
        print(f"Чекпойнт сохранён: epoch={epoch}, loss={loss:.4f}")

    def load_latest_checkpoint(self, model, optimizer):
        """Восстановление из последней контрольной точки"""
        import glob
        checkpoints = sorted(glob.glob(
            f"{self.checkpoint_dir}/checkpoint_epoch_*.pt"
        ))
        if not checkpoints:
            return 0

        checkpoint = torch.load(checkpoints[-1])
        model.load_state_dict(checkpoint["model_state_dict"])
        optimizer.load_state_dict(checkpoint["optimizer_state_dict"])
        print(f"Восстановлено из epoch={checkpoint['epoch']}")
        return checkpoint["epoch"] + 1

Паттерн 3: очередь задач с автоматическим retry

Этот паттерн идеален для обработки задач из очередей. Каждая задача — независимая единица работы. Если спот-инстанс прерывается, невыполненная задача автоматически возвращается в очередь и подхватывается другим воркером. Красота!

# Пример архитектуры с SQS и спот-воркерами (Terraform)
resource "aws_sqs_queue" "task_queue" {
  name                       = "processing-tasks"
  visibility_timeout_seconds = 300
  message_retention_seconds  = 1209600  # 14 дней

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dlq.arn
    maxReceiveCount     = 3  # Макс. 3 попытки обработки
  })
}

resource "aws_sqs_queue" "dlq" {
  name = "processing-tasks-dlq"
}

resource "aws_autoscaling_group" "spot_workers" {
  name                = "spot-workers"
  min_size            = 0
  max_size            = 50
  desired_capacity    = 5

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 1
      on_demand_percentage_above_base_capacity = 0
      spot_allocation_strategy                 = "price-capacity-optimized"
    }

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

      override {
        instance_type = "c5.xlarge"
      }
      override {
        instance_type = "c5a.xlarge"
      }
      override {
        instance_type = "c6i.xlarge"
      }
      override {
        instance_type = "m5.xlarge"
      }
    }
  }
}

Ключевые элементы:

• visibility_timeout в SQS — если воркер не обработал сообщение за 5 минут (например, из-за прерывания), оно снова станет видимым для других воркеров.
• Dead Letter Queue (DLQ) — перехватывает сообщения, которые не удалось обработать после 3 попыток. Чтобы ничего не потерялось.
• on_demand_base_capacity = 1 — хотя бы один on-demand воркер всегда работает, обеспечивая минимальную пропускную способность.

Спот-инстансы в Kubernetes: практическое руководство

Kubernetes и спот-инстансы — это, можно сказать, естественная пара. Kubernetes изначально проектировался для работы с нестабильными нодами: механизмы подов, ReplicaSets и автоскейлинга позволяют элегантно обрабатывать вытеснение узлов.

AWS EKS с Karpenter

Karpenter — автоскейлер нод для Kubernetes, разработанный AWS. В 2026 году он стал де-факто стандартом для управления нодами в EKS и является, на мой взгляд, лучшим инструментом для работы со спот-инстансами в Kubernetes.

# NodePool Karpenter с поддержкой спот-инстансов
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["4"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "100"
    memory: "400Gi"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
---
# Пример Pod с toleration для спот-нод
apiVersion: v1
kind: Pod
metadata:
  name: batch-processor
spec:
  tolerations:
    - key: "karpenter.sh/capacity-type"
      operator: "Equal"
      value: "spot"
      effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: karpenter.sh/capacity-type
                operator: In
                values: ["spot"]
  containers:
    - name: processor
      image: myregistry/batch-processor:latest
      resources:
        requests:
          cpu: "500m"
          memory: "1Gi"
        limits:
          cpu: "1000m"
          memory: "2Gi"

Karpenter автоматически выбирает оптимальные типы инстансов из указанных категорий (c, m, r) и поколений (5+), отдавая предпочтение спотам. Если спот-ёмкость недоступна — прозрачно переключается на on-demand. Никакого ручного вмешательства.

Pod Disruption Budget (PDB)

PDB — критически важный механизм для защиты сервисов при вытеснении спот-нод. Если вы используете споты в Kubernetes и не настроили PDB — вы играете с огнём:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-api-pdb
spec:
  minAvailable: "60%"
  selector:
    matchLabels:
      app: web-api

Этот PDB гарантирует, что минимум 60% подов web-api будут работать при любых обстоятельствах. Kubernetes не позволит вытеснить поды, если это нарушит этот бюджет.

Расчёт экономии: реальные цифры

Давайте посчитаем на конкретных цифрах. Возьмём типичное веб-приложение — 20 инстансов m5.large в регионе us-east-1.

Сценарий 1: полностью on-demand

# On-demand цена m5.large в us-east-1: $0.096/час
# 20 инстансов x $0.096/час x 730 часов/месяц = $1 401.60/месяц
# Годовая стоимость: $16 819.20

Сценарий 2: смешанный подход (On-Demand + Spot)

# Базовый уровень: 5 on-demand инстансов
# 5 x $0.096 x 730 = $350.40/месяц

# Спот-уровень: 15 спот-инстансов (средняя скидка 65%)
# Спот-цена: $0.096 x 0.35 = $0.0336/час
# 15 x $0.0336 x 730 = $367.92/месяц

# Итого: $718.32/месяц
# Годовая стоимость: $8 619.84
# Экономия: $8 199.36/год (48.8%)

Сценарий 3: оптимизированный (Savings Plans + Spot)

# Базовый уровень: 5 инстансов под Compute Savings Plans (скидка 35%)
# 5 x $0.096 x 0.65 x 730 = $227.76/месяц

# Спот-уровень: 15 спот-инстансов (средняя скидка 65%)
# 15 x $0.0336 x 730 = $367.92/месяц

# Итого: $595.68/месяц
# Годовая стоимость: $7 148.16
# Экономия: $9 671.04/год (57.5%)

Комбинация Savings Plans для базового уровня и спотов для пиковой нагрузки даёт экономию более 57%. И это всего на 20 инстансах. Для компании с сотнями серверов экономия запросто переваливает за сотни тысяч долларов в год.

Инструменты управления спот-инстансами

Ручное управление спотами возможно, но на масштабе быстро становится головной болью. Вот проверенные инструменты для автоматизации.

Нативные инструменты провайдеров

• AWS Spot Fleet / EC2 Fleet — управление большими флотами спот-инстансов с различными стратегиями аллокации.
• AWS EC2 Capacity Manager — новый инструмент 2026 года для мониторинга спот-ёмкости и прерываний.
• Azure VMSS Spot Priority Mix — автоматическое поддержание соотношения спот/on-demand в Scale Sets.
• GCP Managed Instance Groups (MIG) — группы управляемых инстансов с поддержкой Spot VMs и автоскейлинга.

Kubernetes-специфичные инструменты

• Karpenter — автоскейлер нод с нативной поддержкой спотов для EKS (и экспериментально для других провайдеров).
• Cluster Autoscaler — стандартный автоскейлер с поддержкой спот-нод для EKS, AKS и GKE.
• Spot by NetApp — мультиоблачная платформа для автоматизации спот-инстансов с предиктивным анализом прерываний.

Сторонние платформы

• CAST AI — автоматическая оптимизация Kubernetes-кластеров с интеллектуальным управлением спотами.
• Spot by NetApp (Ocean) — автоматическое управление спот-инстансами, перебалансировка нагрузок и предсказание прерываний.
• Holori — мониторинг спот-цен и частоты прерываний по всем провайдерам.

Типичные ошибки и как их избежать

Эти ошибки я встречал даже у опытных команд. Так что не стоит думать, что они вас не коснутся.

Ошибка 1: недостаточная диверсификация типов инстансов

Указание одного-двух типов инстансов — верный путь к проблемам. Все инстансы одного типа в одной зоне доступности обслуживаются из одного пула ёмкости. Если этот пул исчерпается, все ваши инстансы вытеснят одновременно.

Решение: указывайте минимум 5–8 совместимых типов из разных семейств (m5, m5a, m6i, c5, c5a, c6i) и используйте минимум 2–3 зоны доступности.

Ошибка 2: отсутствие graceful shutdown

Удивительно, как часто приложения просто не обрабатывают сигнал прерывания. В результате теряются данные, не завершаются транзакции, не закрываются соединения.

Решение: реализуйте обработку SIGTERM, настройте shutdown hooks, используйте preStop hooks в Kubernetes.

Ошибка 3: споты для stateful-нагрузок без репликации

Запуск базы данных или кеша на одном спот-инстансе без реплик — это рецепт катастрофы. И эта катастрофа обязательно произойдёт в самый неподходящий момент (закон Мёрфи никто не отменял).

Решение: stateful-нагрузки на спотах обязательно должны иметь репликацию и автоматическое восстановление. Или просто не используйте споты для этого.

Ошибка 4: слишком низкая максимальная цена

Попытка сэкономить ещё больше, установив максимальную цену ниже рыночной, приводит к частым и непредсказуемым прерываниям.

Решение: установите максимальную цену равной on-demand цене (или -1 в Azure). Вы всё равно заплатите текущую спот-цену, а не максимальную, зато прерывания будут только из-за реальной нехватки ёмкости.

Ошибка 5: отсутствие мониторинга

Без мониторинга вы просто не узнаете, что спот-цены выросли или частота прерываний увеличилась. Экономия может оказаться совсем не такой, как вы рассчитывали.

Решение: настройте дашборды для отслеживания текущих спот-цен, частоты прерываний, соотношения спот/on-demand инстансов и фактической экономии.

Пошаговый план внедрения спот-инстансов

Если вы только начинаете со спотами, вот проверенный план действий:

1. Аудит нагрузок — проанализируйте текущие нагрузки и определите кандидатов. Начните с dev/staging-сред и batch-задач — там риски минимальны.
2. Подготовка приложений — реализуйте graceful shutdown, чекпойнтинг и обработку сигналов прерывания в приложениях-кандидатах.
3. Пилот — запустите 10–20% нагрузки на спотах. Отслеживайте частоту прерываний, время восстановления и влияние на SLA.
4. Масштабирование — постепенно увеличивайте долю спотов, основываясь на результатах пилота. Используйте смешанные флоты с on-demand базовым уровнем.
5. Оптимизация — настройте диверсификацию типов инстансов, стратегии аллокации и автоскейлинг.
6. Мониторинг — настройте непрерывный мониторинг: цены, прерывания, стоимость, SLA-влияние. И не забрасывайте его после запуска.

Заключение

Спот-инстансы — один из самых мощных инструментов экономии в облаке. При правильном подходе они позволяют сократить затраты на вычислительные ресурсы на 60–90%. Для компании с существенным облачным бюджетом это сотни тысяч, а то и миллионы долларов экономии в год.

Ключ ко всему — правильная архитектура. Приложения должны быть спроектированы для работы с прерываниями: stateless-дизайн, чекпойнтинг, graceful shutdown, достаточное количество реплик. И знаете что? Это не усложнение ради усложнения. Это те же принципы отказоустойчивости, которые делают систему надёжнее вне зависимости от типа инстансов.

Комбинируйте спот-инстансы с другими инструментами экономии: Savings Plans или Reserved Instances для базового уровня, споты для переменной и пиковой части, правильное ресурсирование в Kubernetes. Такой многослойный подход — основа зрелой FinOps-практики.

Начните с малого — переведите на споты CI/CD-пайплайны или dev-среду. Оцените экономию, отработайте обработку прерываний, и постепенно расширяйте использование. Через пару месяцев вы не сможете представить свою инфраструктуру без спотов.