Оптимизация стоимости: варианты покупки, egress, простой и видимость

Рычаг 1: варианты покупки compute — подгони обязательство под базу

У одной и той же EC2-ёмкости четыре цены, и разрыв между самой дешёвой и самой дорогой огромен. On-Demand — дефолт: максимум гибкости, без обязательств и самая высокая ставка за час. Ты платишь за каждый час работы инстанса, занят он или простаивает. Это верная цена для непредсказуемой или короткоживущей работы — и неверная для базы, работающей круглосуточно.

Savings Plans меняют гибкость на скидку: ты обязуешься тратить на compute постоянную сумму (в долларах в час) на один или три года, а взамен экономишь до ~72% против On-Demand. Стоит знать две формы. Compute Savings Plan — гибкая: его скидка (до ~66%) применяется автоматически независимо от семейства инстанса, размера, региона, ОС и по EC2, Fargate и Lambda, так что ты можешь переархитектурить под ним без потери ставки. EC2 Instance Savings Plan дешевле (до ~72%), но уже: ты обязуешься по конкретному семейству инстансов в выбранном регионе, и скидка следует только за сменой размера и ОС внутри этого семейства. Reserved Instances — более старый механизм, появившийся до Savings Plans; они связывают скидку с опциональным резервированием ёмкости и для чистой экономии в основном вытеснены Savings Plans.

На дальнем конце Spot Instances продают свободную ёмкость AWS со скидкой до ~90% против On-Demand — с одной оговоркой: AWS может забрать инстанс в любой момент, давая лишь двухминутное предупреждение об отзыве (через метаданные инстанса и событие EventBridge). Spot — подарок для прерываемой, stateless, отказоустойчивой работы — батч-джобов, CI-раннеров, обработки больших данных, всего, что умеет чекпойнтиться и возобновляться, — и ловушка для всего stateful, что не переживёт убийства на полпути.

Сеньорское правило — подгонять обязательство под форму спроса: покрой постоянную базу 24/7 через Savings Plan или RI, поглоти непредсказуемый всплеск сверху через On-Demand, а прерываемый батч гоняй на Spot. Цены зависят от региона и со временем меняются — всегда сверяй актуальные числа на странице цен EC2; проценты здесь — это опубликованные AWS максимумы «до», а не котировка.

Рычаг 2: data transfer и NAT — тихие строки счёта

Compute — это счёт, за которым следят все; data transfer — счёт, который их удивляет. Грубая ментальная модель: ingress из интернета обычно бесплатен, egress — нет, а трафик, пересекающий границу зоны доступности (AZ) или региона, метрируется, даже если он не покидает AWS. Микросервисная архитектура, постоянно перешёптывающаяся между сервисами в разных AZ, может накрутить cross-AZ-плату за трафик, затмевающую compute, который этот трафик и генерирует. Фикс архитектурный: держи болтливый трафик внутри одной AZ (соразмещай собеседников), ставь перед egress в интернет CloudFront, чтобы ориджин отдавал байты один раз, а CDN дальше отдавал их дёшево, и достигай сервисов AWS вроде S3 и DynamoDB через VPC-эндпоинты, а не маршрутизируя этот трафик наружу через шлюз.

Этот шлюз — вторая тихая строка. NAT gateway тарифицируется сразу двумя способами: плата за каждый час, что он провижинен, плюс плата за каждый гигабайт, который он обрабатывает, — обе зависят от региона (см. цены NAT gateway). Классический сюрприз — нагрузка в приватной подсети, чей единственный «внешний» трафик идёт в S3: каждый байт метрируется через NAT без причины. Собственная рекомендация AWS — размещать ресурсы в той же AZ, что и NAT gateway, чтобы не накладывать сверху cross-AZ-плату, и использовать VPC interface- или gateway-эндпоинты для трафика к сервисам AWS, чтобы он обходил NAT целиком.

# Быстро найди главные источники трат через Cost Explorer, сгруппировав по usage type
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[0].Groups[?Metrics.UnblendedCost.Amount>`100`]'
# Ищи *-DataTransfer-Out-Bytes, NatGateway-Bytes и *-DataTransfer-Regional-Bytes

Рычаг 3: простой и отходы — ты платишь за то, что забыл

Когда аудируешь счёт впервые, этот раздел обычно удивляет больше всего — потому что ничего не сломано, просто никто не смотрел. Большая доля типичного счёта — чистые отходы: ёмкость, которая провижинена, тарифицируется и ничего не делает. Обычные подозреваемые — неприсоединённые тома EBS, оставшиеся после терминации инстансов, старые снапшоты, которые никто не чистит, переразмеренные инстансы под пик, который не приходит, простаивающие RDS, оставленные «на всякий случай», забытые dev/test-окружения, работающие по ночам и выходным, и балансировщики, не подключённые ни к чему. Два инструмента бьют прямо по этому: Compute Optimizer анализирует утилизацию и рекомендует right-sizing (на размер вниз или к более дешёвому семейству), а простой планировщик, останавливающий непродакшен-инстансы вне рабочих часов, может срезать compute-счёт dev-аккаунта более чем вдвое — такие окружения простаивают ~128 из 168 часов в неделю.

Рычаг 4: видимость — нельзя оптимизировать то, что нельзя атрибутировать

Каждый рычаг выше невидим без измерения, и фундамент — теги распределения затрат (cost allocation tags). Разметка ресурсов по team, env и service позволяет резать счёт по тому, кто чем владеет, — но есть острая ловушка: пользовательский тег не появится в отчётах о затратах, пока ты не активируешь его в консоли Billing and Cost Management, и после применения, как отмечает AWS, новый тег-ключ может появляться в консоли Billing для активации до 24 часов, а после активации учитывается только в затратах с этого момента, не задним числом. Вокруг тегов — три инструмента: Cost Explorer для анализа и прогноза трат, AWS Budgets для срабатывания алертов (или даже автоматических действий) при пересечении порога и Cost Anomaly Detection для отлова всплеска в день его начала, а не первого числа.

{
  "BudgetName": "monthly-prod-ceiling",
  "BudgetType": "COST",
  "TimeUnit": "MONTHLY",
  "BudgetLimit": { "Amount": "5000", "Unit": "USD" },
  "CostFilters": { "TagKeyValue": ["user:env$prod"] },
  "NotificationsWithSubscribers": [
    {
      "Notification": { "NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80 },
      "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "platform-oncall@example.com" }]
    }
  ]
}