Оптимизация облачных расходов: перестаньте переплачивать за свой MVP

В прошлом квартале я провел аудит счета AWS одного стартапа и обнаружил, что они тратили $2800 в месяц на инфраструктуру, которая могла бы комфортно работать за $900. У них был t3.2xlarge, на котором работал Node.js API, загрузка процессора которого достигала пика в 12%. Три неиспользуемых Elastic IP простаивали, обходясь в $3.65 в месяц каждый. Развертывание RDS Multi-AZ для базы данных с 200 строками. NAT gateway, маршрутизирующий трафик, который мог бы проходить через VPC endpoint бесплатно. Ничто из этого не было злонамеренным или даже особенно небрежным — это было накопление решений типа «просто предоставьте что-нибудь, что работает», принятых во время спринта по выпуску продукта.

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

Самые большие ловушки расходов, которые я постоянно вижу

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

Избыточно выделенные вычислительные инстансы

Это самый большой источник потерь. Команды выбирают размер инстанса во время первоначальной настройки — обычно на основе статьи в блоге или из соображений «на всякий случай» — и никогда не пересматривают его. Я видел инстансы m5.xlarge, выполняющие cron-задания, которые работают 30 секунд каждый час. Инстанс простаивает 59,5 минут, сжигая $0.192 в час ($140 в месяц), по сути, ничего не делая.

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

# Check your EC2 instance CPU utilization over the past 2 weeks
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum

Если средняя загрузка вашего процессора ниже 20%, а пиковая — ниже 50%, вы почти наверняка избыточно выделены. Уменьшите размер инстанса на один или два, понаблюдайте в течение недели и скорректируйте.

Забытые тома и снимки EBS

Когда вы завершаете работу инстанса EC2, прикрепленные тома EBS не удаляются автоматически, если вы не настроили это при запуске. Это означает, что завершенные инстансы оставляют после себя осиротевшие тома, за которые продолжает взиматься плата. Я видел аккаунты с десятками неприкрепленных томов gp3, каждый из которых стоит $0.08/ГБ/месяц, что в сумме составляет сотни долларов за хранилище, которое никто не использует.

Снимки еще коварнее. Автоматические скрипты резервного копирования создают ежедневные снимки без политики жизненного цикла, поэтому они накапливаются бесконечно. Том объемом 500 ГБ, ежедневно снимаемый в течение года, генерирует 365 снимков, и хотя снимки EBS являются инкрементальными, затраты складываются в реальные деньги.

# Find all unattached EBS volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Find snapshots older than 90 days
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-12-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
  --output table

NAT Gateway: Тихий убийца бюджета

NAT gateways стоят $0.045 в час ($32.40 в месяц) просто за существование, плюс $0.045 за ГБ обработанных данных. Для стартапа, совершающего частые вызовы API к внешним сервисам из частных подсетей, только плата за обработку данных может превышать $100 в месяц. Я видел, как расходы на NAT gateway составляли 15-20% от общего счета AWS небольшого стартапа.

Решение зависит от того, какой трафик проходит через NAT:

• Трафик к сервисам AWS (S3, DynamoDB, SQS): Используйте VPC Gateway Endpoints (бесплатно для S3 и DynamoDB) или Interface Endpoints ($7.20 в месяц каждый, но все равно дешевле, чем NAT для высокообъемного трафика).
• Трафик в интернет от функций Lambda: Подумайте, действительно ли этим функциям нужно находиться в VPC. Многие функции Lambda помещаются в VPC «для безопасности», хотя они не обращаются к каким-либо ресурсам VPC.
• Низкообъемный исходящий трафик: Инстанс NAT на t4g.nano ($3.02 в месяц) обрабатывает умеренный трафик за долю стоимости NAT gateway.

Плата за передачу данных

