Экономия в облаке 2026: RI и Savings Plans

Введение: почему обязательства — главный рычаг экономии в облаке

В 2026 году расходы на облачную инфраструктуру продолжают расти с пугающей скоростью. По данным Gartner, мировые расходы на публичные облачные сервисы превысили 830 миллиардов долларов. А средняя компания тратит на облако на 25–35% больше, чем планировала. Знакомая ситуация, правда?

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

Среди всех инструментов оптимизации — от rightsizing до спот-инстансов — именно обязательства на потребление (commitments) остаются самым мощным рычагом экономии. Скидки от 30% до 75% по сравнению с ценами on-demand делают их незаменимым элементом любой зрелой облачной стратегии. Честно говоря, если вы ещё не используете обязательства, вы буквально сжигаете деньги.

За последний год в этой области произошло несколько важных изменений. AWS продолжает развивать Savings Plans как основной механизм, постепенно сужая доступность классических Reserved Instances. Azure значительно расширил возможности Savings Plans for Compute, добавив поддержку новых сервисов. А Google Cloud полностью перешёл на spend-based модель CUD, заменив ресурсные обязательства гибкими планами на основе расходов.

Все эти изменения требуют пересмотра устоявшихся подходов. Итак, давайте разберёмся во всём по порядку.

Типы обязательств в облачных провайдерах

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

AWS предлагает два основных механизма: Reserved Instances (RI) — привязанные к конкретным ресурсам, и Savings Plans (SP) — более гибкие обязательства на основе долларовых расходов в час. Оба доступны на 1 или 3 года.
Azure использует Azure Reservations (аналог RI), Savings Plans for Compute и уникальный механизм Azure Hybrid Benefit для лицензий Windows Server и SQL Server. Сроки — 1 или 3 года.
GCP применяет Committed Use Discounts (CUD), которые в 2026 году полностью перешли на spend-based модель. Доступны сроки 1 и 3 года, а для некоторых сервисов — гибкие обязательства (Flex CUD).

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

AWS: Reserved Instances и Savings Plans

Reserved Instances: классический подход

Reserved Instances (RI) — исторически первый механизм обязательств в AWS, существующий с 2009 года. Несмотря на то что AWS активно продвигает Savings Plans, RI по-прежнему доступны и в ряде случаев дают максимальные скидки.

Существует два основных типа RI:

Standard RI — обеспечивают максимальную скидку (до 72% для Linux-инстансов при 3-летнем сроке с полной предоплатой), но гибкость ограничена. Их можно продавать на AWS Reserved Instance Marketplace, но менять семейство инстансов нельзя.
Convertible RI — позволяют менять семейство инстансов, операционную систему и тип тенанта в пределах одного региона. Скидки чуть ниже (до 66%), но гибкость значительно выше.

RI применяются к конкретным типам инстансов EC2, а также доступны для RDS, ElastiCache, Redshift, OpenSearch и DynamoDB. Важный момент — RI в AWS поддерживают размерную гибкость (instance size flexibility) внутри одного семейства. Например, один RI для m5.2xlarge может покрыть два m5.xlarge или четыре m5.large. Это реально удобная штука, которая часто спасает при небольших изменениях в инфраструктуре.

Savings Plans: современный и гибкий подход

Savings Plans, запущенные в 2019 году, — это обязательство на определённую сумму расходов в час (скажем, $10/час) в обмен на скидки. В 2026 году AWS предлагает три типа:

Compute Savings Plans — максимально гибкие. Применяются к EC2, Fargate и Lambda в любом регионе, любом семействе инстансов, любой ОС. Скидки до 66% по сравнению с on-demand.
EC2 Instance Savings Plans — привязаны к конкретному семейству инстансов в конкретном регионе, зато скидки повыше (до 72%). Гибкость по размеру, ОС и тенанту сохраняется.
SageMaker Savings Plans — специализированные планы для ML-нагрузок на Amazon SageMaker. Скидки до 64%.

Главное преимущество Savings Plans — простота. Вместо подбора правильных типов инстансов для каждого RI вы просто указываете сумму, которую готовы тратить в час. AWS автоматически применяет скидку к самым дорогим ресурсам в первую очередь — максимизируя вашу экономию без лишних телодвижений.

Ключевые различия и когда что использовать

Выбор между RI и Savings Plans зависит от конкретной ситуации:

Стабильные, предсказуемые нагрузки с известным типом инстансов — EC2 Instance Savings Plans или Standard RI обеспечат максимальную скидку.
Динамичные среды, где часто меняются типы инстансов или регионы — Compute Savings Plans дают лучший баланс скидки и гибкости.
Сервисы без поддержки Savings Plans (RDS, ElastiCache, Redshift) — здесь RI остаются единственным вариантом.
ML-нагрузки на SageMaker — используйте SageMaker Savings Plans.

Лучшая практика — комбинировать оба инструмента. Сначала покрыть стабильный базовый уровень EC2 Instance Savings Plans, затем добавить Compute Savings Plans для переменной части, и наконец использовать RI для баз данных. По моему опыту, именно такой многослойный подход даёт максимальную экономию.

Azure: Резервирования и Savings Plans

Azure Reserved VM Instances

Azure Reservations работают по схожему с AWS RI принципу — вы резервируете конкретный тип виртуальной машины в конкретном регионе на 1 или 3 года. Скидки впечатляют: до 72% для Linux-машин и до 80% при комбинации с Azure Hybrid Benefit для Windows Server.

Azure Reservations доступны для широкого спектра сервисов:

Virtual Machines (включая изолированные размеры)
Azure SQL Database и SQL Managed Instance
Azure Cosmos DB
Azure Synapse Analytics
Azure Blob Storage (reserved capacity)
Azure Files
Azure Data Explorer
Azure VMware Solution
Azure Red Hat OpenShift

Приятная особенность Azure — гибкость размера инстанса включена по умолчанию. Резервирование D4s_v5 может автоматически покрыть два D2s_v5 или один D8s_v5 (с учётом коэффициентов нормализации). Это существенно снижает риск простаивания резервирований при изменении размеров виртуальных машин.

Azure Savings Plans for Compute

Запущенные в 2022 году, Azure Savings Plans for Compute предлагают скидки до 65% в обмен на обязательство фиксированной суммы расходов в час. Они применяются к:

Azure Virtual Machines (все серии, регионы, ОС)
Azure App Service (выделенные планы)
Azure Container Instances
Azure Functions Premium

Savings Plans в Azure дают значительно большую гибкость по сравнению с резервированиями — вы не привязаны к конкретному размеру VM, серии или региону. Но скидки обычно чуть ниже, чем при резервировании конкретного типа VM. Такой вот компромисс.

Azure Hybrid Benefit

Уникальное преимущество Azure — программа Hybrid Benefit. Она позволяет использовать существующие лицензии Windows Server и SQL Server с Software Assurance в облаке. Экономия может достигать 40% для Windows Server и до 55% для SQL Server. А при комбинации с Reserved Instances общая скидка может превышать 80% от цены on-demand. Восемьдесят процентов — это серьёзно.

В 2026 году Microsoft расширил программу, включив поддержку Red Hat и SUSE Linux Enterprise через Azure Hybrid Benefit for Linux. Организации с существующими подписками теперь могут переносить их в Azure без двойной оплаты.

Варианты оплаты

Azure предлагает три варианта оплаты для резервирований:

Полная предоплата (All upfront) — максимальная скидка, одноразовый платёж за весь срок.
Частичная предоплата (Partial upfront) — часть суммы вносится сразу, остальное — ежемесячными платежами.
Без предоплаты (Monthly payments) — равномерные ежемесячные платежи без первоначального взноса. Скидка чуть ниже, зато нагрузка на бюджет распределена равномерно.

Для Savings Plans доступна оплата ежемесячно или с полной предоплатой. Кстати, в Azure разница между вариантами оплаты минимальна — в отличие от AWS, где полная предоплата даёт заметно более высокую скидку.

GCP: Committed Use Discounts

Ресурсные CUD: устаревающая модель

Исторически Google Cloud предлагал ресурсные CUD (resource-based Committed Use Discounts), при которых вы обязывались использовать определённое количество vCPU и памяти в конкретном регионе. Скидки были неплохие — до 57% при 3-летнем обязательстве для обычных машин и до 70% для memory-optimized.

Ресурсные CUD применялись к Compute Engine и GKE, привязывались к конкретному региону и типу машины. Они автоматически применялись к подходящим ресурсам в проекте — проще, чем RI в AWS.

Spend-based CUD: новая модель 2026 года

