Аудит облачного счёта: сначала исправьте архитектуру, чтобы сократить расходы

Почему счёт остаётся высоким после скидок

Скидка снижает тариф. Она не исправляет форму того, что вы запускаете.

Если команда держит большие базы данных, слишком крупные серверы приложений и простаивающие воркеры круглосуточно, счёт остаётся высоким в любом случае. Поэтому аудит облачных расходов должен начинаться с архитектуры. Цены говорят, сколько стоит каждая единица. Архитектура решает, сколько этих единиц вы оплачиваете, как долго они работают и нужны ли они вообще.

Переразмеренные сервисы — одна из самых частых утечек. Команды часто подбирают сервис под всплеск трафика, а затем оставляют его таким на месяцы после падения спроса. Ежемесячный платёж продолжается, даже когда сервис большую часть времени простаивает наполовину.

Старые окружения создают тот же тормоз. Стек для staging, демо‑настройка или тестовый кластер часто остаются онлайн после окончания работы. Один забытый набор кажется безобидным. Несколько таких окружений превращаются в реальную ежемесячную статью расходов.

Потери на хранение растут тихо. Логи остаются в «горячем» хранилище дольше, чем нужно. Бэкапы накапливаются. Снимки перекрываются. Команды копируют наборы данных в несколько мест, потому что это кажется безопаснее или быстрее в моменте. Ни один из этих пунктов по‑отдельности не выглядит драматично — поэтому они переживают множество бюджетных проверок.

Цены получают обвинения, потому что они видимы. Но форма использования — более серьёзная проблема, потому что она прячется за нормальным видом сервисов. Если развертывания создают слишком много всегда‑включённых ресурсов или данные двигаются чаще, чем нужно, скидки лишь подрезают края.

Небольшой стартап часто может сократить счёт быстрее, удалив неиспользуемое окружение, уменьшив два переразмеренных блока данных и задав ограничения хранения логов, чем тратя недели на переговоры о более выгодном тарифе. Представитель поставщика может немного снизить цену. Но именно дизайн решает общую сумму.

Где потери видны невооружённым глазом

Крупные облачные затраты обычно не появляются в одной шокирующей строке счёта. Они возникают из мелких архитектурных решений, которые остались в силе после изменений продукта.

Типичный пример — переразмеренная база данных. Команды выбирают большой управляемый инстанс на старте, трафик так и не подходит к этому пику, и база продолжает работать на 10–20% загрузке месяцами. Вы платите за лишние CPU, память и премиальную производительность хранения, которыми никто не пользуется.

Наложение инструментов — ещё одна тихая утечка. Одна команда добавляет очередь сообщений, другая — планировщики, кто‑то приносит workflow‑инструмент или serverless‑задачи для тех же фоновых работ. Каждое решение по отдельности имеет смысл. Вместе они создают дублирование работы, дублирование мониторинга и дублирование счетов.

Трафик между регионами легко пропустить, потому что в малых объёмах он кажется безобидным. Приложение работает в одном регионе, база в другом, логи уходят в третье место, а бэкапы копируются по расписанию между регионами. Ни одна передача сама по себе не кажется дорогой. Итог за месяц часто рассказывает другую историю.

Вы также платите за машины, которые ничего не делают. Простаивающие воркеры — классический пример. Они опрашивают пустые очереди день и ночь, даже когда продукт тих после рабочего времени. Превью‑окружения, внутренние инструменты и staging часто имеют ту же проблему: никто не настроил правила старта и остановки.

Лишние реплики тоже заслуживают жёсткой проверки. Команда может держать read‑реплики, standby‑ноды или дублирующие инстансы приложений, потому что когда‑то ожидала быстрый рост или хотела безопасность при миграции. Позже использование стабилизируется, но лишние копии остаются онлайн. Во многих конфигурациях меньшего числа реплик вполне хватит для реального риска.

