Оптимизация затрат в AWS: с чего начать

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения как защита от счёта

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

Четыре ограничителя, которые ставят заранее:

• Максимум в группе масштабирования. Это не только про отказоустойчивость, но и про деньги: неверная метрика или всплеск ошибок приведёт к тому, что группа поднимет столько копий, сколько разрешено. Максимум ставят по расчёту «сколько нам реально может понадобиться», а не «побольше, чтобы не мешало».
• Ограничение одновременности у функций. У функции задают резервированную одновременность (reserved concurrency) — это одновременно и защита базы от сотен соединений, и потолок расходов: функция, вызванная в цикле из-за ошибки, не разгонится до тысячи экземпляров.
• Максимальный размер и класс у баз и кэшей. Автомасштабирование хранилища у управляемой базы удобно и не имеет обратного хода: диск увеличивается, а уменьшить его нельзя. Поэтому предел роста задают явно.
• Квоты сервиса как страховка. Квоты аккаунта (о них в статье про масштабирование) работают и как ограничитель расходов: не поднятая заранее квота не даст случайно запустить двести машин.

И отдельно — бюджет с оповещением (о нём ниже) как последний рубеж: он не остановит расходы, но сообщит о них в тот же день, а не в конце месяца.

Хранилище: классы и сроки

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

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

Прежде чем писать такое правило, посмотрите на две вещи, на которых спотыкаются при первом знакомстве. Первая — минимальный срок тарификации: у архивного класса Glacier Flexible Retrieval это 90 дней, у Deep Archive — 180. Удалили объект раньше — всё равно заплатите за весь срок. Вторая — за извлечение из архива берут отдельные деньги. Поэтому для россыпи мелких короткоживущих объектов такое правило счёт не уменьшает, а увеличивает; архив хорош для крупного и по-настоящему холодного.

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

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

Исходящий трафик: за что берут деньги

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

И самая частая невидимая строка: преобразование адресов для выхода в интернет (NAT Gateway). Она появляется именно у тех, кто всё сделал правильно и поставил приложение в закрытые подсети. Тарифицируется дважды: почасово за сам шлюз (около 32 долларов в месяц за штуку, а их ставят по одному на зону доступности — то есть в схеме на три зоны это около сотни в месяц) и за каждый обработанный гигабайт (порядка 4,5 цента). Второе и есть неожиданность: через шлюз идёт весь исходящий трафик приложения, включая обращения к сервисам самого AWS.

Типичная картина в счёте: сервис выгружает данные из хранилища объектов, обращается к хранилищу секретов и отправляет метрики — всё это «внутри AWS», но физически проходит через шлюз, и терабайт такого трафика стоит около 45 долларов сверх стоимости самих сервисов.

Что с этим делают, в порядке отдачи:

1. Точка доступа для хранилища объектов и DynamoDB. Бесплатная (gateway endpoint), настраивается строкой в таблице маршрутов — и трафик к этим двум сервисам перестаёт идти через шлюз вовсе. Это первое, что включают, и обычно самая крупная экономия.
2. Точки доступа для остальных сервисов (interface endpoint) — платные, порядка 7–10 долларов в месяц за каждую в каждой зоне плюс плата за гигабайт. Считать надо: для сервиса, к которому идёт большой поток (хранилище секретов, очереди, реестр образов), точка окупается; для редких обращений — нет.
3. Меньше шлюзов. Три шлюза ради отказоустойчивости — правильно для боевого контура; для стенда достаточно одного, а иногда шлюз не нужен вовсе (если из закрытой подсети никуда не надо).
4. Сеть доставки контента перед хранилищем для отдачи файлов пользователям: у неё трафик наружу дешевле, чем напрямую из хранилища, а ещё она кэширует.

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

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

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

Теги. Просто навесить тег недостаточно: пока его не включили как Cost Allocation Tag в настройках биллинга, в отчётах о расходах он не появится. Сам тег — пара «ключ-значение» на ресурсе (например, team: payments или env: prod); когда ресурсы помечены и теги включены, счёт раскладывается по командам, сервисам или средам, и видно, кто и за что платит. Без тегов счёт — безликая куча строк. После включения разбивка по умолчанию идёт с момента активации; а если ресурс был помечен тегом раньше, управляющий аккаунт может запросить применение задним числом (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=2027-01-01,End=2027-02-01 \
  --metric UNBLENDED_COST \
  --granularity MONTHLY

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

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

Только сам по себе бюджет молчит: он считает деньги, но никого не оповещает. Пороги и адресатов задают отдельным блоком, который передают в create-budget параметром --notifications-with-subscribers.

[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "ThresholdType": "PERCENTAGE",
      "Threshold": 80
    },
    "Subscribers": [
      { "SubscriptionType": "EMAIL", "Address": "team@example.com" }
    ]
  }
]

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

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

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

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

Глубже: обязательство это риск, а не только скидкарасширенное

Скидка в 40–70 % выглядит бесплатным обедом, и про обратную сторону узнают через год. Обязательство означает, что вы платите заявленную сумму в час независимо от того, пользуетесь вы ей или нет.

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

Что с этим делают.

