Как снизить затраты на AWS: RI и Savings Plans на практике

Почему счёт за облако растёт при стабильной нагрузке

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

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

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

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

Эффект резервирования: что меняется в счёте и планировании

Резервирование снимает волатильность не со всего счёта, а с той части нагрузки, которая повторяется из месяца в месяц. В Amazon Web Services для этого есть Reserved Instances и Savings Plans — разные механики с одной логикой: обязательство на срок в обмен на ставку ниже оплаты по требованию. Эффект проверяется по четырём пунктам, и каждый виден в счёте без сложной аналитики.

• Покрытие базовой нагрузки. Берём минимум потребления за длинный период — именно его закрывает обязательство. Всё, что выше базовой линии, остаётся на оплате по требованию, поэтому резерв не превращается в балласт при спаде активности.
• Снижение стоимости часа на покрытом участке. Ставка часа падает относительно оплаты по требованию — на практике это диапазон 30–60%, и он проявляется на длинном окне, а не в одном месяце. Savings Plans дают ту же логику, но привязываются к объёму потребления, а не к конкретному семейству инстансов.
• Предсказуемость платежа. Фиксированная почасовая плата за обязательство переводит переменную статью в постоянную: бюджет на вычислительные ресурсы планируется от периода к периоду, а не от факта.
• Устойчивость к сезонным пикам. Обязательство не ограничивает масштабирование — пик сверх резерва закрывается оплатой по требованию, без пересмотра договорённостей. Спад, наоборот, не оставляет лишних обязательств, если базовую линию брать по нижней границе.
• Меньше ручных разборов счёта. Покрытая часть перестаёт быть набором меняющихся строк: расхождение плана и факта видно в одном месте, сверка занимает минуты вместо часов.

Критерий простой: если сходятся хотя бы три пункта из четырёх, покрытие выбрано верно. Пересматриваем его вместе с разбором счёта по мере изменения профиля нагрузки — обычно раз в квартал.

Reserved Instances или Savings Plans: что выбрать

Различие между двумя механиками — не в размере скидки, а в том, что именно вы фиксируете. Reserved Instances привязан к семейству экземпляров и региону, а гибкий план на вычислительные ресурсы покрывает суммарный объём вычислений в час независимо от семейства и региона.

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

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

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

Как мы внедряем резервирование: этапы инженерной работы

Резервирование окупается только там, где обязательства привязаны к реальному профилю потребления — взятые «на глаз» Reserved Instances дают переплату за неиспользуемые часы. Поэтому внедрение ведём как инженерный проект с фиксированными шагами и проверяемым результатом на каждом.

1. Аудит счетов и профиля нагрузки — выгружаем детализацию потребления за несколько месяцев и разбираем её по типам инстансов, регионам, зонам и времени суток. Отдельно отмечаем суточные пики и разовые нагрузки: под них резерв не берут.
2. Расчёт доли покрытия — считаем, какая часть нагрузки стабильна и какую долю закрывать обязательствами. Часть оставляем нерезервированной под рост и пики.
3. Схема резервов — подбираем комбинацию: жёсткие резервы под неизменные ресурсы, гибкие планы под то, что мигрирует между семействами и регионами.
4. Настройка и учёт — применяем резервы на уровне организации, разносим по проектам через теги и включаем оповещения об утилизации, чтобы команда видела простаивающие обязательства.
5. Проверка на модельных сценариях — прогоняем рост нагрузки, смену семейства инстансов, отказ зоны и сезонный спад. Где появляется переплата, правим схему до продакшена.
6. Передача документации — отдаём команде заказчика регламент: как резервы отражаются в счёте, когда продлевать, по каким метрикам следить за покрытием и что делать при смене архитектуры.

На выходе обязательства привязаны к реальному потреблению, а решения о продлении и пересмотре схемы принимаются по цифрам, а не по интуиции.

Политики покрытия резервами и отчётность по использованию

Резерв окупается только там, где совпадает с фактическим профилем нагрузки. Если покрытие уехало в сторону, часть резервов простаивает, а самая тяжёлая часть трафика снова тарифицируется по требованию.

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

• Схема покрытия — какие семейства инстансов, регионы и типы резервов закрывают какую долю базовой нагрузки, с разбивкой по сервисам и окружениям.
• Конфигурации резервов — перечень с параметрами: класс, платформа, срок, зона, вариант оплаты и обоснование выбора каждого набора.
• Правила пересмотра доли — целевое покрытие, допустимое отклонение и триггеры пересмотра: рост числа узлов, смена семейства, запуск нового сервиса.
• Отчёт об использовании — процент покрытия, доля неиспользованного резерва, динамика по неделям и расхождение с целевым значением.
• Регламент реакции — кто и в какой срок пересчитывает покрытие при изменении нагрузки, что считается штатным, а что требует пересогласования резервов.
• Ответственные и периодичность — кто ведёт отчёт, кто утверждает пересмотр доли и как часто проводится сверка с фактическим потреблением.

Документы держим в репозитории рядом с инфраструктурным кодом: новый инженер входит в тему по ним, а не по переписке. Формат и глубину подгоняем под то, кто будет вести покрытие — ваша команда или мы на поддержке.

Кейс: как изменился счёт после перехода на резервы

Клиент — сервис с выраженным суточным профилем: базовая нагрузка держится ровно, пики приходятся на короткие окна. Парк работал по модели «плати по факту» в Amazon Web Services: обязательств не было, но платёж повторял профиль трафика, а инженеры вручную гасили и поднимали узлы перед каждым пиком.

Что было и что изменили

Разобрали парк на два слоя. Под базовую часть со стабильным профилем взяли резервы — Reserved Instances на весь горизонт планирования, под нагрузку с плавающим потреблением — Savings Plans, остаток оставили «по факту» под пики. Обязательства считали по метрикам потребления за несколько месяцев с запасом на рост: перебрать — платить за простой, недобрать — терять скидку на самом дорогом слое.

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

Чем Reserved Instances отличаются от оплаты по факту потребления

Оплата по факту — почасовая тарификация запущенного ресурса: ставка зависит от региона, семейства и размера инстанса, операционной системы и модели тенантности. Reserved Instances в AWS — это предоплаченное обязательство на год или три: резервируется не конкретная машина, а профиль ресурса, и скидка к почасовой ставке тем выше, чем жёстче фиксация.

Зональный резерв привязан к зоне доступности и типу инстанса — уехала нагрузка в другую зону, и оплаченный час сгорает. Региональный мягче: он действует в пределах региона и даёт размерную гибкость внутри семейства, когда один крупный инстанс заменяется двумя средними без потери покрытия; конвертируемый допускает смену семейства и операционной системы.

Покрытие считается в нормализованных единицах: оплаченные часы сопоставляются с фактическим потреблением за тот же час. Смотреть нужно на две метрики — доля покрытия показывает, какая часть нагрузки закрыта резервом, утилизация — какая часть оплаченных часов реально израсходована. Утилизация ниже 90% означает, что предоплата частично ушла впустую.

Гибкость против цены разводят по слоям. Стандартный RI даёт максимальную скидку, но почти не допускает изменений; Savings Plans уступают в размере скидки, зато шире по покрываемым сервисам и не привязаны к семейству инстансов. Стабильное ядро выгоднее закрывать жёстким резервом, разнородные контуры — гибким планом.

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

Частые технические вопросы по резервированию мощностей

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

Как считается доля покрытия?

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

Куда уходит неиспользованный остаток?

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

Сколько занимает переход и нужна ли остановка сервисов?

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

Совместимо ли резервирование с автомасштабированием?

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

Обсудим задачу: разберём ваш профиль нагрузки

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

• Выгрузка счетов за 3–6 месяцев в CSV: разбивка по сервисам, регионам и типам инстансов, отдельными строками — резервы и планы экономии.
• Схема сервисов: что с чем обменивается данными, где хранится состояние, что масштабируется автоматически, а что живёт в одном экземпляре.
• График нагрузки: суточный и недельный профиль с пиками и провалами, сезонные всплески, фоновые задачи, которые можно сдвинуть по времени.
• Требования к доступности: допустимое окно простоя, нужна ли отказоустойчивость по зонам, какие сценарии деградации приемлемы.
• Ограничения по регионам: где должны находиться данные, какие регионы уже задействованы, есть ли требования к задержке отклика.
• Действующие обязательства: какие резервы и планы экономии активны, на какой срок и какую долю потребления покрывают.

С этим набором мы считаем, какое покрытие обязательствами даёт эффект без потери гибкости, и возвращаемся с планом: что менять сразу, а что — по мере истечения текущих сроков.