С января 2026 года Google Cloud полностью перешёл на spend-based модель CUD. Теперь обязательства основаны на суммах расходов, а не на конкретных ресурсах. Концептуально это ближе к Savings Plans в AWS и Azure.

Ключевые особенности spend-based CUD:

Гибкость — обязательство покрывает расходы на широкий спектр сервисов GCP: Compute Engine, GKE, Cloud SQL, Cloud Run и другие.
Автоматическое применение — скидки автоматически распределяются по наиболее дорогим ресурсам.
Региональная гибкость — возможность покрытия расходов в разных регионах (зависит от типа обязательства).
Сроки — обязательства на 1 и 3 года с соответствующими уровнями скидок.

Flex CUD

GCP также предлагает Flex CUD — краткосрочные обязательства от 1 года, но с возможностью досрочного прекращения через 30 дней (со штрафом). Скидки поменьше, зато риск значительно ниже. Flex CUD — отличный вариант для нагрузок с неопределённым горизонтом планирования или для тех, кто только начинает работать с обязательствами и хочет «пощупать» механизм.

Отличия от подхода AWS и Azure

Подход GCP к обязательствам имеет несколько принципиальных отличий:

Sustained Use Discounts (SUD) — GCP автоматически предоставляет скидки при стабильном использовании ресурсов, даже без явных обязательств. Скидки достигают 30% при использовании ресурсов весь месяц. Ни AWS, ни Azure ничего подобного не предлагают.
Автоматическое применение — CUD применяются ко всем подходящим ресурсам в биллинговом аккаунте, без привязки к конкретным проектам.
Отсутствие маркетплейса — в отличие от AWS, GCP не позволяет перепродавать неиспользуемые обязательства.
Проще для старта — с переходом на spend-based модель управление CUD стало концептуально проще, чем система RI + SP в AWS.

Сравнительная таблица провайдеров

Параметр	AWS	Azure	GCP
Механизмы обязательств	Reserved Instances + Savings Plans	Reservations + Savings Plans for Compute	Spend-based CUD + Flex CUD
Максимальная скидка (compute)	До 72% (Standard RI, 3 года, полная предоплата)	До 72% (Reservations, 3 года); до 80% с Hybrid Benefit	До 70% (3-летние CUD, memory-optimized)
Гибкость (наилучшая опция)	Compute Savings Plans: любой регион, семейство, ОС	Savings Plans: любой регион, серия, ОС	Spend-based CUD: автоматическое применение по биллинговому аккаунту
Сроки обязательств	1 год, 3 года	1 год, 3 года	1 год, 3 года; Flex CUD (от 30 дней)
Варианты оплаты	Полная предоплата, частичная, без предоплаты	Полная предоплата, ежемесячно	Ежемесячно (автоматические списания)
Область применения (scope)	Аккаунт, организация (linked accounts)	Подписка, группа ресурсов, общий доступ (shared scope)	Биллинговый аккаунт (все проекты)
Покрытие сервисов	RI: EC2, RDS, ElastiCache, Redshift, etc. SP: EC2, Fargate, Lambda, SageMaker	Reservations: VM, SQL, Cosmos DB, etc. SP: VM, App Service, ACI, Functions	CUD: Compute Engine, GKE, Cloud SQL, Cloud Run и другие
Автоматические скидки	Нет	Нет	Да (Sustained Use Discounts до 30%)
Маркетплейс для перепродажи	Да (для Standard RI)	Нет	Нет
Обмен/конвертация	Convertible RI: да. Standard RI: нет. SP: нет	Обмен резервирований (с ограничениями). SP: нет	Нет (но Flex CUD можно отменить)

FinOps-стратегия управления обязательствами

Роль центральной FinOps-команды

Управление обязательствами должно быть централизованным. Распределение ответственности между отдельными командами неизбежно приводит к фрагментации, дублированию и неоптимальному покрытию. Центральная FinOps-команда (или выделенный FinOps-инженер в небольших организациях) отвечает за:

Анализ текущего использования и прогнозирование будущих потребностей
Определение оптимального микса обязательств (RI + SP + CUD)
Закупку и управление жизненным циклом обязательств
Мониторинг утилизации и покрытия
Регулярный пересмотр стратегии (ежемесячно или ежеквартально)
Отчётность и коммуникацию экономии руководству

Целевые показатели покрытия

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

