Счёт за AWS — прямое следствие архитектурных решений, и он умеет неприятно удивлять. Оптимизация затрат — это не разовая чистка перед концом квартала, а понимание моделей оплаты и встроенный в проектирование выбор. Для backend-разработчика это не «бухгалтерия»: то, как ты разворачиваешь сервис и хранишь данные, напрямую определяет цену.

Модели оплаты вычислений

Одну и ту же вычислительную мощность AWS продаёт по разной цене в зависимости от обязательств:

  • On-demand — плати по факту, без обязательств. Дороже всего, но гибко. Для непредсказуемой нагрузки и старта.
  • Reserved Instances / Savings Plans — обязательство на 1–3 года в обмен на крупную скидку (до ~70%). Для стабильной базовой нагрузки, которая точно будет. Savings Plans гибче (обязательство на сумму в час, не на конкретный тип).
  • Spot — свободные мощности с огромной скидкой (до ~90%), но AWS может их забрать с коротким предупреждением. Для прерываемых задач: батч, обработка очередей, stateless-воркеры.

Типовая стратегия: базовая нагрузка — на reserved/savings plans, пики — on-demand, прерываемое — spot.

Right-sizing

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

Хранилище и трафик

Данные тоже стоят по-разному:

  • Классы хранилища — частый доступ дороже, архив дешевле; перемещение редко используемых данных в холодные классы (по правилам жизненного цикла) экономит на объёме.
  • Egress-трафик — данные из AWS наружу платны, и на больших объёмах это заметная статья. Сюда же — трафик между зонами/регионами. Архитектура, гоняющая данные туда-обратно через границы, дорожает незаметно.

Контроль расходов

Нельзя оптимизировать невидимое. Базовая гигиена: теги на ресурсы (атрибуция затрат по командам/сервисам), бюджеты с оповещениями (узнать о всплеске сразу, а не в счёте), регулярный разбор через Cost Explorer. Цель — чтобы каждая значимая строка счёта была объяснима: видно, что и почему стоит, и где переплата.

Где это в UCP

Оптимизация затрат — инженерное решение, встроенное в архитектуру: модель оплаты под характер нагрузки (reserved/spot/on-demand), right-sizing вместо запаса «на всякий случай», контроль egress и хранилища, видимость через теги и бюджеты. Это та же дисциплина «не платить сложностью и ресурсами авансом», что уровни зрелости в коде. Cost optimization — один из столпов Well-Architected; для backend-разработчика осознанность по затратам — часть ответственности за сервис, а не чужая забота.