Spot Instances AWS vs Azure vs GCP 2026

Оновлено: 30 червня 2026

Spot instances у AWS, Azure та GCP дозволяють заощадити 60–91% від ціни On-Demand завдяки використанню вільної ємності хмари, але кожен провайдер реалізує їх по-своєму. AWS дає 2 хвилини на graceful shutdown і ринкове ціноутворення, Azure та GCP лише 30 секунд, при цьому GCP пропонує фіксовану ціну, а Azure найагресивніші знижки на batch-навантаження. У цьому посібнику я зіставлю реальні ціни, частоту переривань і інструменти управління флотом, щоб ви могли обрати правильного провайдера під конкретний workload у 2026 році.

AWS Spot дає 2-хвилинне попередження про переривання, удвічі більше часу за Azure (30 с) і GCP (30 с), і має найзріліший fleet management через EC2 Fleet та Capacity-Optimized Allocation.
GCP Spot VMs пропонують фіксовану ціну (60–91% знижки) зі змінами раз на ~3 місяці, тоді як AWS змінює Spot-ціни в середньому 197 разів на місяць, а Azure менш ніж раз на місяць.
Середній рівень переривань на AWS становить менше 5% за останні 30 днів (дані Spot Instance Advisor); Azure показує eviction probability у портал, GCP взагалі не публікує даних.
Для batch-обробки (Spark, ML training, CI/CD) Azure часто пропонує найкращу ціну; для production-стійкого Kubernetes AWS Spot з Karpenter; для дешевого передбачуваного бюджету GCP Spot.
Mix 60/40 (On-Demand/Spot) дає у Kubernetes-кластерах середню економію 59%, а pure-Spot до 77% (Kubernetes Cost Benchmark 2025).
Diversification по 3+ типах інстансів та 2+ AZ знижує eviction rate в 4–5 разів. Це найважливіша архітектурна оптимізація.

Що таке Spot instances і як вони працюють у трьох хмарах

Spot instances, це невикористана compute-ємність провайдера, яку він продає зі знижкою 60–91% за умови, що може забрати її назад у будь-який момент. AWS назвав їх Spot Instances ще у 2009 році, Azure запустив Spot VMs у 2020-му (замінивши Low-Priority VMs), а Google перейменував Preemptible VMs на Spot VMs у 2021-му, скасувавши при цьому 24-годинний жорсткий ліміт runtime (хоча для деяких типів він зберігся).

Принцип однаковий у всіх трьох провайдерів: ваша VM/EC2 instance запускається на спільному пулі вільної ємності в конкретному регіоні та AZ. Коли провайдер потребує цю ємність для On-Demand клієнтів або Reserved-зобов'язань, він надсилає сигнал переривання, після чого у вас є від 30 секунд (Azure, GCP) до 2 хвилин (AWS) на checkpoint, drain з'єднань і завершення процесів. Якщо ваша архітектура побудована з урахуванням цього, Spot стає найпотужнішим важелем економії в портфелі FinOps.

У моїй практиці benchmark-а різних провайдерів я бачу, що команди недооцінюють саме операційну зрілість. AWS у 2026 році додав Capacity Manager з per-account Spot interruption metrics, що нарешті дозволяє відстежувати реальну (а не передбачувану) частоту evictions. Azure показує eviction probability у Cost Management, а GCP не публікує даних взагалі. Це треба враховувати при виборі.

Порівняння цін: AWS vs Azure vs GCP у 2026

Перш ніж дивитись на табличку, важливе застереження: Spot-ціни змінюються залежно від регіону, AZ, типу інстансу та часу доби. Цифри нижче для типового instance розміру 4 vCPU / 16 GB у північноамериканських регіонах станом на червень 2026.

Параметр	AWS Spot (m5.xlarge)	Azure Spot (D4s_v5)	GCP Spot (n2-standard-4)
On-Demand ціна	$0.192/год	$0.192/год	$0.194/год
Типова Spot ціна	$0.058/год (~70%)	$0.019–0.058/год (70–90%)	$0.048/год (фіксовано 75%)
Максимальна знижка	~90%	~90%	60–91%
Модель ціноутворення	Ринкова, динамічна	Bid-based, рідкі зміни	Фіксована
Частота зміни ціни	~197/місяць	<1/місяць	Раз на ~3 місяці
Попередження про eviction	2 хвилини	30 секунд	30 секунд
Fleet management	EC2 Fleet, Spot Fleet	VM Scale Sets	MIG, GKE integration
Прозорість interruption rate	Spot Advisor (5-bands)	Eviction probability у portal	Не публікується