Большинство потерь укладывается в знакомую картину: базы данных подобраны под пик, который не пришёл; две‑три службы выполняют одну и ту же фоновую задачу; трафик пересекает регионы без явной причины; воркеры и окружения работают по ночам и в выходные; а реплики защищают от проблемы, которой у бизнеса уже нет.

Как по шагам проверить счёт

Аудит облачных расходов работает лучше, если вы воспринимаете его как проверку архитектуры, а не учётную задачу. Цель проста: найти несколько решений, которые определяют большую часть затрат.

Начните с счётов и данных об использовании за последние три месяца. Один месяц может ввести в заблуждение. Запуск продукта, разовый бэкап или шумное тестовое окружение искажают картину.

Затем отсортируйте все строки расходов от больших к маленьким. Не начинайте с маленьких плат, которые кажутся раздражающими. Начните с самых больших чисел на странице — именно там работа обычно окупается.

Для каждой службы вверху списка напишите одно простое предложение о её задаче: «Запускает основное приложение.» «Хранит загрузки клиентов.» «Обрабатывает чтения из базы.» Если вы не можете объяснить сервис в одном предложении, скорее всего вы не понимаете, зачем он до сих пор существует.

Далее добавьте по две заметки рядом с каждым пунктом: кто за это отвечает и когда люди действительно это используют. База данных, которой никто не владеет, часто слишком большая месяцами. Staging‑кластер, который используют только по будням, не должен работать на полную мощность в выходные.

После этого сгруппируйте расходы в четыре корзины: compute, хранение, передача данных и вспомогательные инструменты. Это облегчает понимание формы утечки. Если compute высок, ищите переразмеренные инстансы, слишком много реплик или всегда‑включенные непроизводственные системы. Если хранение высоко — проверьте бэкапы, снимки, хранение логов и старые версии объектов. Если передача высока — проверьте трафик между регионами, использование NAT и «болтливые» сервисы.

Только после этого стоит смотреть на скидки и резервные планы. Более дешёвая ставка на неправильной конфигурации по‑прежнему оставляет вас с неправильной конфигурацией.

Большинство команд получают самый быстрый результат, проверяя первые три крупных статьи. Если одна управляемая база, один Kubernetes‑кластер и один бакет хранилища составляют 70% счёта, работайте с ними. Подрезать по доллару в десяти мелких сервисах приятно, но редко меняет итог.

Сначала проверьте форму сервисов

Большая часть облачных потерь начинается с решения о размере, которое никто не пересматривает. Команда выбирает большие инстансы на старте, добавляет реплики для безопасности и затем оставляет всё работающим после стабилизации трафика. Через полгода счёт отражает старые опасения, а не текущую нагрузку.

Для полезного обзора сравните реальное использование с формой каждого сервиса. Посмотрите CPU, память, активность диска и сетевой трафик за обычную неделю и за пиковую. Если сервер приложения постоянно использует 15% CPU и никогда не приближается к лимиту памяти, вы, вероятно, платите за запас, который не используете.

Базы данных заслуживают того же подхода. Команды часто поднимают несколько небольших управляемых баз, потому что каждому приложению или фиче хочется свой инстанс. Это выглядит аккуратно, но может стоить дороже, чем один правильно подобранный уровень базы с отдельными схемами, пользователями и правилами бэкапа. Три маленьких Postgres‑инстанса часто дороже одного среднего.

Несколько проверок обычно быстро раскрывают правду. Сравните пиковую и среднюю нагрузку перед изменением размера. Сначала убирайте лишние реплики в dev и staging. Проверьте, действительно ли внутренним инструментам нужна круглосуточная высокая доступность. Спросите, окупает ли управляемый сервис время команды своей ценой.

Непроизводственная нагрузка обычно даёт самый лёгкий выигрыш. Staging не нуждается в тех же репликах, классах хранения или фейловер‑настройках, что продакшен. Если команда работает с понедельника по пятницу, некоторые сервисы могут снижать масштаб или выключаться ночью без проблем.