70–80% покрытие стабильных, предсказуемых нагрузок (production-среды, базы данных, основные сервисы)
40–60% покрытие умеренно предсказуемых нагрузок (staging, внутренние инструменты)
0–20% покрытие непредсказуемых нагрузок (dev/test, экспериментальные проекты) — здесь лучше использовать spot/preemptible

Общее целевое покрытие в 70–90% от стабильной базовой нагрузки — хороший ориентир для зрелых организаций. Недопокрытие — это упущенная экономия. Перепокрытие — напрасные расходы. Найти баланс — вот в чём искусство.

Модель зрелости: Crawl / Walk / Run

Внедрение стратегии обязательств должно быть поэтапным. Не пытайтесь перепрыгнуть через этапы — это почти всегда заканчивается перекоммитментом.

Crawl (начальный этап):

Начните с 1-летних обязательств для самых стабильных нагрузок
Покройте 30–50% базовой нагрузки
Используйте наиболее гибкие инструменты (Compute Savings Plans, spend-based CUD)
Настройте базовый мониторинг утилизации

Walk (средний этап):

Увеличьте покрытие до 60–75%
Добавьте более специфичные обязательства (EC2 Instance SP, Azure Reservations) для максимизации скидок
Внедрите 3-летние обязательства для самых стабильных ресурсов
Автоматизируйте рекомендации и отчётность

Run (продвинутый этап):

Покрытие 80–90% стабильной нагрузки
Оптимальный микс RI + SP + CUD + Spot
Автоматизированная закупка и управление
Прогнозирование с использованием ML-моделей
Интеграция с CI/CD и процессами планирования инфраструктуры

Управление рисками: короткие vs длинные сроки

Выбор срока обязательства — это всегда компромисс между размером скидки и риском:

1-летние обязательства — скидка меньше (обычно на 15–25% ниже, чем 3-летние), зато риск значительно ниже. Идеальны для нагрузок с горизонтом планирования менее 2 лет или для организаций с высокой скоростью изменений.
3-летние обязательства — максимальная скидка, но высокий риск привязки. Рекомендуются только для абсолютно стабильных нагрузок (production-базы данных, core-инфраструктура).

Практическое правило: начинайте с 1-летних обязательств и переходите к 3-летним только после 12–18 месяцев исторических данных, подтверждающих стабильность потребления. Не торопитесь — три года это долго.

Комбинированная стратегия

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

Базовый слой (60–70% от стабильной нагрузки) — покрыть обязательствами (RI/SP/CUD) со сроком 1–3 года
Переменный слой (15–25%) — использовать Spot/Preemptible инстансы для устойчивых к прерываниям нагрузок
Пиковый слой (10–20%) — оставить на on-demand для непредсказуемых пиков

Практическое руководство: как выбрать оптимальную стратегию

Пошаговый процесс

Вот конкретный план действий для построения стратегии обязательств:

Соберите данные — проанализируйте историческое использование за последние 3–6 месяцев
Определите базовый уровень — найдите минимальный стабильный уровень потребления, который не опускается ниже определённого порога
Классифицируйте нагрузки — разделите на стабильные, переменные и непредсказуемые
Выберите тип обязательств — для каждой категории определите оптимальный инструмент
Определите срок и объём — рассчитайте сумму обязательств на основе базового уровня
Приобретите обязательства — закупайте поэтапно, не всё сразу
Мониторьте и корректируйте — еженедельно проверяйте утилизацию, ежемесячно пересматривайте стратегию

Анализ использования с помощью AWS CLI

Ниже — примеры команд AWS CLI для анализа текущего использования и получения рекомендаций по Savings Plans. Рекомендую начать именно с них, чтобы получить объективную картину:

# Получить рекомендации по Savings Plans от AWS Cost Explorer
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type "COMPUTE_SP" \
  --term-in-years "ONE_YEAR" \
  --payment-option "NO_UPFRONT" \
  --lookback-period-in-days "SIXTY_DAYS" \
  --output json

# Получить текущее покрытие Savings Plans
aws ce get-savings-plans-coverage \
  --time-period Start=2026-01-01,End=2026-01-31 \
  --granularity MONTHLY \
  --output table

# Получить утилизацию существующих Savings Plans
aws ce get-savings-plans-utilization \
  --time-period Start=2026-01-01,End=2026-01-31 \
  --granularity MONTHLY \
  --output table

# Посмотреть текущие активные Savings Plans
aws savingsplans describe-savings-plans \
  --states "active" \
  --output table