Глобальний тренд цікавий: за даними CloudPriceCheck, з 2022 по 2023 рік середні Spot-ціни Azure зросли на 108%, AWS на 21%, а GCP знизились на 26%. Виходить, Google свідомо тисне на ринок дешевшою ємністю, тоді як Microsoft та AWS закладають у Spot премію за зрілість екосистеми.

Переривання та eviction-політики

Найкритичніша різниця між провайдерами, це вікно попередження про переривання. Воно визначає, скільки часу ваш додаток має на graceful shutdown, drain трафіку та збереження стану.

AWS надсилає сигнал переривання через EC2 Instance Metadata Service (IMDS) за 2 хвилини до примусового зупинення. Окремо AWS емітить Rebalance Recommendation, м'якший сигнал без гарантованого вікна, який попереджає про підвищений ризик переривання та дозволяє проактивно замінити інстанс. Це особливо цінно для Karpenter та EC2 Fleet, які можуть запустити заміну ще до фактичного eviction.

Azure доставляє Preempt event через Scheduled Events API на best-effort основі з мінімум 30 секундами попередження. У вас є дві політики eviction: Deallocate (зупинити VM, але зберегти диск і IP, з можливістю перезапуску) або Delete (видалити повністю). Для stateful workloads майже завжди потрібен Deallocate, для stateless container nodes ставлять Delete.

GCP надсилає ACPI G2 soft-off сигнал, який запускає ваш shutdown-скрипт. Жорсткий ліміт 30 секунд, після чого машина примусово вимикається. GCP не публікує конкретних даних про preemption rate, рекомендуючи лише використовувати менші типи machine та запускати workload в off-peak години.

За даними Cast AI, Spot інстанси часто переривають пачками: якщо один m5.large в us-east-1a "помер", швидше за все, ціла група m5.large у тій же AZ помре теж. Чесно кажучи, я в своєму останньому проєкті обпікся саме на цьому: усі 8 нод нашого Spark-кластера полягли за 90 секунд. Diversification по типу інстансу та AZ це не "nice to have", а критично необхідна архітектурна вимога.

AWS Spot: EC2 Fleet, Capacity-Optimized Allocation, Capacity Manager

AWS має найзрілішу екосистему для Spot. У 2026 році стандартом стало використання EC2 Fleet (наступник Spot Fleet) з allocation strategy capacity-optimized-prioritized, яка запитує ємність у тих пулах (instance type × AZ), де AWS прогнозує найнижчий ризик переривання, навіть якщо вони трохи дорожчі.

Найважливіше оновлення року, це EC2 Capacity Manager з per-account Spot interruption metrics, що з січня 2026 дозволяє бачити вашу реальну частоту переривань і порівнювати з прогнозами Spot Instance Advisor. До цього доводилось писати власні CloudWatch-метрики на EventBridge подіях, тепер дані з коробки.

# Запит EC2 Fleet із 5 instance types через 3 AZ для максимальної diversification
aws ec2 create-fleet \
  --type maintain \
  --target-capacity-specification 'TotalTargetCapacity=20,DefaultTargetCapacityType=spot' \
  --spot-options 'AllocationStrategy=capacity-optimized-prioritized,InstanceInterruptionBehavior=terminate' \
  --launch-template-configs file://fleet-config.json

Файл fleet-config.json має перелічувати ваш Launch Template з overrides для різних типів: m5.xlarge, m5a.xlarge, m5n.xlarge, m6i.xlarge, m6a.xlarge через три AZ. Чим більше пулів, тим менше шанс одночасного переривання всього флоту.

Для Kubernetes я майже завжди рекомендую Karpenter із Spot-первинним NodePool. Він автоматично виконує consolidation, реагує на Rebalance Recommendation, і інтегрується з Capacity-Optimized стратегією. Детальний розбір є у статті як зменшити витрати Kubernetes на 40–70%.

Azure Spot VMs: max price, deallocate vs delete, Scheduled Events API

Azure Spot працює на bid-based моделі: ви або встановлюєте maxPrice (максимальна ціна, яку готові платити), або вказуєте -1, що означає "погоджуюсь на поточну Spot-ціну до рівня On-Demand". У моїй практиці -1 майже завжди оптимальний вибір, бо різниця між поточною Spot і On-Demand велика, а evictions рідко спричинені саме перевищенням ціни. Частіше це capacity reclaim.

Друге рішення, це eviction policy:

Deallocate: VM зупиняється, диск і конфігурація зберігаються, ви платите лише за storage. VM можна перезапустити, коли ємність повернеться. Підходить для stateful jobs.
Delete: VM і всі ресурси видаляються повністю. Економить storage cost, ідеально для AKS node pools та batch worker nodes.