Управляемые сервисы тоже требуют строгой проверки. Малому продукту с лёгким трафиком может не понадобиться одновременно managed Kubernetes, премиальная очередь и отдельный кластер поиска. Иногда проще на меньшем количестве машин даёт тот же результат за долю стоимости. Время команды важно, но многие компании переплачивают за удобство, которым почти не пользуются.

Контроль затрат обычно эффективнее всего на уровне архитектуры. Как только форма сервисов соответствует реальному спросу клиентов, скидки становятся бонусом, а не главным планом.

Проверьте хранение и перемещение данных

Затраты на хранение сначала кажутся безобидными. Центы за гигабайт не пугают. Счёт растёт, когда команды держат слишком много копий, сохраняют логи вечно и постоянно перемещают одни и те же данные между сервисами.

Хороший обзор спрашивает, действительно ли данные должны жить там, где они находятся сейчас. Быстрое хранилище для файлов, которыми часто пользуются. Старые экспорты, устаревшие загрузки и застарелые бэкапы обычно принадлежат в более холодный уровень, где доступ медленнее, но месячная стоимость значительно ниже.

Снимки требуют дополнительной проверки. Команды создают их из соображений безопасности, а затем больше не трогают. Если никто не восстанавливал снимок несколько месяцев, спросите, зачем он вообще существует. Оставьте только те точки восстановления, которые действительно нужны, протестируйте восстановление и удалите остальное.

Логи — ещё один тихий расход. Многие команды хранят подробные логи дольше, чем кто‑то их читает. Если инженеры обычно смотрят назад 7–30 дней при расследовании инцидентов, хранение всех debug‑логов год делает мало смысла. Длительную ретенцию оставляйте только для задач безопасности, аудита или юридических требований.

Копии накапливаются в неожиданных местах. Один и тот же набор данных часто оказывается в продакшен‑бакете, бэкап‑бакете, staging‑бакете, в другом регионе и у внешнего вендора. Некоторые копии необходимы. Многие — остатки после миграции, быстрого теста или привычки, которую никто не оспорил.

При проверке хранения посмотрите возраст снимков и историю восстановления, файлы в «горячем» хранилище без чтений месяцами, ретенцию логов относительно реальных окон расследования, дублирующиеся бакеты или кросс‑региональные реплики, которыми никто не пользуется, и транзакционные расходы между приложениями, регионами и внешними инструментами.

Перемещение данных важно не меньше, чем хранение. Приложение в одном регионе, общающееся с базой в другом, может создать стабильный поток плат за передачу. То же происходит, когда один сервис отправляет логи в вендора, другой их тянет обратно, а третий копирует для отчётов.

Одна небольшая правка может сэкономить больше, чем любая скидка. Перенесите неактивные файлы в холодное хранение, урежьте ретенцию логов, удалите мёртвые реплики и расположите «болтливые» сервисы ближе друг к другу. Команды часто обнаруживают, что утечка была не в прайслистe, а в форме данных и частоте их перемещения.

Проверьте привычки развёртывания

Много потерь связано с тем, как команды выкладывают изменения, а не с самими изменениями. Привычки развёртывания объясняют, почему расходы продолжают расти, даже если трафик не растёт.

Превью‑окружения — частая утечка. Они помогают при ревью, но должны исчезать, как только ревью закончено. Если команда открывает по десять pull‑request’ов в неделю и каждый держит полноценное окружение днями, счёт растёт без бизнес‑причины.

Staging часто имеет ту же проблему. Многие команды оставляют его работающим ночью, по выходным и в праздники, хотя им никто не пользуется. Если тестирование идёт в рабочие часы, ставьте staging по расписанию и запускайте только когда нужно. Это одно изменение может существенно сократить расходы на compute и базы.

Полные пересборки — ещё одна привычка, которую стоит исправить. Небольшое изменение фронтенда не должно триггерить полную пересборку всех сервисов, свежую копию базы и длинную тестовую матрицу, если ничего больше не поменялось. Сужайте деплой до части, которая действительно изменилась. Вы сэкономите минуты сборки, churn в хранилище и время инженеров.