# Получить рекомендации по Reserved Instances для EC2
aws ce get-reservation-purchase-recommendation \
  --service "Amazon Elastic Compute Cloud - Compute" \
  --term-in-years "ONE_YEAR" \
  --payment-option "NO_UPFRONT" \
  --lookback-period-in-days "SIXTY_DAYS"

# Проверить утилизацию Reserved Instances
aws ce get-reservation-utilization \
  --time-period Start=2026-01-01,End=2026-01-31 \
  --granularity MONTHLY \
  --output table

Python-скрипт для анализа утилизации обязательств

Следующий скрипт анализирует утилизацию Savings Plans и Reserved Instances, выявляет проблемные области и генерирует рекомендации. Мы используем похожий подход у себя — работает на удивление хорошо:

import boto3
import json
from datetime import datetime, timedelta


def analyze_commitment_utilization(months_back=3):
    """
    Анализирует утилизацию Savings Plans и Reserved Instances
    за указанный период и генерирует рекомендации.
    """
    ce_client = boto3.client('ce')
    sp_client = boto3.client('savingsplans')

    end_date = datetime.now().strftime('%Y-%m-%d')
    start_date = (datetime.now() - timedelta(days=months_back * 30)).strftime('%Y-%m-%d')

    results = {
        'savings_plans': {},
        'reserved_instances': {},
        'recommendations': []
    }

    # --- Анализ Savings Plans ---
    try:
        sp_utilization = ce_client.get_savings_plans_utilization(
            TimePeriod={'Start': start_date, 'End': end_date},
            Granularity='MONTHLY'
        )

        for period in sp_utilization['SavingsPlansUtilizationsByTime']:
            month = period['TimePeriod']['Start'][:7]
            utilization_pct = float(
                period['Utilization']['UtilizationPercentage']
            )
            total_commitment = float(
                period['Utilization']['TotalCommitment']
            )
            used_commitment = float(
                period['Utilization']['UsedCommitment']
            )
            unused = float(
                period['Utilization']['UnusedCommitment']
            )

            results['savings_plans'][month] = {
                'utilization_pct': utilization_pct,
                'total_commitment': total_commitment,
                'used_commitment': used_commitment,
                'unused_commitment': unused
            }

            # Предупреждение при низкой утилизации
            if utilization_pct < 80:
                results['recommendations'].append({
                    'type': 'WARNING',
                    'message': (
                        f'Низкая утилизация Savings Plans в {month}: '
                        f'{utilization_pct:.1f}%. '
                        f'Неиспользованные обязательства: ${unused:,.2f}'
                    )
                })

    except Exception as e:
        print(f"Ошибка при анализе Savings Plans: {e}")

    # --- Анализ Reserved Instances ---
    try:
        ri_utilization = ce_client.get_reservation_utilization(
            TimePeriod={'Start': start_date, 'End': end_date},
            Granularity='MONTHLY'
        )

        for period in ri_utilization['UtilizationsByTime']:
            month = period['TimePeriod']['Start'][:7]
            util_pct = float(
                period['Total']['UtilizationPercentage']
            )

            results['reserved_instances'][month] = {
                'utilization_pct': util_pct
            }

            if util_pct < 80:
                results['recommendations'].append({
                    'type': 'WARNING',
                    'message': (
                        f'Низкая утилизация RI в {month}: '
                        f'{util_pct:.1f}%. '
                        f'Рассмотрите продажу неиспользуемых RI на Marketplace.'
                    )
                })

    except Exception as e:
        print(f"Ошибка при анализе Reserved Instances: {e}")

    # --- Получение рекомендаций по покупке ---
    try:
        sp_recs = ce_client.get_savings_plans_purchase_recommendation(
            SavingsPlansType='COMPUTE_SP',
            TermInYears='ONE_YEAR',
            PaymentOption='NO_UPFRONT',
            LookbackPeriodInDays='SIXTY_DAYS'
        )

        for rec in sp_recs.get(
            'SavingsPlansPurchaseRecommendation', {}
        ).get('SavingsPlansPurchaseRecommendationDetails', []):

            hourly_commitment = float(
                rec['HourlyCommitmentToPurchase']
            )
            estimated_savings_pct = float(
                rec['EstimatedSavingsPercentage']
            )
            estimated_monthly_savings = float(
                rec['EstimatedMonthlySavingsAmount']
            )

            results['recommendations'].append({
                'type': 'RECOMMENDATION',
                'message': (
                    f'Рекомендуется приобрести Compute SP: '
                    f'${hourly_commitment:.4f}/час. '
                    f'Ожидаемая экономия: {estimated_savings_pct:.1f}% '
                    f'(~${estimated_monthly_savings:,.0f}/мес)'
                )
            })

    except Exception as e:
        print(f"Ошибка при получении рекомендаций: {e}")

    # --- Анализ покрытия ---
    try:
        coverage = ce_client.get_savings_plans_coverage(
            TimePeriod={'Start': start_date, 'End': end_date},
            Granularity='MONTHLY'
        )

        for period in coverage['SavingsPlansCoverages']:
            month = period['TimePeriod']['Start'][:7]
            coverage_pct = float(
                period['Attributes'].get('CoveragePercentage', 0)
            ) if 'Attributes' in period else 0

            if coverage_pct < 70:
                results['recommendations'].append({
                    'type': 'INFO',
                    'message': (
                        f'Покрытие Savings Plans в {month}: '
                        f'{coverage_pct:.1f}%. '
                        f'Целевой показатель: 70-80%.'
                    )
                })

    except Exception as e:
        print(f"Ошибка при анализе покрытия: {e}")

    return results


