Облачные счета растут быстрее, чем бизнес, — это норма, если не управлять затратами. Типичная картина: dev-среды работают 24/7, инстансы right-sized «на всякий случай», неиспользуемые EBS-тома и снапшоты за несколько лет. Аудит инфраструктуры даёт 20–40% экономии без потери производительности. Cloud cost optimization — наша специализация: мы проводим аудит облачной инфраструктуры, right-sizing инстансов и резервирование инстансов (Reserved Instances, Savings Plans). За последние годы мы провели более 100 проектов, средняя экономия составила 32%, что для среднего бизнеса означает $2000–$5000 в месяц.
Основные драйверы перерасхода — отсутствие регулярного аудита и автоматизации. Инженеры создают ресурсы под текущую нагрузку, не удаляя временные, а dev-среды часто копируют продакшен, хотя нужны только 8 часов в день. Классы хранения не меняются, хотя данные не запрашиваются месяцами. Каждая из этих проблем даёт 5–15% перерасхода, в сумме — 30–50%. С помощью right-sizing, покупки Reserved Instances и удаления orphaned ресурсов можно быстро снизить счета.
Причины роста облачных счетов
Основная причина — отсутствие регулярного аудита и автоматизации. Инженеры создают ресурсы под текущую нагрузку, не удаляя временные. Dev-среды дублируют продакшен, хотя нужны только 8 часов в день. Классы хранения не меняются, хотя данные не запрашиваются месяцами. Каждая из этих проблем в отдельности даёт 5–15% перерасхода, а в сумме — 30–50%.
Выявление неиспользуемых ресурсов
Compute (EC2/GCE/VM)
Самая большая статья. Проблемы:
- Oversized инстансы (c5.2xlarge для сервиса под 200 RPS)
- Dev/staging работают ночью и в выходные
- Старые инстансы на предыдущих поколениях (r4 вместо r6i)
Storage
Незаметно копится:
- EBS-тома от удалённых инстансов (orphaned volumes)
- Снапшоты старше 90 дней (часто хранятся годами)
- S3 объекты без lifecycle policy
- Неоптимальный storage class (Standard вместо Infrequent Access для архивов)
Трансфер данных
Data transfer out стоит дорого. Особенно: cross-AZ трафик (EC2 ↔ RDS в разных AZ), egress из региона.
Idle и неиспользуемые ресурсы
Load balancers без трафика, NAT Gateways, Elastic IP без привязки.
Инструменты анализа
| Инструмент | Назначение | Бесплатно? |
|---|---|---|
| AWS Cost Explorer | Анализ расходов по сервисам, тегам, RI | Да |
| AWS Trusted Advisor / GCP Recommender | Конкретные рекомендации по right-sizing | Да |
| Infracost | Анализ стоимости Terraform-планов до применения | Да (с ограничениями) |
| CloudHealth / Spot.io / Apptio Cloudability | Enterprise-аналитика, showback/chargeback | Нет |
Быстрые победы (неделя 1-2)
- Удалить orphaned resources: EBS-тома без attachment, Elastic IPs без привязки, старые снапшоты.
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table - S3 Intelligent-Tiering: включить для больших buckets — AWS автоматически перемещает объекты между storage tiers.
- Выключать dev/staging ночью: Lambda + CloudWatch Events или Instance Scheduler.
- Удалить старые снапшоты: lifecycle policy для AMI и EBS snapshots.
Чек-лист быстрых побед
- Удалить orphaned EBS-тома
- Включить S3 Intelligent-Tiering
- Настроить автоматическое выключение dev-сред
- Удалить старые снапшоты
Rightsizing инстансов
Анализ CloudWatch метрик за 2–4 недели:
- CPU < 20% в P95 → уменьшить инстанс
- Memory < 30% → уменьшить
- Network: сравнить с теоретическим лимитом инстанса
import boto3 from datetime import datetime, timedelta cw = boto3.client('cloudwatch') def get_cpu_p95(instance_id: str, days: int = 14) -> float: response = cw.get_metric_statistics( Namespace='AWS/EC2', MetricName='CPUUtilization', Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}], StartTime=datetime.now() - timedelta(days=days), EndTime=datetime.now(), Period=3600, Statistics=['p95'] ) values = [dp['p95'] for dp in response['Datapoints']] return max(values) if values else 0 Как right-sizing снижает счета?
Rightsizing — это приведение размера инстансов в соответствие с фактической нагрузкой. Например, если инстанс c5.2xlarge (8 vCPU, 16 GB RAM) использует CPU на 10% в пике, его можно заменить на c5.large (2 vCPU, 4 GB RAM). Экономия — 75% стоимости. Для типового проекта с 20–30 инстансами это $1500–$3000 в месяц.
Когда стоит покупать Savings Plans?
После стабилизации baseline нагрузки:
- 1-year Compute Savings Plans: 20–30% скидка, гибкость (работает для EC2, Fargate, Lambda)
- 3-year Reserved Instances: 40–60% скидка для стабильных workloads
- Spot Instances: 70–90% скидка для прерываемых задач (batch, CI workers)
Подробнее о Savings Plans можно прочитать в AWS Savings Plans документации.
Оптимизация трафика
Cross-AZ трафик: RDS и EC2 должны быть в одном AZ (для non-HA инстансов). Или используйте RDS Proxy для снижения числа соединений и их правильного размещения. S3 VPC Gateway Endpoint: трафик S3 → EC2 через VPC endpoint не тарифицируется как egress.
Объём работ
- Аудит текущей облачной инфраструктуры с детальным отчётом
- Выявление избыточных и неиспользуемых ресурсов
- Подготовка плана right-sizing и покупки RI/Savings Plans
- Настройка автоматического выключения dev-сред
- Внедрение S3 lifecycle policy и Intelligent-Tiering
- Мониторинг и регулярные отчёты для контроля затрат
- Передача знаний команде заказчика, документация
Результаты типичного аудита
| Категория | Экономия |
|---|---|
| Rightsizing инстансов | 15–25% |
| Reserved/Savings Plans | 20–40% от compute |
| Dev/staging scheduling | 10–20% |
| S3 lifecycle + storage class | 5–15% |
| Orphaned resources | 3–8% |
Сроки проведения оптимизации
- Аудит и анализ текущих расходов — 2–3 дня
- Быстрые победы (orphaned, scheduling) — 2–3 дня
- Rightsizing план + реализация — 3–5 дней
- Reserved/Savings Plans покупка — 1 день (требует 1–2 недели наблюдения перед покупкой)
Закажите аудит облачных расходов — мы найдём точки роста и предложим план экономии. Свяжитесь с нами, чтобы получить консультацию и примеры реализованных проектов. Таким образом, управление облачными затратами и оптимизация EC2 — это постоянный процесс.