Хмарні рахунки зростають швидше, ніж бізнес — це норма, якщо не керувати витратами. Типова картина: 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 — це постійний процес.