def print_report(results):
    """Форматированный вывод отчёта об утилизации."""
    print("=" * 70)
    print("ОТЧЁТ ОБ УТИЛИЗАЦИИ ОБЯЗАТЕЛЬСТВ")
    print("=" * 70)

    print("\n--- Savings Plans: утилизация по месяцам ---")
    for month, data in sorted(results['savings_plans'].items()):
        bar = "█" * int(data['utilization_pct'] / 2)
        print(
            f"  {month}: {data['utilization_pct']:6.1f}% "
            f"|{bar:<50}| "
            f"${data['used_commitment']:>10,.2f} / "
            f"${data['total_commitment']:>10,.2f}"
        )

    print("\n--- Reserved Instances: утилизация по месяцам ---")
    for month, data in sorted(results['reserved_instances'].items()):
        bar = "█" * int(data['utilization_pct'] / 2)
        print(
            f"  {month}: {data['utilization_pct']:6.1f}% "
            f"|{bar:<50}|"
        )

    print("\n--- Рекомендации ---")
    for rec in results['recommendations']:
        icon = {
            'WARNING': '[!]',
            'RECOMMENDATION': '[+]',
            'INFO': '[i]'
        }.get(rec['type'], '[-]')
        print(f"  {icon} {rec['message']}")

    print("\n" + "=" * 70)


if __name__ == '__main__':
    results = analyze_commitment_utilization(months_back=3)
    print_report(results)

Автоматизация управления обязательствами

Инструменты автоматизации

Ручное управление обязательствами становится неэффективным по мере роста инфраструктуры. В 2026 году доступен ряд специализированных платформ:

ProsperOps — автоматизированная платформа для управления Savings Plans и RI в AWS. Использует алгоритмы для динамической закупки обязательств, максимизируя экономию при минимальном риске. Средняя экономия клиентов — 40–50% от on-demand.
Antimetal — платформа с групповыми скидками и автоматизированным управлением обязательствами. Гарантирует экономию. Особенно интересна для стартапов и средних компаний.
nOps — комплексная FinOps-платформа с модулем автоматической закупки обязательств, поддерживающая AWS, Azure и GCP. Включает функцию автоматического rightsizing перед покупкой — это важная деталь.
CloudHealth by VMware — enterprise-решение для мультиоблачного управления затратами с модулями рекомендаций и управления обязательствами.
Spot by NetApp — платформа для оптимизации вычислительных затрат, комбинирующая управление обязательствами со spot-инстансами.

Встроенные рекомендации провайдеров

AWS Cost Explorer предоставляет встроенные рекомендации по покупке RI и Savings Plans на основе исторического использования. Рекомендации обновляются ежедневно и учитывают паттерны потребления за 7, 30 или 60 дней.

Azure Advisor анализирует использование виртуальных машин и предлагает рекомендации по покупке резервирований. В 2026 году Azure добавил рекомендации по Savings Plans и улучшил точность прогнозов с помощью ML.

Google Cloud Recommender автоматически генерирует рекомендации по CUD на основе исторического использования. Доступ через консоль, gcloud CLI и API.