Покрывают не всё. Разумная доля обязательства — 60–80 % от стабильного минимума потребления, а не 100 % текущего. Остаток держат на оплате по факту: он дороже за единицу, зато не привязывает.

Берут гибкий вид. Обязательство по сумме расходов на вычисления (Compute Savings Plans) распространяется и на машины, и на контейнеры, и на функции, и на любой регион — то есть переезд между ними его не обнуляет. Скидка меньше, чем у привязанного к семейству машин, зато риск заметно ниже.

Смотрят на срок. Год вместо трёх: скидка меньше, но горизонт предсказуемости у большинства команд как раз годовой. Трёхлетнее обязательство разумно для того, что точно не изменится (базовая инфраструктура, а не конкретный сервис).

Мониторят покрытие и использование. В отчётах по затратам есть две метрики: покрытие (какая доля потребления попала под скидку) и использование (какая доля обязательства реально израсходована). Первая около 70–80 % и вторая около 100 % — здоровая картина. Использование ниже 90 % означает, что вы платите за воздух, и это повод разобраться.

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

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

Глубже: Graviton: самая дешёвая правка счётарасширенное

Отдельно стоит назвать изменение, которое даёт 10–20 % экономии почти без усилий: процессоры Graviton — собственная архитектура AWS (ARM). Машина того же класса на Graviton стоит примерно на пятую часть дешевле, а по производительности на типичной серверной нагрузке не уступает, часто и выигрывает.

Почему это «почти бесплатно» для приложений на виртуальной машине языка (Java, .NET, Node.js, Python, Go): код не компилируется под конкретный процессор, а среда исполнения под ARM существует давно и стабильна. То есть переезд — это смена типа машины и пересборка образа контейнера под другую архитектуру, без правок кода.

Что проверить перед переездом:

• Образ должен быть собран под ARM (или под обе архитектуры сразу) — про это статья про реестры и конвейер;
• Нативные библиотеки. Всё, что содержит скомпилированный код (драйверы, ускорители шифрования, обработка изображений), должно иметь сборку под ARM. Это и есть единственное реальное препятствие, и проверяется оно прогоном тестов;
• Сторонние агенты (сбор метрик, безопасность) — у большинства версии под ARM есть, но проверить стоит до переезда.

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

Глубже: бесплатный уровень и как он кончаетсярасширенное

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

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

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

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

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

Глубже: порядки цен: во что это обходитсярасширенное

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

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

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

Глубже: класс, который выбирает самрасширенное

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

Как он работает: объект лежит в быстром уровне, и если к нему не обращались 30 дней, класс сам переводит его в более дешёвый уровень; обратился кто-то — объект возвращается наверх, и за это не берут плату за извлечение. Плата — небольшой сбор за отслеживание каждого объекта в месяц.

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

Когда не стоит: очень много очень мелких объектов (сбор за отслеживание на объект начинает перевешивать экономию — ориентир: объекты меньше 128 КБ в более дешёвые уровни не переводятся вовсе) и когда профиль доступа вам точно известен (тогда прямое правило перекладывания дешевле).

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

Коротко

• Одну и ту же мощность продают по-разному: on-demand по факту, обязательство на год или три со скидкой до 70 %, spot из свободных мощностей с отзывом за две минуты; базу держат на обязательстве, пики на on-demand, фоновое на spot.
• Обязательство это плата за час независимо от использования: покрывают 60–80 % стабильного минимума, берут гибкий вид по сумме расходов, срок год, смотрят покрытие и использование и не покупают в первый месяц.
• Graviton даёт 10–20 % почти даром для языков с виртуальной машиной: проверить образ под ARM, нативные библиотеки и агенты, начать со стенда.
• Переплачивают за машины с запасом, забытые ресурсы, публичные адреса IPv4 и стенды по ночам; лечат подбором размера, расписанием выключения и удалением брошенного.
• Потолки ставят заранее: максимум группы масштабирования, одновременность функций, предел роста диска базы, квоты аккаунта; бюджет с оповещением не остановит расход, но сообщит в тот же день.
• Бесплатный уровень неоднороден: двенадцать месяцев с регистрации, постоянно бесплатные лимиты и пробные периоды; бюджет на 10 долларов в первый день показывает любой выход за него.
• Классы хранения выбирают по частоте доступа с оглядкой на минимальный срок тарификации; самовыбирающий класс берут для объектов от пользователей, правила по возрасту для того, чей жизненный цикл известен.
• Трафик наружу дороже хранения, а NAT-шлюз считает часы и гигабайты: бесплатная точка доступа для S3 и DynamoDB, платные для остальных сервисов по расчёту, меньше шлюзов на стенде, CDN перед хранилищем.
• Теги включают как Cost Allocation Tag, бюджеты оповещают, Cost Explorer смотрят регулярно, чтобы каждая значимая строка счёта имела хозяина.

Что почитать дальше

• Основы AWS — что тихо капает в счёт с первой недели.
• Вычисления в AWS — за какие серверы и как идёт счёт.
• Сеть в AWS — сетевые границы, за которыми начинается платный трафик.
• Деньги в облаке — модель оплаты и ловушки, общие для всех провайдеров.