Как сократить расходы на Yandex Cloud без потери скорости

Кратко

Счёт Yandex Cloud растёт, а связь с бизнес метриками неочевидна — типичная ситуация через 3–6 месяцев после миграции. Команда добавляла VM «на всякий случай», диски от старых тестов не удалили, боевой контур крутится ночью на полной мощности, а dev-среды работают 24/7. управление облачными затратами — не абстрактная экономия «где нибудь», а системная работа: инвентаризация, права sizing, политики shutdown, резервирование там, где оно нужно, и отказ от лишнего.

На практике после ревью инфраструктуры клиентов SmartProektSystems (официальный партнёр Yandex Cloud) экономия 20–40% без деградации SLA достижима в большинстве кейсов малого и среднего бизнеса. Ниже — откуда берётся перерасход, как провести аудит затрат и что внедрить в первую очередь.

Почему облако «внезапно» дорожает

• Эффект старта. При миграции закладывают запас 2–3× «чтобы точно хватило» — и забывают ужать после стабилизации.
• Нет владельца ресурсов. Dev поднял VM, уволился — инстанс работает полгода.
• Отсутствие tagging/labels. Непонятно, какой проект или отдел генерирует расход.
• Диски и снимки состояния. Удалённая VM, а SSD и бэкапы остались — классический «забытый хвост».
• Over-provisioned БД. Managed PostgreSQL на 8 vCPU, а загрузка CPU — 12%.
• Нет расписания dev/test. Тестовый контур идентичен боевой контур по мощности и работает круглосуточно.
• Исходящий трафик и Object Storage. Неоптимальная раздача статики, жизненный цикл policy не настроена.
• Резервирование не использовано. Стабильная базовая нагрузка платится по фактическому потреблению, хотя подходит резервирование ресурсов.

Облако не «дорогое» само по себе — дорогое неуправляемое облако.

управление облачными затратами: три слоя управления

Inform — видимость: кто, что, сколько тратит. Billing export, labels, дашборды, алерты на бюджет (+10% к прошлому месяцу).

Optimize — технические меры: подбор размера ресурсов, удаление мусора, расписания, уровни хранения.

Эксплуатация — процессы: согласование новых ресурсов, квартальный пересмотр, управление облачными затратами в критерии готовности новых сервисов.

Без эксплуатации первые два слоя откатываются за 2–3 месяца — команда снова плодит «временные» VM.

Шаг 1: инвентаризация и «забытые» ресурсы

Первый проход делаем за 2–5 дней. Смотрим:

• все VM и их utilization (CPU, RAM, disk IOPS) за 14–30 дней;
• unattached disks и старые снимки состояния;
• public IP, привязанные к остановленным инстансам;
• load balancer'ы без backend'ов;
• тестовые кластеры K8s, namespace'ы без pod'ов;
• Object Storage bucket'ы без политики жизненного цикла (старые логи, бэкапы без TTL).

Quick win: один клиент e-commerce платил ~48 000 ₽/мес за «забытые» диски и три тестовых сервера прошлого подрядчика — после чистки минус 19 000 ₽ без изменения боевой контур.

Шаг 2: подбор размера ресурсов

Подбор размера ресурсов — не «урезать всё до минимума», а сопоставить ресурс с фактической нагрузкой и запасом на пик. Алгоритм:

1. собрать метрики Monitoring за 30 дней: CPU p95, RAM, disk, network;
2. отделить batch/cron-пики от sustained load;
3. для VM — перейти на класс с меньшим vCPU/RAM или на preemptible для некритичных worker'ов;
4. для Managed PostgreSQL/MySQL — сменить preset или включить автомасштабирование хранилища;
5. для K8s — настроить запросы и лимиты ресурсов, HPA, автомасштабирование кластера, убрать «fat» pod'ы по умолчанию.

Важно: подбор размера ресурсов делаем после анализа сезонности. Black Friday и закрытие квартала — не время ужимать боевой контур.

Шаг 3: dev/test — отдельные правила

Dev и тестовый контур не обязаны повторять боевой контур один в один:

• меньший класс VM, shared K8s namespace;
• Managed DB минимального tier с anonymized data;
• автоостановка в нерабочие часы (cron, Yandex Cloud Functions + API, Terraform schedule);
• выключение на выходные для команд без релизов;
• ephemeral среды для feature branch — подняли, протестировали, удалили.

Экономия на non-боевой контур часто 40–60% этих сред при том же качестве тестирования — если тесты автоматизированы и данные достаточны.

Шаг 4: хранилище и трафик

Object Storage: жизненный цикл rules — hot → cold → delete для логов, медиа архивов, старых бэкапов. CDN (Yandex Cloud CDN) для статики — меньше исходящего с origin и быстрее для пользователей.

Диски: не все данные нужны на network SSD; снимки состояния по расписанию вместо «полный клон диска каждый день на отдельный SSD».

Межзонный и egress-трафик — проектируем сервисы в одной zone/VPC где возможно; выгрузки в analytics — batch ночью.

Как читать billing Yandex Cloud

Консоль billing показывает детализацию по сервисам, folder, labels. На первом аудите смотрим:

• Compute Cloud — доля CPU/RAM, сколько инстансов stopped vs running;
• Managed databases — класс инстанса vs метрики Monitoring;
• Хранилище — объём по классу, рост за 3 месяца;
• Network — исходящий трафик, public IP, load balancer hours;
• Kubernetes — master + worker nodes, неиспользуемые node group.

Экспорт в CSV или интеграция с BI (DataLens, Google Sheets) помогает CFO видеть тренд, а не только «итого в конце месяца».

Кейс: интернет-магазин, счёт вырос с 120 до 210 тыс. ₽