Управление обязательствами как код (Terraform)

Для организаций, практикующих Infrastructure as Code, управление обязательствами через Terraform — это повторяемость, аудитируемость и интеграция с CI/CD. Вот пример конфигурации:

# Terraform конфигурация для управления обязательствами в AWS и Azure

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

# ============================================
# AWS Savings Plans
# ============================================

# Compute Savings Plan — максимальная гибкость
resource "aws_savings_plan" "compute_baseline" {
  savings_plan_type = "Compute"
  commitment        = "15.00"  # $15/час
  term              = "1yr"
  payment_option    = "NoUpfront"

  tags = {
    Name        = "compute-baseline-sp"
    Environment = "production"
    ManagedBy   = "terraform"
    FinOps      = "central-team"
    ExpiryDate  = "2027-02-01"
  }
}

# EC2 Instance Savings Plan — более высокая скидка
# для стабильных рабочих нагрузок
resource "aws_savings_plan" "ec2_production" {
  savings_plan_type    = "EC2Instance"
  commitment           = "8.50"  # $8.50/час
  term                 = "3yr"
  payment_option       = "PartialUpfront"
  instance_family      = "m6i"
  region               = "us-east-1"

  tags = {
    Name        = "ec2-production-sp"
    Environment = "production"
    ManagedBy   = "terraform"
    FinOps      = "central-team"
    Workload    = "api-servers"
    ExpiryDate  = "2029-02-01"
  }
}

# ============================================
# Azure Reservations
# ============================================

# Резервирование виртуальных машин Azure
resource "azurerm_capacity_reservation_group" "production" {
  name                = "production-reservation-group"
  resource_group_name = "rg-finops"
  location            = "westeurope"

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
    FinOps      = "central-team"
  }
}

resource "azurerm_capacity_reservation" "web_servers" {
  name                          = "web-servers-reservation"
  capacity_reservation_group_id = azurerm_capacity_reservation_group.production.id

  sku {
    name     = "Standard_D4s_v5"
    capacity = 10  # 10 инстансов
  }

  tags = {
    Workload = "web-frontend"
  }
}

# ============================================
# Модуль мониторинга обязательств
# ============================================

# CloudWatch alarm для мониторинга утилизации SP
resource "aws_cloudwatch_metric_alarm" "sp_utilization_low" {
  alarm_name          = "savings-plans-low-utilization"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 3
  metric_name         = "SavingsPlanUtilization"
  namespace           = "AWS/CostExplorer"
  period              = 86400  # 1 день
  statistic           = "Average"
  threshold           = 80
  alarm_description   = "Утилизация Savings Plans ниже 80% — требуется анализ"

  alarm_actions = [aws_sns_topic.finops_alerts.arn]

  tags = {
    ManagedBy = "terraform"
    Team      = "finops"
  }
}

# SNS topic для уведомлений FinOps-команды
resource "aws_sns_topic" "finops_alerts" {
  name = "finops-commitment-alerts"

  tags = {
    ManagedBy = "terraform"
    Team      = "finops"
  }
}

resource "aws_sns_topic_subscription" "finops_email" {
  topic_arn = aws_sns_topic.finops_alerts.arn
  protocol  = "email"
  endpoint  = "[email protected]"
}

# ============================================
# Выходные данные для отчётности
# ============================================

output "compute_sp_hourly_commitment" {
  description = "Часовое обязательство Compute Savings Plan"
  value       = aws_savings_plan.compute_baseline.commitment
}

output "ec2_sp_hourly_commitment" {
  description = "Часовое обязательство EC2 Instance Savings Plan"
  value       = aws_savings_plan.ec2_production.commitment
}

output "total_hourly_commitment" {
  description = "Общее часовое обязательство по всем Savings Plans"
  value       = tonumber(aws_savings_plan.compute_baseline.commitment) + tonumber(aws_savings_plan.ec2_production.commitment)
}

Такой подход позволяет управлять обязательствами через pull requests, проводить code review перед покупкой и вести полную историю изменений. Для крупных организаций рекомендую создать отдельный Terraform-модуль для обязательств с чётким процессом утверждения.

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

Ошибка 1: Перекоммитмент (over-commitment)

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

Как избежать: начинайте с покрытия 60–70% минимального стабильного уровня. Лучше недопокрыть и дозакупить позже, чем переплатить за простаивающие обязательства. Полезная формула: объём обязательств = P10 использования (10-й перцентиль за последние 90 дней).