Команды также тратят деньги, клонируя целые стеки для каждого проекта или клиента. Общие логирование, мониторинг, CI‑раннеры и внутренние инструменты обычно достаточно. Дублирование всего стека кажется безопасным, но создаёт множество мелких счетов, которые быстро суммируются и трудно заметить.

Потом идёт уборка. Старые контейнеры, неиспользуемые образы, забытые тестовые базы и одноразовые тома остаются потому, что за ними никто не отвечает. По‑одному они выглядят дешёвыми. Через несколько месяцев они перестают быть дешевыми.

Простое правило помогает: временное должно быть действительно временным. Команды, которые это соблюдают, обычно находят экономию быстрее, чем те, кто сначала просит скидку.

Простой пример для стартапа

Небольшая SaaS‑команда имела конфигурацию, которая сначала казалась разумной. Они запускали production, staging и превью‑окружение почти для каждой активной ветки. Это давало разработчикам свободу, но ежемесячный счёт облака рос.

Каждое окружение имело свою базу данных, кеш и стек мониторинга. Одна фича‑ветка запускала не только контейнер приложения. Она также поднимала PostgreSQL, Redis, сбор логов, метрики, бэкапы и несколько фоновых задач.

Дорогой частью была не нагрузка. Было дело в форме. Команда построила непроизводственные системы, которые слишком напоминали продакшен.

Большинство превью‑веток простаивали через день‑два. Никто их не удалял, и они держались всю неделю. Некоторые продолжали хранить логи, снимки и бэкапы долго после закрытия pull‑requestа.

Когда команда проверила счёт, они перестали искать купоны и начали считать копии. Они нашли более десятка превью‑стеков онлайн, хотя активно использовались только три. Staging тоже имел собственную базу и кеш, но делал мало реальной работы.

Они сделали три изменения. Превью‑окружения истекали через 48 часов, если кто‑то их не продлевал. Staging и превью стали использовать общие непроизводственные сервисы там, где изоляция не требовалась. Превью‑стеки перестали отправлять полный мониторинг и создавать долгоживущие бэкапы.

Это последнее изменение оказалось важнее, чем команда ожидала. Простые приложения не потребляют много CPU, но логи, метрики и хранение продолжают выставлять счёт тихо.

После очистки продакшен остался без изменений. Он сохранил свою базу, кеш, оповещения и политику бэкапов. Непроизводственная часть стала легче. Preview‑сборки использовали общую базу с отдельными схемами для тестовых данных, общий кеш и более короткую ретенцию логов.

Счёт упал быстро. Конфигурация, которая платила за множество полупустых систем, теперь платила за один реальный продакшен и гораздо меньший слой тестирования. Экономия пришла не от скидки, а от изменения привычек развёртывания и сокращения хранения, которые стали нормой.

Ошибки, которые делают проверки бесполезными

Аудит облачных расходов часто терпит неудачу ещё до открытия панели биллинга. Команды сначала просят кредита у поставщика, резервы или лучший тариф. Это может чуть‑чуть снизить счёт на месяц‑два, но не исправляет переразмеренные базы, простаивающие сервисы или дорогой трафик между системами, которые не должны быть разделены.

Ещё одна частая ошибка — слишком быстро урезать избыточность в продакшене. Второй узел, standby‑база или мультизонная настройка могут выглядеть дорогими на бумаге. Удаление их без проверки требований к доступности, влияния на клиентов и времени восстановления может превратить экономию в дорогостоящий простой. Начните с мест, где риск низок, а не там, где падение критично для бизнеса.

Многие команды тратят часы на мелкие сборы. Они спорят о маленьком инструменте мониторинга или забытом тест‑бакете, в то время как compute, базы и сетевой трафик съедают большую часть бюджета. Если три верхние статьи формируют основную часть расходов, начните с них. Ремонт на $20 приносит удовлетворение. Снижение на 30% в основных сервисах меняет счёт.

Один месяц в изоляции даёт ещё одну плохую картину. Один счёт может скрывать запуск продукта, пик трафика, изменение политики бэкапов или нового крупного клиента. Сравнивайте несколько месяцев. Тренды говорят правду быстрее, чем один «чистый» скриншот.

Инфраструктура — только часть истории. Привычки команды продолжают воссоздавать потери после очистки. Инженеры оставляют превью на выходные. Стандартные размеры инстансов остаются после старта. Развёртывания пересобирают и отправляют больше, чем изменилось. Логи остаются на debug‑уровне в продакшене. Хранилище растёт, потому что никто не установил правила ретенции.

Полезный аудит связывает затраты с архитектурными решениями и повседневным поведением команды, а затем исправляет и то, и другое.

Быстрые проверки на эту неделю

Большая часть экономии обнаруживается в нескольких скучных местах. Вам не нужен полный аудит, чтобы их заметить. Начните с непроизводственных систем, потому что они часто работают дольше, чем нужно.

Затем пробегитесь по этому чек‑листу:

• Проверьте, действительно ли dev, staging и QA работают 24/7 без причин.
• Проверьте ретенцию логов и сократите её под реальные окна расследований.
• Проверьте дублирование данных в хранилище приложений, бэкапах, экспортах аналитики и общих дисках.
• Проверьте уровни сервиса и выясните, нужен ли премиум‑план при лёгком трафике.
• Проверьте старые окружения на предмет владельцев и даты истечения.

Потери на хранение легко пропустить, потому что каждая строка выглядит маленькой. Вместе они превращаются в реальную ежемесячную статью расходов. Один стартап может платить за продакшен‑данные, данные реплик, копии бэкапов, BI‑экспорты и логи, которые все описывают одно и то же поведение клиента в чуть разных местах.

Привычки развёртывания тоже важны. Команды часто создают новое окружение для каждого теста, а затем забывают удалить его. Дайте временным окружениям владельца и дату выключения.

Если хотите быстрое победное действие на этой неделе, откройте счёт, отсортируйте по самым высоким ежемесячным статьям и задайте один прямой вопрос для каждой: «Кто использует это каждый день?» Если никто не отвечает одним предложением, этой статье нужен более тщательный взгляд.

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

Начните с короткой карточки для каждого изменения, которое вы нашли. Запишите три числа: ожидаемая ежемесячная экономия, усилия для внесения изменения и риск для аптайма или скорости доставки. Это держит работу честной. Исправление, которое экономит $300 в месяц и занимает два часа, часто лучше большой задачи, которая тянется неделями.

Затем приоритизируйте просто. Сначала низкорисковые и малозатратные изменения. Средние по усилиям задачи отложите на вторую очередь. Рискованные миграции оставьте до безопасного тестирования. Отбрасывайте идеи, которые мало экономят и создают много работы.

Меняйте по одному пункту за раз. Если вы одновременно уменьшаете размер сервиса, ставите старые снимки на паузу и меняете тайминги развёртывания, вы не поймёте, что именно снизило счёт. Записывайте расходы до и после каждого изменения и держите запись простую: дата, сервис, сделанное изменение, ожидаемая экономия, фактическая экономия через 7–30 дней.

Многие команды теряют эффект аудита, потому что убирают раз и потом старые привычки возвращаются. Поставьте короткий месячный обзор в календарь. Полчаса хватает, чтобы проверить форму сервисов, рост хранилища, простаивающие окружения и новые инструменты, которые попали в стек без плана очистки.

Если хотите второе мнение перед большой очисткой, внешний ревьюер часто замечает паттерны, которые ваша команда перестала видеть. Oleg Sotnikov at oleg.is работает со стартапами и мелким бизнесом как Fractional CTO и советник, помогая командам исправлять архитектуру, инфраструктурный сплайн и практическое внедрение AI без добавления нового мусора.

Лучший следующий шаг обычно мал и измерим. Выберите одно изменение, которое можно выполнить на этой неделе, измерьте результат и используйте его, чтобы выбрать следующий шаг.