AWS взимает $0.09/ГБ за данные, покидающие регион, а трафик между зонами доступности стоит $0.01/ГБ в каждом направлении. Эти расходы невидимы, пока не станут таковыми. Многословная микросервисная архитектура, распределенная по трем зонам доступности, с сервисами, вызывающими друг друга сотни раз в секунду, может генерировать удивительные счета за передачу данных.

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

Правильный подбор размера: Систематический подход

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

Шаг 1: Сбор данных об использовании

AWS Compute Optimizer бесплатен и предоставляет рекомендации по правильному подбору размера для EC2, EBS, Lambda и ECS. Включите его и дайте ему собрать данные как минимум за 14 дней, прежде чем действовать по его рекомендациям.

Для более детального анализа метрики CloudWatch являются вашим основным источником данных. Ключевые метрики для отслеживания:

• EC2: CPUUtilization, NetworkIn/Out, MemoryUtilization (требуется агент CloudWatch)
• RDS: CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS
• ElastiCache: CPUUtilization, CurrConnections, BytesUsedForCache

Шаг 2: Категоризация рабочих нагрузок

Не каждая рабочая нагрузка должна быть оптимизирована одинаково. Я делю их на три категории:

Постоянные рабочие нагрузки (серверы API, базы данных): Им требуется постоянная производительность. Оптимизируйте, найдя наименьший инстанс, который справляется с пиковой нагрузкой с запасом в 30%. Используйте Reserved Instances или Savings Plans для базовой нагрузки.

Переменные рабочие нагрузки (пакетная обработка, серверы сборки): Они должны использовать Auto Scaling Groups с соответствующими политиками масштабирования или Spot Instances для отказоустойчивых пакетных заданий.

Периодические рабочие нагрузки (cron-задания, запланированные отчеты): Они вообще не должны работать на выделенных инстансах. Перенесите их в Lambda, Fargate Spot или Step Functions.

Шаг 3: Действуйте постепенно

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

Reserved Instances против Savings Plans против Spot

Именно здесь происходит реальная экономия — 30-72% от цен по требованию — но механика обязательств достаточно запутана, что многие стартапы просто полностью избегают их.

Reserved Instances (RIs)

Вы обязуетесь использовать определенный тип инстанса в определенном регионе на 1 или 3 года. Взамен вы получаете скидку от 30-40% (без предоплаты, 1 год) до 60% (полная предоплата, 3 года). Подвох: если вам нужно изменить типы инстансов, Standard RIs негибкие. Convertible RIs предлагают большую гибкость при немного меньшей скидке (около 45% для 3-летней полной предоплаты).

Когда использовать RIs: Базы данных и другие рабочие нагрузки, где тип и размер инстанса действительно стабильны. RDS Reserved Instances почти всегда окупаются — базы данных редко меняют размер.

Savings Plans

Savings Plans — это современная альтернатива RIs для вычислений. Вы обязуетесь тратить определенную сумму в долларах на вычисления в час (например, $0.10/час) на 1 или 3 года. Обязательство автоматически применяется к использованию EC2, Fargate и Lambda, и оно гибко в отношении семейств инстансов, размеров, ОС и регионов.

Когда использовать Savings Plans: Почти всегда предпочтительнее, чем EC2 RIs для вычислительных рабочих нагрузок. Compute Savings Plans предлагают лучшее соотношение гибкости и скидки. Начните с обязательства, которое покрывает ваши минимальные базовые расходы.

# Example: Calculating Savings Plan commitment
# Current on-demand spend: $500/month on EC2
# Minimum baseline (never drops below): $350/month
# Recommended Savings Plan commitment: $350/month = ~$0.48/hour
# Expected savings: ~30% on the committed amount = ~$105/month
# Remaining $150/month stays on-demand for flexibility

Spot Instances

Spot Instances предлагают скидки 60-90%, но могут быть прерваны с уведомлением за 2 минуты. Они идеально подходят для:

• Агенты сборки CI/CD (используйте Spot Fleet с несколькими типами инстансов)
• Задания пакетной обработки, которые могут сохранять состояние и возобновляться
• Среды разработки и тестирования
• Нагрузочное тестирование

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

# Example: GitHub Actions self-hosted runner on Spot
# This saves roughly 70% compared to GitHub-hosted runners
# for compute-heavy builds
Resources:
  SpotFleet:
    Type: AWS::EC2::SpotFleet
    Properties:
      SpotFleetRequestConfigData:
        IamFleetRole: !GetAtt SpotFleetRole.Arn
        TargetCapacity: 2
        AllocationStrategy: lowestPrice
        LaunchSpecifications:
          - InstanceType: c5.xlarge
            SpotPrice: "0.06"
          - InstanceType: c5a.xlarge
            SpotPrice: "0.06"
          - InstanceType: c6i.xlarge
            SpotPrice: "0.06"

Модели бессерверных вычислений: Не всегда дешевле

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

Реальность ценообразования Lambda

Lambda взимает плату за запрос ($0.20 за миллион) и за ГБ-секунду вычислений ($0.0000166667). Для типичной конечной точки API, которая работает 200 мс с 256 МБ памяти:

• 1000 запросов/день: ~$0.03/месяц. Фактически бесплатно.
• 100 000 запросов/день: ~$3.00/месяц. Все еще очень дешево.
• 1 000 000 запросов/день: ~$30/месяц. Начинает сравниваться с небольшим инстансом EC2.
• 10 000 000 запросов/день: ~$300/месяц. t3.medium ($30/месяц) с правильным кэшированием легко справляется с этим.

Точка пересечения сильно зависит от продолжительности выполнения и выделения памяти, но для большинства рабочих нагрузок API Lambda перестает быть экономически эффективной где-то между 1-5 миллионами запросов в день. Ниже этого порога это почти всегда самый дешевый вариант.

Расходы на API Gateway накапливаются

Люди забывают, что функции Lambda за API Gateway влекут за собой дополнительные расходы. API Gateway стоит $3.50 за миллион запросов (REST API) или $1.00 за миллион (HTTP API). В масштабе стоимость API Gateway превышает стоимость Lambda. Если у вас достаточно трафика, чтобы беспокоиться о расходах на Lambda, вам следует использовать Application Load Balancer ($0.008 за LCU-час) вместо API Gateway.

Fargate: Золотая середина

AWS Fargate находится между Lambda и EC2 как по стоимости, так и по операционной сложности. Вы платите за vCPU и память посекундно, без управления инстансами. Для рабочих нагрузок, которые должны работать непрерывно, но вы не хотите управлять серверами, Fargate с поставщиками Spot-мощностей предлагает хороший баланс.

Задача Fargate с 0.25 vCPU и 0.5 ГБ памяти стоит около $9 в месяц при непрерывной работе. Это конкурентоспособно с t4g.nano, и вы получаете автоматическое размещение, проверки работоспособности и масштабирование без управления базовым хостом.

Мониторинг и оповещение о расходах

Вы не можете оптимизировать то, что не измеряете. Вот стек мониторинга, который я настраиваю для каждого проекта.

AWS Cost Explorer

Включите Cost Explorer и настройте ежемесячный бюджет с оповещениями на порогах 50%, 80% и 100%. Это абсолютный минимум. Представление Cost Explorer «Стоимость по сервисам» немедленно показывает, куда уходят деньги.

# Create a budget with email alerts
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Monthly-Total",
    "BudgetLimit": {"Amount": "500", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "team@startup.com"
    }]
  }]'

Infracost для инфраструктуры как кода

Если вы используете Terraform, Infracost интегрируется в ваш CI-конвейер и показывает оценки стоимости для каждого изменения инфраструктуры до его применения. Это преобразует процесс — осведомленность о затратах переходит от ежемесячного сюрприза к обсуждению в запросе на слияние.

# .github/workflows/infracost.yml
name: Infracost
on: pull_request
jobs: