Реалізація FinOps-практик для управління хмарними витратами

Рахунок за хмарні ресурси зростає швидше, ніж бізнес. Нещодавно до нас звернулася компанія: за пів року рахунок AWS виріс з $20k до $80k. Аудит показав, що 35% — idle RDS та NAT Gateway. Ми впровадили FinOps: налаштували бюджети, автовимкнення dev-середовищ і купили Savings Plans. Через 8 тижнів рахунок знизився на 40%. FinOps — операційна модель управління витратами, що об'єднує інженерів, фінансистів та бізнес. Без такої практики компанії втрачають до 40% бюджету на хмару.

Як FinOps-практики керують хмарними витратами?

FinOps — це не просто набір інструментів, а культура спільної відповідальності. Ми впроваджуємо її з нуля або доопрацьовуємо існуючі процеси. Наш підхід — швидкі перемоги одразу (Rightsizing, видалення abandoned ресурсів) і довгострокова стратегія: commitment, автоматизація, культура. Результат — зниження рахунку на 20–40% без втрати продуктивності. Згідно з FinOps Foundation, зрілість практики ділиться на три рівні: Crawl, Walk, Run.

Як FinOps виявляє приховані втрати?

Три джерела втрат, які зустрічаються в 80% проєктів:

• Idle та underutilized ресурси. EC2-інстанси з CPU utilization 3–5% цілодобово. RDS з Multi-AZ у dev-середовищі. NAT Gateway в регіоні, де трафіку немає. Все це легко виявляє AWS Trusted Advisor або Cost Anomaly Detection, але без регулярного моніторингу вони залишаються непоміченими.
• Відсутність Savings Plans та Reserved Instances. On-demand pricing — максимальна ставка. Compute Savings Plans з 1-year commitment дають 20–40% знижки на EC2, Lambda та Fargate. Багато команд роками платять on-demand просто тому, що «не розібралися» або бояться зафіксуватися.
• Data transfer costs. Egress між регіонами, між AZ, через NAT Gateway — ці рядки в CUR (Cost and Usage Report) часто ігнорують, поки вони не починають займати 15–20% рахунку. Типовий випадок: мікросервіси в різних AZ ганяють трафік через NAT замість VPC Endpoint або PrivateLink.

Як ми впроваджуємо FinOps: три рівні зрілості

FinOps Foundation ділить зрілість на Crawl → Walk → Run. На практиці це виглядає так:

Crawl — видимість. Налаштування Cost and Usage Reports з hourly granularity, експорт в S3, Athena-таблиця поверх. Обов'язкові теги на всіх ресурсах (project, team, environment). Щотижневі cost review-зустрічі. На цьому рівні більшість компаній уже знаходять 15–25% потенційної економії, що в грошовому вираженні може становити $10 000–$50 000 на місяць при рахунку $50 000–$200 000.

Walk — оптимізація. Rightsizing інстансів за метриками CloudWatch (CPU/Memory за 30 днів). Перехід на Graviton3 там, де дозволяє стек. Купівля Savings Plans на базове навантаження, on-demand — тільки під піки. Автоматичне вимкнення non-prod середовищ за розкладом (EventBridge + Lambda або Instance Scheduler).

Run — автоматизація та передбачуваність. Бюджети з алертами в AWS Budgets. Cost Anomaly Detection з SNS-повідомленнями. FinOps-метрики в інженерних дашбордах — поруч з SLO. Chargeback/showback за командами через Cost Allocation Tags.

Чому впровадження FinOps вимагає культурних змін?

Навіть після впровадження базових практик зростання може продовжуватися через відсутність культури спільної відповідальності. Ми налаштовуємо процеси так, щоб кожна команда бачила свої витрати і могла на них впливати. Щотижневий 30-хвилинний cost review з представниками різних команд — мінімальний формат для підтримки культури. Метрика unit economics — вартість обробки однієї транзакції, одного користувача, одного запиту — показує ефективність оптимізації краще, ніж абсолютні цифри рахунку.

Як автоматизація знижує витрати?

Instance Scheduler

Перше, що впроваджуємо в dev/staging — автоматичне вимкнення невикористовуваних ресурсів:

---
# CloudFormation параметр для Instance Scheduler Periods: office-hours: begintime: "08:00" endtime: "20:00" weekdays: "mon-fri" timezone: "Europe/Moscow" 
---

Cost Anomaly Detection

Для автоматичного виявлення аномалій налаштовуємо через AWS CLI:

aws ce create-anomaly-monitor \
    --anomaly-monitor '{"MonitorName":"TeamCostMonitor","MonitorType":"DIMENSIONAL","MonitorDimension":"SERVICE"}' \
    --region us-east-1

aws ce create-anomaly-subscription \
    --anomaly-subscription '{
        "SubscriptionName": "DailyCostAlert",
        "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/..."],
        "Subscribers": [{"Address": "[email protected]", "Type": "EMAIL"}],
        "Threshold": 20,
        "Frequency": "DAILY"
    }'

Покрокова інструкція:

1. Створіть монітор аномалій за допомогою aws ce create-anomaly-monitor.
2. Налаштуйте підписку на сповіщення через aws ce create-anomaly-subscription.
3. Вкажіть поріг (Threshold) — наприклад, 20% відхилення від очікуваного.
4. Перевірте роботу, викликавши тестову аномалію або дочекавшись реальної.

Rightsizing

Дивимося на CloudWatch метрики за 30 днів: якщо CPUUtilization p95 нижче 20% — кандидат на downsize. Наприклад, для m5.2xlarge → m5.xlarge економія близько $70/місяць на інстанс. Помножте на 50 інстансів — виходить суттєва сума.

Savings Plans: як розрахувати commitment

Помилка — купувати Savings Plans на максимальне навантаження. Правильно — покривати тільки baseline, решту залишати on-demand. З Cost Explorer беремо hourly spend за останні 3 місяці, знаходимо мінімальне значення — це і є безпечний commitment. Наприклад, якщо мінімальний hourly spend $8, commitment = $8/hour на Compute Savings Plan. Понад це — on-demand або Spot для batch-завдань. Такий розрахунок дозволяє уникнути переплати за фіксацію.

Що входить у нашу роботу

Етапи та строки

Повний цикл від аудиту до працюючих процесів — 6–10 тижнів для компанії з 5–15 інженерами та одним хмарним акаунтом. Для multi-account структури з кількома командами — 3–4 місяці. Наш досвід: 10+ років у DevOps, 40+ проєктів з оптимізації хмарних витрат, сертифіковані інженери AWS. Замовте аудит FinOps — дізнайтеся, скільки можна заощадити. Зв'яжіться з нами для консультації.