Счёт за AWS — прямое следствие того, как вы строите систему. И он умеет неприятно удивлять: забыли выключить тестовую машину, выбрали инстанс «с запасом», погнали много трафика наружу — и в конце месяца цифра больше, чем ожидали. Хорошая новость: почти всё это управляемо, если понимать, за что именно AWS берёт деньги.

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

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

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

On-demand («по запросу») — платите по факту, посекундно или почасово, без обязательств. Включили машину — пошёл счётчик, выключили — остановился. Это самый дорогой, но и самый гибкий вариант. Аналогия: такси по счётчику — удобно, ничего не обещаешь заранее, но за километр платишь больше всего. Подходит для старта, когда нагрузка непредсказуема, и для коротких экспериментов.

Reserved Instances и Savings Plans — вы заранее обещаете AWS, что будете пользоваться вычислениями 1 или 3 года, а взамен получаете крупную скидку (до примерно 70%). Аналогия: годовой абонемент в спортзал — дешевле разовых посещений, если вы точно будете ходить. Разница между двумя вариантами в гибкости: Reserved Instances привязаны к конкретному типу машины, а Savings Plans — это обязательство тратить определённую сумму в час на вычисления, и скидка применяется автоматически независимо от того, какой именно инстанс вы запустили (а Compute Savings Plans распространяются ещё и на другие сервисы вычислений — Fargate, Lambda). Берут для стабильной базовой нагрузки, которая точно будет работать постоянно.

Spot — это свободные сейчас мощности AWS, которые он отдаёт с огромной скидкой (до примерно 90%). Подвох: AWS может забрать их обратно, предупредив всего за 2 минуты. Аналогия: «горящие» билеты — очень дёшево, но рейс могут отменить. Подходит для задач, которые не страшно прервать и потом перезапустить: пакетная обработка данных, разбор очередей, серверы без состояния, которые легко заменить. Важно: Spot не покрывается Savings Plans — это отдельный механизм скидки.

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

Right-sizing: платить за нужное, а не за запас

Right-sizing (буквально «подбор правильного размера») — это приведение мощности ресурсов к реальной потребности. Самая частая переплата в облаке — оплата того, чем не пользуются.

Типичные источники лишних денег:

  • Машины «с запасом». Взяли инстанс вдвое мощнее, чем реально нужно, «на всякий случай» — и платите за неиспользуемые ядра и память круглые сутки.
  • Забытые ресурсы. Подняли что-то для эксперимента, проект закрыли, а машина, диск или база остались работать и капать в счёт.
  • Тестовые среды по ночам. Среда для разработки крутится 24/7, хотя люди работают 8 часов в день — две трети времени она просто жжёт деньги.

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

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

Данные тоже стоят денег, и тоже по-разному в зависимости от того, как часто вы к ним обращаетесь и куда их гоняете.

Классы хранилища. В объектном хранилище S3 данные можно держать в разных «классах»: для частого доступа — дороже за хранение, но дёшево читать; для архива — наоборот, копейки за хранение, но достать долго и с доплатой. Логика проста: горячие данные (которые читают постоянно) держат в обычном классе, а холодные (логи годовой давности, бэкапы, которые вряд ли понадобятся) переносят в дешёвый архивный. Делать это вручную необязательно — настраиваются правила жизненного цикла (lifecycle rules), которые сами перемещают объекты в холодные классы по возрасту.

Так выглядит простое правило: всё, что старше 90 дней, уезжает в дешёвый архивный класс.

{
  "Rules": [
    {
      "ID": "archive-old-logs",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 90, "StorageClass": "GLACIER" }
      ]
    }
  ]
}

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

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

Нельзя оптимизировать то, чего не видишь. Базовая гигиена держит расходы прозрачными.

Теги. Тег — это пара «ключ-значение», которую вешают на ресурс (например, team: payments или env: prod). Когда ресурсы помечены тегами, счёт можно разложить по командам, сервисам или средам и понять, кто и за что платит. Без тегов счёт — это безликая куча строк. Тонкость для новичка: чтобы тег появился как ось разбивки в отчётах, его сначала нужно явно включить как Cost Allocation Tag в настройках биллинга — просто навесить тег недостаточно. После включения разбивка по умолчанию идёт с момента активации; а если ресурс был помечен тегом раньше, управляющий аккаунт может запросить применение задним числом (backfill) на срок до 12 месяцев.

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

Регулярный разбор. Cost Explorer — встроенный инструмент, который показывает расходы в динамике, по сервисам и тегам. Заглядывать туда стоит регулярно, а не только когда счёт напугал. Цель простая: чтобы каждая значимая строка была объяснима — видно, что и почему стоит денег, и где есть переплата.

Пример: посмотреть текущие траты по сервисам за июнь через AWS CLI. Параметр End в Cost Explorer эксклюзивен — чтобы попал весь июнь, ставим 2026-07-01.

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

А прогноз будущих трат — это отдельная команда get-cost-forecast: она предсказывает расходы на заданный вперёд период по вашей истории.

aws ce get-cost-forecast \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --metric UNBLENDED_COST \
  --granularity MONTHLY

А так задаётся бюджет с оповещением (формат JSON, который понимают и AWS CLI, и инструменты инфраструктуры-как-кода).

{
  "BudgetName": "monthly-prod",
  "BudgetLimit": { "Amount": "500", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

Где это применяется

Оптимизация затрат — повседневная инженерная задача, а не отдельная «бухгалтерия». Она встречается на каждом этапе: при выборе типа сервера, при настройке хранения данных, при проектировании сети, при разворачивании окружений в конвейере доставки. Управление стоимостью — один из столпов методики Well-Architected Framework, по которой AWS рекомендует проектировать системы.

Типичные ошибки новичков:

  • Всё на on-demand навсегда. Удобно на старте, но для постоянной нагрузки это переплата в разы — стоит перевести базу на savings plans, как только нагрузка стала предсказуемой.
  • Инстанс «с запасом». Берут размер побольше «чтобы хватило», а потом годами платят за простаивающую мощность. Лучше начать скромно и увеличить при необходимости.
  • Забытые ресурсы. Эксперимент закрыли, а диски, снапшоты и базы остались. Помогают теги и регулярный разбор в Cost Explorer.
  • Незаметный egress. Архитектура гоняет данные между регионами или наружу, и счёт растёт без видимой причины. Полезно понимать сетевые границы.

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