Проблема рахунку AWS
Кожна компанія, що працює на AWS, має однаковий досвід. Перші кілька місяців витрати керовані. Потім зростає впровадження, команди створюють ресурси, і через дванадцять місяців хтось питає, чому рахунок потроївся. Відповідь майже завжди однакова: ніхто не звертав уваги.
Управління витратами на хмару — це не про скнарість. Це про усвідомлені витрати. У DevOpsVibe ми регулярно допомагаємо клієнтам зменшувати витрати на AWS на 30-50% без шкоди для продуктивності чи надійності. Ось стратегії, які стабільно дають результати.
Почніть з видимості: стратегія тегування
Неможливо оптимізувати те, що не можна виміряти. Послідовна стратегія тегування — фундамент кожної FinOps-практики:
# Enforce these tags on every resource
Required Tags:
- Environment: dev | staging | production
- Team: platform | backend | data | ml
- Service: api-gateway | user-service | analytics
- CostCenter: CC-1001 | CC-1002
- ManagedBy: terraform | manual | cdk
Забезпечте тегування за допомогою AWS Organization SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireTags",
"Effect": "Deny",
"Action": [
"ec2:RunInstances",
"rds:CreateDBInstance",
"elasticloadbalancing:CreateLoadBalancer"
],
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/Environment": "true",
"aws:RequestTag/Team": "true",
"aws:RequestTag/Service": "true"
}
}
}
]
}
Потім налаштуйте AWS Cost Explorer з групуванням за тегами. За тиждень ви точно знатимете, яка команда та сервіс відповідають за кожен долар.
Rightsizing: найбільша швидка перемога
За нашим досвідом, 40-60% EC2-інстансів мають надмірний розмір. Команди виділяють ресурси для пікового навантаження і ніколи не переглядають це рішення.
Як виявити завеликі інстанси
Використовуйте AWS Compute Optimizer або запитуйте CloudWatch напряму:
# Find instances with average CPU below 20% over 14 days
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc123def456 \
--start-time $(date -d '14 days ago' --iso-8601) \
--end-time $(date --iso-8601) \
--period 3600 \
--statistics Average \
--query 'Datapoints[?Average<`20.0`]'
До і після
Реальний приклад з клієнтського проєкту:
| Ресурс | До | Після | Місячна економія |
|---|---|---|---|
| API-сервери (12x) | m5.2xlarge | m6i.xlarge | $2,880 |
| Worker-вузли (8x) | c5.4xlarge | c6i.2xlarge | $3,520 |
| RDS Primary | db.r5.4xlarge | db.r6g.2xlarge | $1,840 |
| Redis-кластер | cache.r5.2xlarge | cache.r7g.xlarge | $960 |
| Всього | $9,200/міс |
Ключові спостереження:
- Перехід на інстанси поточного покоління (m6i, c6i, r6g) дає кращу продуктивність за нижчою ціною завдяки покращеному співвідношенню ціна/продуктивність.
- Інстанси на базі Graviton (суфікс "g") зазвичай на 20-30% дешевші з рівною або кращою продуктивністю для більшості навантажень.
- Rightsizing — це не одноразова подія. Вбудуйте його у щоквартальний процес перегляду.
Reserved Instances та Savings Plans
Коли ваш базовий рівень оптимізовано за розміром, зобов'яжіться щодо ємності для передбачуваних навантажень:
Savings Plans проти Reserved Instances
| Функція | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances |
|---|---|---|---|
| Гнучкість | Будь-яке сімейство, регіон, ОС | Конкретне сімейство, будь-який розмір | Конкретний тип і AZ |
| Знижка | До 66% | До 72% | До 72% |
| Найкраще для | Змінні навантаження | Стабільні сімейства | Високопередбачувані навантаження |
Наша рекомендація: починайте з Compute Savings Plans через їхню гнучкість. Вони автоматично застосовуються до використання EC2, Fargate та Lambda у будь-якому регіоні чи сімействі інстансів.
# Check current coverage and recommendations
aws ce get-savings-plans-coverage \
--time-period Start=$(date -d '30 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
--granularity MONTHLY
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS
Практичний підхід до покриття зобов'язаннями:
- 70-80% стабільного базового рівня: 1-річні no-upfront Savings Plans
- 10-15% передбачуваних піків: 1-річні partial-upfront Reserved Instances
- Решта 10-20%: On-demand та Spot для пікової ємності
Spot-інстанси для некритичних навантажень
Spot-інстанси дають до 90% економії. Вони добре працюють для:
- CI/CD build runners
- Batch-завдання обробки
- Середовища розробки та тестування
- Stateless worker-вузли в Kubernetes
Налаштуйте mixed-instance ASG для стійкості:
{
"MixedInstancesPolicy": {
"InstancesDistribution": {
"OnDemandBaseCapacity": 2,
"OnDemandPercentageAboveBaseCapacity": 20,
"SpotAllocationStrategy": "capacity-optimized"
},
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateId": "lt-0abc123",
"Version": "$Latest"
},
"Overrides": [
{ "InstanceType": "m6i.xlarge" },
{ "InstanceType": "m5.xlarge" },
{ "InstanceType": "m5a.xlarge" },
{ "InstanceType": "m6a.xlarge" }
]
}
}
}
Це залишає 2 on-demand інстанси як базу, заповнює 20% додаткової ємності on-demand і використовує Spot для решти 80%. Перерахування кількох типів інстансів максимізує доступність Spot.
Оптимізація витрат на сховище
Витрати на S3 та EBS накопичуються тихо. Вирішуйте їх за допомогою lifecycle-політик та tiering:
S3 Intelligent Tiering
Для бакетів, де патерни доступу непередбачувані, увімкніть Intelligent-Tiering:
aws s3api put-bucket-intelligent-tiering-configuration \
--bucket my-data-bucket \
--id entire-bucket \
--intelligent-tiering-configuration '{
"Id": "entire-bucket",
"Status": "Enabled",
"Tierings": [
{ "AccessTier": "ARCHIVE_ACCESS", "Days": 90 },
{ "AccessTier": "DEEP_ARCHIVE_ACCESS", "Days": 180 }
]
}'
S3 Lifecycle Rules
Для бакетів з відомими патернами доступу:
{
"Rules": [
{
"ID": "archive-old-logs",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER" },
{ "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
],
"Expiration": { "Days": 730 }
}
]
}
Очищення EBS Volumes
Невід'єднані EBS-томи — це чисті марнотратства. Знайдіть і очистіть їх:
# Find unattached volumes
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
--output table
# Also check for old snapshots
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[?StartTime<`2025-06-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
--output table
Автоматизуйте це за допомогою щотижневої Lambda-функції або використовуйте AWS Trusted Advisor.
Впровадження FinOps-практики
Інструменти й тактики мають значення, але стійка оптимізація витрат вимагає організаційних змін:
Структура FinOps-команди
- FinOps Lead -- володіє практикою, ставить цілі, звітує керівництву
- Engineering Champions -- по одному на команду, відповідають за усвідомлення витрат своєю командою
- Finance Partner -- перекладає технічну економію в бізнес-метрики
Місячний FinOps-цикл
- Тиждень 1: Звіт. Згенеруйте звіти про витрати за командами, сервісами та середовищами. Порівняйте з бюджетом і попереднім місяцем.
- Тиждень 2: Аналіз. Визначте топ-5 аномалій витрат і можливостей оптимізації.
- Тиждень 3: Оптимізація. Впровадьте rightsizing, оновіть резервування, очистіть невикористані ресурси.
- Тиждень 4: Перегляд. Презентуйте результати стейкхолдерам. Святкуйте перемоги.
Виявлення аномалій витрат
Налаштуйте AWS Cost Anomaly Detection, щоб виловлювати неочікувані сплески, перш ніж вони стануть дорогими:
aws ce create-anomaly-monitor \
--anomaly-monitor '{
"MonitorName": "service-monitor",
"MonitorType": "DIMENSIONAL",
"MonitorDimension": "SERVICE"
}'
aws ce create-anomaly-subscription \
--anomaly-subscription '{
"SubscriptionName": "cost-alerts",
"MonitorArnList": ["arn:aws:ce::123456789:anomalymonitor/abc123"],
"Subscribers": [
{ "Address": "[email protected]", "Type": "EMAIL" },
{ "Address": "arn:aws:sns:us-east-1:123456789:cost-alerts", "Type": "SNS" }
],
"Threshold": 100,
"Frequency": "DAILY"
}'
Чеклист швидких перемог
Якщо ви хочете почати економити цього тижня, ось дії з найбільшим впливом:
- Видаліть невід'єднані EBS-томи та старі snapshots
- Зупиняйте або термінуйте непродакшн інстанси поза робочими годинами
- Увімкніть S3 Intelligent-Tiering на великих бакетах
- Видаліть невикористані Elastic IP (вони коштують грошей, коли не приєднані)
- Перегляньте і видаліть старі AMI та їхні snapshots
- Перейдіть з NAT Gateways на NAT-інстанси для dev-середовищ
- Увімкніть gp3 томи замість gp2 (на 20% дешевше, краща продуктивність)
- Перегляньте витрати на передачу даних -- використовуйте VPC endpoints для S3 і DynamoDB
Цифри, які мають значення
Відстежуйте ці метрики щомісяця:
- Unit cost -- вартість на транзакцію, користувача чи запит (а не лише загальні витрати)
- Coverage ratio -- відсоток compute, покритий Savings Plans або RI
- Waste ratio -- неактивні ресурси як відсоток загальних витрат
- Cost per environment -- співвідношення продакшн / непродакшн (цільте 70/30 або краще)
Висновок
Оптимізація витрат AWS — це не проєкт з кінцевою датою. Це постійна практика, що вимагає видимості, відповідальності та регулярної уваги. Стратегії з цього посібника -- тегування, rightsizing, знижки за зобов'язаннями, Spot-інстанси, оптимізація сховища та організаційні FinOps-практики -- працюють разом, створюючи культуру, де ефективність витрат є функцією, а не запізнілою думкою.
У DevOpsVibe ми проводимо комплексні аудити витрат AWS і впроваджуємо FinOps-практики, що приносять вимірювану економію. Наші клієнти зазвичай бачать скорочення витрат на 30-50% протягом першого кварталу. Якщо ваш рахунок AWS зростає швидше за бізнес, зверніться до нас, і ми допоможемо взяти його під контроль.
awsfinopscloudcost-optimizationinfrastructuregovernance