Ошибка 2: Отсутствие мониторинга утилизации

Многие организации покупают обязательства и забывают о них до момента продления. За это время нагрузки могут измениться, инстансы могут быть удалены, и обязательства начинают простаивать. Видел это не раз.

Как избежать: настройте еженедельные отчёты об утилизации. Установите пороговые значения для алертов (утилизация ниже 80%). Назначьте ответственного за регулярный пересмотр портфеля обязательств.

Ошибка 3: Игнорирование изменений в нагрузках

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

Как избежать: перед покупкой обязательно согласуйте с командами разработки и архитектуры планы на ближайшие 12–36 месяцев. Для нагрузок с неопределённым будущим используйте только 1-летние обязательства или гибкие варианты (Compute SP, Flex CUD).

Ошибка 4: Использование только одного типа обязательств

Некоторые организации используют исключительно Savings Plans, игнорируя RI для баз данных. Или наоборот — покупают только RI, упуская гибкость Savings Plans. Монотипная стратегия неизбежно оставляет деньги на столе.

Как избежать: выстройте многослойную стратегию. Для EC2 комбинируйте EC2 Instance SP (стабильное ядро) + Compute SP (гибкое покрытие). Для баз данных — RI. Для непредсказуемых нагрузок — Spot.

Ошибка 5: Единовременная закупка всего объёма

Покупка всех обязательств одномоментно создаёт «стену продлений» — момент, когда все обязательства истекают одновременно. Это провоцирует резкий скачок затрат и давление на принятие быстрых решений.

Как избежать: распределяйте закупки во времени. Покупайте обязательства ежемесячно или ежеквартально, равными порциями. Это создаёт «лестницу продлений» (staggered renewals), при которой каждый месяц обновляется лишь небольшая часть портфеля.

Ошибка 6: Отсутствие процесса утверждения

Покупка обязательств — это финансовое решение, нередко на сотни тысяч долларов. Без формального процесса утверждения легко ошибиться: не тот тип, не тот регион, не тот срок.

Как избежать: внедрите процесс утверждения с использованием Infrastructure as Code. Каждая покупка проходит через pull request, code review и утверждение FinOps-лидом и финансовым контролёром.

Ошибка 7: Непроведение rightsizing перед покупкой

Покупка обязательств для oversized инстансов фиксирует неэффективность на 1–3 года. Если ваши m5.2xlarge загружены на 15%, вы получите скидку на ресурсы, которые вам не нужны в таком объёме.

Как избежать: всегда проводите rightsizing до покупки обязательств. Оптимизируйте размеры инстансов, удалите неиспользуемые ресурсы, и только после стабилизации потребления приобретайте обязательства.

Заключение

Обязательства на потребление облачных ресурсов остаются самым эффективным инструментом оптимизации затрат в 2026 году. Правильно выстроенная стратегия способна снизить облачные расходы на 30–50% — для крупных организаций это миллионы долларов ежегодно.

Подведём итоги:

Комбинируйте инструменты — RI для баз данных, EC2 Instance SP для стабильного ядра, Compute SP для гибкого покрытия, Spot для устойчивых к прерываниям задач.
Начинайте консервативно — покрывайте 60–70% стабильной базовой нагрузки и постепенно увеличивайте покрытие по мере накопления данных.
Мониторьте непрерывно — автоматические отчёты и алерты для отслеживания утилизации и покрытия.
Автоматизируйте — используйте специализированные платформы (ProsperOps, nOps) или собственные скрипты.
Управляйте как код — Terraform или другие IaC-инструменты для документирования и управления портфелем.
Распределяйте во времени — никаких единовременных закупок, создавайте лестницу продлений.
Rightsizing перед обязательствами — сначала оптимизируйте размеры, потом фиксируйте обязательства.

Что делать прямо сейчас:

Проведите аудит текущих обязательств и их утилизации с помощью скриптов из этого руководства.
Определите базовый уровень стабильного потребления за последние 90 дней.
Рассчитайте потенциальную экономию от оптимизации портфеля обязательств.
Разработайте многослойную стратегию, учитывающую специфику ваших нагрузок.
Внедрите ежемесячный пересмотр и автоматический мониторинг.
Рассмотрите внедрение специализированных платформ для масштабирования практики.

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