Для отримання попередження використовуйте Scheduled Events API через IMDS endpoint:

# Опитування Scheduled Events API на Azure Spot VM
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | jq

# Очікувана відповідь при майбутньому evict:
# {
#   "DocumentIncarnation": 3,
#   "Events": [{
#     "EventId": "...",
#     "EventType": "Preempt",
#     "ResourceType": "VirtualMachine",
#     "Resources": ["myVMName"],
#     "EventStatus": "Scheduled",
#     "NotBefore": "Mon, 30 Jun 2026 10:15:00 GMT"
#   }]
# }

Згідно з офіційною документацією Microsoft, опитувати endpoint потрібно кожні 1–2 секунди, інакше можна пропустити вікно. У AKS це робить вбудований aks-spot-termination-handler, який автоматично cordon і drain ноди.

GCP Spot VMs: фіксована ціна, 24-годинний ліміт, ACPI signal

GCP, це найпростіша модель для бюджетування. Ціна фіксована, прив'язана до machine family та регіону, і змінюється рідко (за моїми спостереженнями, 4 рази на рік максимум). Знижка від On-Demand коливається від 60% (на свіжих T2D/C3) до 91% (на старших N1).

Важливі особливості:

24-годинний максимальний runtime для деяких machine types (особливо A2/A3 GPU). Це означає, що навіть якщо ємність є, GCP всі одно перерве VM через 24 години, і це треба враховувати в архітектурі.
ACPI G2 soft-off signal з 30-секундним вікном. Ваш shutdown script запускається з /etc/init.d або systemd unit.
Інтеграція з GKE Spot Pools та Batch on Compute Engine для автоматичного rebalancing.

# Створення GKE node pool на Spot VMs з автозаміною
gcloud container node-pools create spot-pool \
  --cluster=my-cluster \
  --region=us-central1 \
  --spot \
  --machine-type=n2-standard-4 \
  --num-nodes=3 \
  --enable-autoscaling \
  --min-nodes=0 \
  --max-nodes=20 \
  --node-taints=cloud.google.com/gke-spot=true:NoSchedule

Taint змушує тільки явно tolerant pods приземлятися на Spot ноди. Це захист від випадкового планування критичних workload. Документацію Google по цій темі дивіться у Spot VMs overview.

Які workloads підходять для Spot, а які ні

Це питання я отримую найчастіше. Коротка відповідь: будь-який workload, який можна безпечно перервати і перезапустити менш ніж за 5 хвилин, є кандидатом на Spot.

Підходять:

Batch processing (Spark, Flink, Airflow tasks). Мають built-in checkpointing.
CI/CD runners (GitHub Actions self-hosted, GitLab Runners, Jenkins agents).
ML training з distributed checkpointing (PyTorch Lightning, Hugging Face Accelerate).
Stateless web services за load balancer з 3+ репліками.
Data analytics workloads (Presto/Trino workers, Druid historicals).
Container image build farms, rendering farms, genomics pipelines.

Не підходять:

Primary database nodes (PostgreSQL master, MongoDB primary).
Workload з SLA > 99.9% без надлишкової інфраструктури.
Sticky-session web apps без zero-downtime deployment.
Real-time trading / payment processing з суворими latency вимогами.
Системи з ліцензуванням, прив'язаним до hostname/MAC.

Практичний код: graceful shutdown та diversified fleet

Так, давайте до коду. Ось приклад універсального shutdown-handler для Linux, який працює на всіх трьох провайдерах (визначає cloud автоматично та опитує відповідний metadata endpoint):

#!/usr/bin/env python3
# spot-watcher.py: Універсальний watcher для AWS/Azure/GCP Spot
import requests, subprocess, time, sys

ENDPOINTS = {
    "aws":   ("http://169.254.169.254/latest/meta-data/spot/instance-action",
              {"X-aws-ec2-metadata-token-ttl-seconds": "21600"}),
    "azure": ("http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01",
              {"Metadata": "true"}),
    "gcp":   ("http://metadata.google.internal/computeMetadata/v1/instance/preempted",
              {"Metadata-Flavor": "Google"}),
}

def detect_cloud():
    for cloud, (url, headers) in ENDPOINTS.items():
        try:
            r = requests.get(url, headers=headers, timeout=1)
            if r.status_code in (200, 404):
                return cloud
        except requests.RequestException:
            continue
    sys.exit("Не вдалося визначити cloud-провайдера")

def is_preempting(cloud):
    url, headers = ENDPOINTS[cloud]
    try:
        r = requests.get(url, headers=headers, timeout=1)
        if cloud == "aws":   return r.status_code == 200
        if cloud == "azure": return any(e.get("EventType") == "Preempt" for e in r.json().get("Events", []))
        if cloud == "gcp":   return r.text.strip().lower() == "true"
    except requests.RequestException:
        return False