Типичная картина: после Black Friday оставили удвоенный автомасштабирование max, три реплики API вместо двух, снимки состояния без retention. За две недели пересмотр облачных затрат:

1. вернули HPA max к расчётному p99 + 30% запас;
2. удалили 4 unattached SSD (180 ГБ);
3. тестовый контур выключили ночью и в воскресенье;
4. перевели архив медиа в cold хранилище;
5. зарезервировали исходный уровень 2 VM на год.

Итог: ~168 тыс. ₽/мес (−20%), latency p95 без изменений, SLA по доступности 99.95% сохранён.

Шаг 5: резервирование и скидки

Если исходный уровень-нагрузка стабильна 6+ месяцев, имеет смысл:

• Committed Use / резервирование vCPU и RAM на 1–3 года — скидка к по фактическому потреблению;
• гранты и программы для партнёров (актуальные условия уточняем как партнёр Yandex Cloud);
• единый billing account с лимитами по folder/project для подразделений.

Резервировать «всё» нельзя — burst и сезонность оставляем по фактическому потреблению. Типичная схема: 60–70% исходный уровень — reserved, остальное — elastic.

Шаг 6: governance — чтобы не расползлось снова

• Обязательные labels: project, env (боевой контур/stage/dev), owner, затраты-center;
• Policy: новая VM > X ₽/мес — согласование; TTL на тестовый стенд разработки ресурсы 30 дней;
• Бюджетные алерты на folder и на весь account — 50%, 80%, 100% порога;
• Ежемесячный отчёт для CFO: топ 5 сервисов, отклонение от plan, рекомендации;
• Квартальный пересмотр облачных затрат с инженерами и бизнесом.

Реалистичные цифры экономии

Обещать «минус 70% без последствий» — нечестно. Если экономия >40% — обычно находили не только overprovision, но и мусор или дубли боевой контур сред.

Чего не делать ради экономии

• Убрать бэкапы и мониторинг — экономия копейки, риск простоя на миллионы.
• Prod на preemptible VM — для stateless worker'ов иногда да, для БД и core API — нет.
• Single AZ без DR — если бизнес требует время восстановления и допустимая потеря данных, экономия иллюзорна.
• «Сожмём до 100% CPU» — нет запаса на пик = инцидент при распродаже.
• Shadow IT — разработчики уносят нагрузку на личные карты; бюджет «дешевеет», риски растут.

Как мы проводим аудит облачных затрат в СмартПроектСистемс

1. Доступ на read-only к billing и Monitoring (или выгрузка в CSV).
2. Отчёт «heat map» — топ ресурсов по затраты и utilization.
3. Список quick wins — можно применить за 1–3 дня без риска.
4. План развития 30/60/90 — подбор размера ресурсов, schedules, governance, reserved capacity.
5. Внедрение — с вашей командой или под ключ; change windows согласуем.
6. Контроль — через месяц сверка фактической экономии с прогнозом.

Аудит управление облачными затратами — от 80 000 ₽ для одного каталога или аккаунта малого и среднего бизнеса. Полное внедрение — по смете после отчёта. Часто окупается за 1–2 месяца счёта облака.

FAQ

Это не задача нашего штатного админа? Частично да, но нужны время, доступ к billing и практика управление облачными затратами. Внешний аудит даёт свежий взгляд и бенчмарк по рынку.

Post-optimization SLA упадёт? При корректном подходе — нет. Метрики latency и error rate мониторим до/после.

Работаете только с Yandex Cloud? Фокус — Yandex Cloud как партнёр; принципы управление облачными затратами универсальны.

Можно совместить с миграцией? Да. Идеально — заложить управление облачными затратами в целевую архитектуру до переключение, а не чистить хаос после.

Как часто повторять аудит? Quick scan — ежемесячно (алерты + топ 10 ресурсов). Полный пересмотр облачных затрат — раз в квартал или после крупного релиза/ сезонного пика.

Чеклист «первая неделя управление облачными затратами»

1. Включить budget alerts на account и боевой контур-folder.
2. Навесить labels env/project/owner на все ресурсы без меток.
3. Выгрузить список disks без attached VM — кандидаты на удаление.
4. Сравнить CPU/RAM p95 боевой контур за 30 дней с размером инстансов.
5. Настроить stop schedule хотя бы на одной dev-среде — проверить экономию.
6. Согласовать с командой политику: «временная» VM живёт не более 14 дней.

Эти шаги не требуют архитектурных изменений и часто дают первые 10–15% экономии уже в первый месяц.

управление облачными затратами и безопасность: где экономить нельзя

Сокращение затрат не должно ослаблять контур безопасности. Оставляем в бюджете без обсуждения:

• WAF и DDoS-защита для публичных сервисов;
• резервное копирование боевой контур с вне площадки хранением и тестом восстановление;
• централизованное логирование и retention по требованиям ИБ;
• multi-AZ для критичных БД, если время восстановления и допустимая потеря данных это предполагают;
• secrets management (Lockbox), а не «экономия» на хранении ключей в plain text.

Экономия достигается за счёт устранения waste, а не за счёт отказа от DR и мониторинга — иначе один инцидент съест годовую «выгоду».

Что делать дальше

Если последний счёт Yandex Cloud удивил — не откладывайте инвентаризацию. Первые «забытые» диски и выключенные тестовый контур находятся за день; 20–40% экономии — реалистичная цель для большинства компаний без жертвования отказоустойчивостью.

SmartProektSystems проводит аудит облачных затрат, настраивает мониторинг бюджетов, подбор размера ресурсов и политики dev/test в Yandex Cloud. Подробнее об услугах Yandex Cloud — пришлите скрин billing или объём счёта, вернёмся с оценкой потенциала экономии.