FinOps на практике. Как перестать сжигать деньги в облаке
Вы не поверите, сколько денег прямо сейчас утекает в ваш облачный счёт за ресурсы, которыми никто не пользуется.
Я поднимаю инфраструктуру стартапа. До этого более 18 лет по энтерпрайз площадкам по всему Казахстану, где каждый тенге на счету. И вот парадокс: в корпорации с её бюрократией финансовый контроль жёсткий, а в облаке полная вольница. Разработчик пишет terraform, деплоит, забывает. Billing приходит в конце месяца. Все удивляются.
Это не проблема денег. Это проблема видимости и культуры.

Почему деньги утекают незаметно
Вот реальный кейс. Adobe. Один Pull Request с временным масштабированием для нагрузочного тестирования обошёлся в $12,000 за три недели. Не взлом, не баг в коде. Просто PR завис, никто не смотрел на расходы, счётчик крутился.
По данным SquareOps за 2026 год, организации тратят впустую 20–35% облачного бюджета. Средняя утилизация CPU составляет 15–30%. То есть вы платите за сервер, который три четверти времени просто стоит и дышит.
Откуда берётся этот мусор:
- Сироты, то есть снапшоты, диски, балансировщики, которые давно не нужны, но никто не удалил
- Dev-окружения 24/7, когда кластер крутится ночью и в выходные, пока разработчики спят
- Завышенные resource requests в Kubernetes, где просят 4 CPU, а используют 0.3
- Плохой bin packing, когда поды не упаковываются и ноды полупустые
Дашборды в этом не помогают. Дашборд показывает что уже случилось. $12K уже потрачены, PR уже смержен (или нет), но вы об этом узнаёте через три недели когда приходит счёт.
Нужен другой подход.
6 паттернов, которые реально работают
1. Tagging как основа всего, без исключений
Если ресурс не размечен, он невидим. Невидимые ресурсы никто не оптимизирует.
Минимальный набор тегов на каждый ресурс:
team: backend
service: payments-api
environment: production
owner: ilyas@company.com
По моему опыту, самая частая проблема в том, что размечать начали сегодня, а половина ресурсов создана год назад без тегов. Не пытайтесь сделать всё сразу. Работает итеративный подход:
- Поднял дашборд по стоимости
- Нашёл неразмеченные ресурсы
- Разметил
- Повторил на следующей неделе
Нудно, но это фундамент. Без тегов вы не знаете, чья команда сжигает деньги.
2. Cost-as-Code, то есть стоимость в code review
Вернёмся к Adobe. Проблема не в том, что кто-то был жадным или тупым. Проблема в том, что стоимость изменений не была видна в момент принятия решения. Написал terraform, открыл PR, reviewer смотрит на логику кода, и никто не смотрит на то, что это обойдётся в $4,000 в месяц.
Решение Infracost. Интегрируется в CI/CD, показывает дельту стоимости прямо в комментарии к PR.
Выглядит примерно так:
💰 Estimated monthly cost change: +$3,847/mo
+ aws_instance.load_test r5.4xlarge +$876/mo
+ aws_rds.replica db.r5.2xl +$2,971/mo
Теперь reviewer видит это до того, как смёржил. Это не блокировка, а сигнал. Легитимные дорогие решения всё равно пройдут, просто осознанно.
На мой взгляд, это самое высокое соотношение усилий к результату из всего что я внедрял. Настраивается за день, работает постоянно.
3. Автоматическое удаление мусора
Вручную это не работает. Люди забывают, стесняются удалять “чужое”, откладывают.
cloud-nuke (от Gruntwork) это инструмент для автоматической очистки AWS-ресурсов по возрасту и тегам. Запускаете по расписанию в dev/staging окружениях, он удаляет всё старше N дней если нет тега do-not-delete: true.
Простейший сценарий для начала:
# Удалить все ресурсы в dev старше 7 дней
cloud-nuke aws --region eu-west-1 \
--environment dev \
--older-than 168h
По моему опыту в стартапе, dev-окружения это главный источник мусора. Кто-то тестировал, создал RDS, Redis, три EC2, забыл. Всё это крутится.
Отдельно про снапшоты и диски. Зайдите прямо сейчас в AWS Console → EC2 → Snapshots. Отсортируйте по дате создания. Готов поспорить, найдёте снапшоты двухлетней давности от инстансов которых уже нет.
4. Rightsizing, или платить за то, что реально используете
CPU утилизация 15–30% в среднем по рынку. Это значит, что большинство инстансов можно уменьшить вдвое без заметного эффекта на производительность.
Как найти кандидатов:
- AWS Compute Optimizer бесплатный, показывает рекомендации по типам инстансов прямо в консоли
- AWS Cost Explorer → Rightsizing Recommendations тоже бесплатно, с конкретными числами
Алгоритм простой:
- Берёте список рекомендаций
- Смотрите на метрики за последние 2 недели
- Если CPU < 20% и памяти хватает, уменьшаете тип инстанса
- Наблюдаете неделю
По моему опыту, инженеры боятся даунсайзить production. Это нормально. Начните со staging, там риск нулевой, а данные реальные.
5. Kubernetes: resource limits и bin packing
K8s это отдельная боль. Разработчики ставят requests: cpu: 2 потому что “на всякий случай”. Планировщик резервирует ноду под эти запросы, реально используется 10% от запрошенного. Нода полупустая, но считается занятой.
Что делать:
Kubecost или OpenCost (open-source версия) показывают стоимость в разрезе namespace, deployment, даже отдельного пода. Сразу видно, кто переплачивает.
Минимальные практики:
resources:
requests:
cpu: "100m" # реальное потребление, не "на всякий случай"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
Плюс отключайте dev-кластеры на ночь и выходные. Если кластер нужен только с 9 до 18 в будни, это уже минус 128 часов из 168 в неделю. Экономия 75% на dev.
6. On-demand vs provisioned: думайте при проектировании
Это про культуру, но с конкретным примером. Взять тот же DynamoDB. Если выбрать on-demand режим, вы платите за реальные запросы. Provisioned capacity означает, что вы платите за зарезервированную ёмкость, используете или нет.
Для MVP и непредсказуемой нагрузки лучше on-demand. Для стабильной высокой нагрузки provisioned дешевле.
Или другой пример: запускаете ML-модель. Используете GPU-инстанс потому что “ML = GPU”. А модель это простая классификация, которая отлично работает на CPU. GPU-инстанс в 5–10 раз дороже.
Инженер должен задавать себе вопрос о стоимости в момент проектирования, а не когда счёт уже пришёл.
Инструменты: что использовать
| Инструмент | Для чего | Цена |
|---|---|---|
| Infracost | Стоимость изменений в PR/CI | Бесплатно (open-source) |
| AWS Cost Explorer | Анализ расходов, rightsizing | Бесплатно |
| AWS Compute Optimizer | Рекомендации по инстансам | Бесплатно |
| OpenCost | Стоимость в K8s по namespace/pod | Бесплатно (open-source) |
| Kubecost | То же + удобный UI + alerting | Freemium |
| cloud-nuke | Автоудаление ресурсов в dev/staging | Бесплатно (open-source) |
На мой взгляд, для начала достаточно Cost Explorer + Infracost + cloud-nuke. Это ноль денег и один день настройки.
Как начать за один день: чеклист
Не надо внедрять всё сразу. Вот минимум который можно сделать сегодня:
Утро (2–3 часа):
- Открыть AWS Cost Explorer, посмотреть топ-5 сервисов по стоимости за последний месяц
- Включить Rightsizing Recommendations, выписать кандидатов
- Зайти в EC2 → Snapshots, найти снапшоты старше 6 месяцев
День (3–4 часа):
- Установить Infracost, интегрировать в один репозиторий с terraform
- Договориться с командой: в PR с инфраструктурой смотрим на стоимость
- Установить минимальный набор тегов для новых ресурсов (team, environment, owner)
Вечер (1–2 часа):
- Найти dev/staging ресурсы без тега
environment - Составить список того что можно выключить на ночь/выходные
- Поставить cloud-nuke на dev-окружение с периодом 7 дней
Структурированная оптимизация даёт 15–25% экономии за первые 60 дней, по данным SquareOps. Это не магия, а просто последовательная работа.
Почему это не задача финансов
Финансовый отдел видит счёт. Инженер видит причину.
Финансы не знают, что конкретный EKS-кластер можно уменьшить с 10 нод до 6 без последствий. Они не знают, что вот этот снапшот остался от инстанса, который снесли год назад. Они не могут оценить, стоит ли платить за reserved instances или лучше on-demand.
FinOps работает только если инженеры владеют стоимостью своих решений. Это четыре компонента которые описывает Ноам Леви из ActiveFence: видимость, короткий цикл обратной связи, оптимизация использования и, самое важное, мышление с учётом стоимости.
Последнее не приходит само. Его надо встроить в процессы: cost-as-code в PR, дашборды по командам, регулярный ревью расходов на планёрке.
По моему опыту, когда разработчик видит что его PR добавляет $2,000 в месяц к счёту, он начинает думать иначе. Не из страха. Просто потому что информация стала видимой.
Облако это не магия и не бесплатно. Это счётчик, который крутится 24/7. Ваша задача знать, что он считает.
Начните с малого. Поставьте Infracost сегодня. Посмотрите Cost Explorer. Найдите один мусорный снапшот и удалите его.
Это уже лучше чем ничего.
Читайте также