def graceful_shutdown():
    subprocess.run(["systemctl", "stop", "myapp-healthcheck"], check=False)
    time.sleep(15)
    subprocess.run(["/usr/local/bin/checkpoint-to-cloud.sh"], check=False)
    subprocess.run(["systemctl", "stop", "myapp"], check=False)

cloud = detect_cloud()
print(f"Запущено на {cloud}, моніторинг переривань...")
while True:
    if is_preempting(cloud):
        print(f"Отримано сигнал переривання від {cloud}, починаю shutdown")
        graceful_shutdown()
        break
    time.sleep(2)

Як поєднати Spot із Savings Plans та Reserved Instances

Spot, це інструмент для burst, а не baseline. Класична трирівнева стратегія, яку я впроваджую клієнтам:

30–40% baseline на 3-річних Compute Savings Plans (AWS) / Reservations (Azure) / CUDs (GCP). Знижка 40–55%, гарантована ємність.
10–20% buffer на On-Demand для трафіку, який неможливо запустити на Spot (primary DB, payment gateways).
40–60% elastic capacity на Spot для всього іншого: Kubernetes worker nodes, batch jobs, ML training.

Результат? Middleweight startup із $50K/міс AWS-рахунком зазвичай скорочує його до $22–28K без втрати продуктивності. Більше про оптимізацію витрат на GPU-навантаження є у статті як оптимізувати витрати на GPU для AI/ML.

Типові помилки при роботі зі Spot

Один instance type, одна AZ. Перша помилка всіх. Diversifyуйте мінімум 3 типи × 2 AZ.
Spot для stateful workload без checkpointing. Втрата 6-годинного ML training tasks через відсутність checkpointing, це втрата сотень доларів.
Ігнорування Rebalance Recommendation на AWS. Цей сигнал часто з'являється за 10–15 хвилин до фактичного eviction.
На Azure: maxPrice нижче On-Demand. Це не знижує вашу ціну, тільки збільшує eviction rate.
На GCP: забути про 24-годинний ліміт. Довгі ML jobs треба архітектурно розбивати на 20-годинні chunks.
Mix On-Demand і Spot в одному ASG/MIG без правильного розділення. Kubernetes scheduler не знає, які pods можна переривати, тому використовуйте taints/tolerations.

Часті запитання

Скільки можна заощадити на Spot Instances порівняно з On-Demand?

У середньому 60–90% залежно від провайдера, регіону та типу інстансу. AWS Spot Instance Advisor показує середню знижку 70%, Azure Spot 70–90% на batch-навантаженнях, GCP Spot фіксовано 60–91%. У реальних production-кластерах Kubernetes mix Spot/On-Demand дає економію близько 59%, а pure-Spot до 77%.

Який провайдер має найнижчу частоту переривань Spot?

За даними AWS Spot Instance Advisor, середня частота переривань на AWS становить менше 5% за останні 30 днів. Azure та GCP не публікують точних даних, але індустріальні бенчмарки Cast AI показують схожі цифри. Найважливіший фактор не провайдер, а diversification: 3+ типи інстансів і 2+ AZ знижують eviction rate в 4–5 разів незалежно від хмари.

Чи можна запускати Kubernetes production на Spot instances?

Так, але з правильною архітектурою. Рекомендується mix 30–40% On-Demand для контрольної площини та критичних stateful pods (etcd, primary databases), а worker nodes для stateless workloads на Spot з Karpenter або Cluster Autoscaler. PodDisruptionBudgets, anti-affinity rules та readiness probes мають бути налаштовані правильно.

Чим відрізняються AWS Spot Instances від AWS Spot Fleet?

Spot Instance, це одна EC2 машина, запущена на Spot ціні. Spot Fleet (тепер EC2 Fleet) це менеджер, який підтримує задану цільову ємність, автоматично запитуючи ємність з найкращих пулів (instance type × AZ) і замінюючи перервані інстанси. Для production завжди використовуйте EC2 Fleet з allocation strategy capacity-optimized-prioritized, а не окремі Spot instances.

Що сталося з Google Preemptible VMs?

Google перейменував Preemptible VMs на Spot VMs у 2021 році та зняв жорсткий 24-годинний ліміт runtime для більшості machine types. Старі Preemptible VMs продовжують працювати, але всі нові інстанси рекомендується створювати як Spot VMs. Вони мають таку ж ціну, але без обмеження тривалості (крім A2/A3 GPU instances, де ліміт зберігся).