Как провести аудит облачных расходов при получении в наследство нового окружения

Аудит расходов на облако в унаследованном окружении означает выяснение того, за что вы платите, кто за это отвечает и что можно безопасно удалить, и всё это без базового уровня для сравнения. Отсутствие этого базового уровня — самая сложная часть. В созданной вами инфраструктуре вы знаете, почему существует каждый ресурс. В унаследованной инфраструктуре каждая строка расходов вызывает вопросы: для чего это нужно, почему был выбран этот тарифный план и зависит ли от этого что-либо до сих пор?

Гадание на кофейной гуще обходится дорого в обе стороны. Оставите всё — будете бесконечно платить за мусор. Удалите не то — можете случайно уничтожить нигде не задокументированный сервис.

Эта статья предлагает повторяемый процесс аудита расходов на облако в унаследованном окружении AWS, Azure или Google Cloud: от чтения первого счета до настройки защитных механизмов, которые не позволят затратам снова вырасти.

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

• Сравните несколько периодов выставления счетов и ищите всплески, а не общие суммы.
• Проведите инвентаризацию того, что реально работает, а затем сопоставьте это со строками расходов.
• Проведите аудит тегов, а затем распределите расходы по командам и центрам затрат.
• Сравните свой IaC с реальностью. Дрифт конфигурации и неуправляемые ресурсы стоят денег.
• Удалите сироты: отключенные диски, неиспользуемые IP-адреса, устаревшие снимки (snapshots), пустые планы.
• Приведите ресурсы в соответствие с измереннойutilization (использованием), а не с выделенной емкостью.
• Зарегистрируйте каждый унаследованный зарезервированный экземпляр (reserved instance), план экономии (savings plan) и подписку.
• Консолидируйте полученные данные, а затем добавьте оценку стоимости до слияния (pre-merge cost estimation), чтобы расходы не вернулись.

Аудит затрат на недавно унаследованные окружения состоит из трех основных этапов:

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

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

Готовы раскрыть скрытые расходы в унаследованных окружениях? Вот ключевые шаги, которые помогут вам перейти от чистого листа к четкому пониманию того, на что уходят ваши деньги:

1. Проанализируйте существующие данные о выставлении счетов

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

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

2. Установите, что на самом деле работает в окружении

Теперь пришло время перейти к более детальным данным. Используйте доступные инструменты наблюдаемости (observability) и консоли облака, а также любые соответствующие конфигурационные файлы IaC, чтобы обнаружить то, что реально находится в окружении. Одновременно сопоставьте статистику использования, чтобы проверить, нужны ли ресурсы, а затем изучите конвейеры развертывания (deployment pipelines), чтобы найти, какие проекты выделяют каждый компонент.

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

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

3. Проведите аудит тегов и отследите расходы до владельцев

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

Аудит текущей системы тегов

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

Использование тегов для отнесения затрат к ресурсам и командам

Используйте ваши данные о выставлении счетов, сведения о рабочих нагрузках и метаданные ресурсов (например, принадлежность к команде и исходный репозиторий IaC), чтобы пометить каждую часть инфраструктуры тегом с указанием бизнес-цели, которую она выполняет. Зафиксируйте подтверждающие данные для каждого решения о назначении тега, чтобы будущие аудиты могли легко проверить, почему были применены те или иные теги.

Одна техническая деталь часто подводит команды в AWS: тег никак не повлияет на ваш счет до тех пор, пока вы не активируете этот ключ тега для распределения затрат в консоли Billing and Cost Management. При активация не имеет обратной силы, поэтому более ранние расходы остаются в категории без тегов. В унаследованном окружении это стирает историю, которую вы больше всего хотите изучить.

Используйте опцию Backfill tags на той же странице, и AWS применит ваши активные ключи тегов к данным о затратах за срок до 12 месяцев назад, при условии, что ресурс имел этот тег в то время. Вы должны находиться в учетной записи управления (management account), начальный месяц — это самое раннее, что вы можете выбрать, и вы получаете один запрос в день.

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

4. Проверьте наличие дрифа между IaC и реальностью

Унаследованный репозиторий IaC описывает то, что кто-то намеревался развернуть, в то время как счет описывает то, что существует на самом деле. Разрыв между ними — это место, где прячутся необъяснимые расходы.

Дрифт и неуправляемая инфраструктура — это две проблемы, которые обходятся по-разному. Дрифт — это управляемый ресурс, который кто-то изменил вручную, например экземпляр, размер которого был изменен во время инцидента и никогда не возвращен в исходное состояние. Неуправляемая инфраструктура существует в учетной записи, но нигде не отражена в коде, поэтому ни один план не помечает ее, а проверка не вызывает вопросов. В унаследованной среде неуправляемая инфраструктура обычно является более дорогой проблемой. Выявляйте дрифт с помощью плана только для обновления (refresh-only) во всех рабочих пространствах.

Terraform возвращает 0 для пустого диффа, 1 для ошибки и 2 при наличии изменений, поэтому вы можете написать скрипт для этого во всех стеках и собирать коды завершения вместо чтения вывода плана.

Выявите второе, сопоставив инвентарь провайдера из AWS Config, Azure Resource Graph или Google Cloud Asset Inventory со списком состояния terraform state list. Перенесите все, что стоит сохранить, с помощью блока import и позвольте terraform plan -generate-config-out=adopted.tf составить для вас черновик конфигурации.

Затем автоматизируйте это. Обнаружение дрифта в Spacelift выполняет предлагаемые запуски по заданному вами расписанию cron, помечает ресурсы с дрифтом в представлении ресурсов (Resources) и при необходимости выполняет их реконсилиацию.

5. Поиск брошенных и неиспользуемых ресурсов

Брошенный ресурс продолжает приносить расходы, но больше ничего не обслуживает. От него ничего не зависит, и никакой мониторинг не жалуется, когда он исчезает. Отключенные диски, несопоставленные IP-адреса, устаревшие снимки и образы машин, балансировщики нагрузки без работоспособных целевых объектов и пустые планы App Service — вот обычные находки.

Сначала проверьте публичные IP-адреса, поскольку AWS выставляет счета за каждый публичный IPv4-адрес с февраля 2024 года независимо от того, привязан он к чему-либо или нет.

Для всего остального начните со средств обнаружения самого провайдера.

• AWS: Cost Optimization Hub объединяет рекомендации по простоям и изменению размеров из Compute Optimizer и рекомендации по обязательствам из Cost Explorer, а затем выполняет дедупликацию пересекающейся экономии. Trusted Advisor теперь отображает те же проверки. И для Hub, и для Compute Optimizer необходимо включить опцию, что в унаследованной учетной записи обычно не сделано.
• Azure: Вкладка Cost в Azure Advisor отмечает неподключенные диски, пустые планы App Service, задействованные не полностью виртуальные машины и масштабируемые группы, а также истекающие резервирования.
• Google Cloud: Рекомендатели неиспользуемых ресурсов отмечают постоянный диск или IP-адрес, который не использовался в течение 15 дней, и пользовательский образ, который не использовался столь же долго. Неиспользуемые виртуальные машины обрабатываются отдельным рекомендателем.

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

6. Проверка загрузки и оптимизация размеров

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

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

Например, кажущиеся недоиспользурованными экземпляры на самом деле могут быть неактивными резервными элементами, которые задействованы в плане аварийного восстановления унаследованной среды.

7. Аудит ценовых обязательств и подписок

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

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

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

8. Консолидация полученных данных и приоритизация оптимизации

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

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

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

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

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

Spacelift запускает Infracost во время фаз планирования и применения запуска. Чтобы включить его для стека, добавьте метку infracost и задайте переменную окружения INFRACOST_API_KEY. Поместите этот ключ в контекст и прикрепите контекст к каждому стеку, которому он нужен, вместо того чтобы копировать ключ из одного стека в другой.

Как только это включено, Spacelift отправляет сводку затрат прямо в ваши пул-реквесты, поэтому проверяющие видят ежемесячную дельту рядом с диффом. Полная детализация также поступает в ваши политики планов в формате JSON в поле third_party_metadata.infracost, что делает оценку инструментом обеспечения соблюдения. Политика может заблокировать изменение, которое выводит стек за рамки бюджета:

Тот же ввод содержит pastBreakdown, поэтому вы можете предупреждать о процентном увеличении вместо абсолютных итогов, что обычно работает лучше для стеков, которые уже велики.

Стоит знать две переменные окружения: INFRACOST_CLI_ARGS добавляет аргументы к команде детализации, с помощью которой вы указываете Infracost на файл использования, чтобы тарифицируемые службы оценивались по вашему реальному потреблению, а не по значениям по умолчанию. INFRACOST_WARN_ON_FAILURE, установленная в значение true, снижает ошибки Infracost до предупреждений вместо сбоя запуска, что важно при внедрении этого в стеки, которые вы еще не до конца понимаете.

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

Оценки остаются оценками. Infracost оценивает ресурс, а не ваш трафик, поэтому за передачей данных и тарифами на основе запросов по-прежнему нужно следить в ваших платежных данных. Цель здесь — определить направление и порядок цифр до слияния, а не прогнозировать расходы до цента.

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

• Начните с основ: внимательное изучение существующих счетов и использование таких инструментов, как AWS Cost Explorer, могут указать вам прямо на потенциальные проблемные зоны, позволяя быстро собрать «низко висящие фрукты».
• Не забывайте о внешних и сторонних расходах: ресурсы в рамках среды не всегда полностью отражают ее стоимость. Крайне важно также проверить, зависят ли компоненты от платных внешних сервисов, таких как подписки на сторонние SaaS-решения.
• Анализируйте как исторические расходы, так и текущую ситуацию: ориентация только на данные о недавних расходах может ввести в заблуждение. Вместо этого стремитесь также оценивать исторические затраты за длительные периоды времени, например за 90 дней, 1 год или 3 года. Это может помочь выявить скрытые аномалии, такие как сервис, который начал накапливать избыточные расходы лишь в последние несколько месяцев.
• Сосредоточьтесь на группировке затрат по конкретным центрам затрат: маркировка расходов по сервисам, командам и назначениям облегчает анализ того, куда на самом деле уходит ваш бюджет. После того как вы определили четкие центры затрат, вы можете соотнести свой анализ с бизнес-приоритетами, вместо того чтобы рассматривать затраты на сырые ресурсы по отдельности.
• Выясните причины оценки отдельных затрат: когда вы получаете унаследованную среду, постарайтесь пообщаться с бывшими инженерами, архитекторами инфраструктуры и операторами, если это возможно. Могут существовать веские причины, почему внешне дорогие сервисы были выбраны вместо более дешевых альтернатив, даже если кажется, что они на самом деле не нужны.

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

Платформа, такая как Spacelift, может помочь вашей организации эффективнее управлять облачной инфраструктурой. Spacelift — это платформа оркестрации инфраструктуры, созданная для эпохи программного обеспечения с ускорением на базе ИИ. Она управляет полным жизненным циклом как традиционной инфраструктуры как кода, так и инфраструктуры, подготавливаемой с помощью ИИ, поддерживая такие инструменты, как OpenTofu, Terraform, Ansible, Pulumi, Kubernetes и CloudFormation.

Безопасность является одним из главных приоритетов Spacelift, а такие функции, как политика как код, шифрование, единый вход (SSO), многофакторная аутентификация (MFA) и пулы частных воркеров, встроены в продукт. Spacelift имеет сертификат SOC 2 Type II и предоставляет артефакты соответствия требованиям и безопасности, включая ресурсы GDPR и DPA, через Spacelift Trust Center.

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

Для некритичных рабочих нагрузок, таких как тесты, пилотные проекты (POC) и демоверсии, Spacelift Intelligence добавляет уровень на базе ИИ, который обеспечивает подготовку на естественном языке, диагностику и оперативные аналитические данные, благодаря чему разработчики могут запрашивать инфраструктуру без написания конфигурационного кода, в то время как платформенные команды сохраняют полный контроль и видимость.

Интеграции Spacelift с запросами на слияние (pull request) держат всех в курсе того, что изменится, показывая, какие ресурсы будут затронуты новыми слияниями. Spacelift также позволяет вам применять политики и автоматические проверки на соответствие требованиям, которые предотвращают опасные упущения.

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

Вместе со Spacelift вы получаете:

• Политики для контроля того, какие ресурсы могут создавать инженеры, какие параметры они могут иметь, сколько одобрений требуется для запуска, какой тип задачи выполняется, что происходит при открытии запроса на слияние и куда отправлять уведомления
• Зависимости стеков для построения рабочих процессов автоматизации с несколькими инфраструктурами и зависимостями, с возможностью создать рабочий процесс, который, например, генерирует ваши экземпляры EC2 с помощью Terraform и объединяет их с Ansible для их настройки
• Инфраструктуру самообслуживания с помощью чертежей (Blueprints) и шаблонов (Templates), позволяющую вашим разработчикам заниматься тем, что важно — разработкой кода приложений, не жертвуя при этом контролем
• Удобства, такие как контексты (переиспользуемые контейнеры для ваших переменных среды, файлов и хуков), а также возможность запускать произвольный код
• Обнаружение дрейфа и дополнительное исправление

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

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

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

Часто задаваемые вопросы

• Как провести аудит облачных расходов на унаследованной инфраструктуре? Работайте в три этапа: соберите данные о выставлении счетов и использовании, привяжите каждую затрату к владельцу и бизнес-цели, а затем оптимизируйте то, что осталось. Ничего не меняйте до завершения первых двух этапов, потому что причина, по которой ресурс кажется неэффективным, часто является причиной его существования.

Как провести аудит облачных расходов на унаследованной инфраструктуре?

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

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

Каковы наиболее частые источники облачных отходов?

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

• Как найти осиротевшие ресурсы в AWS, Azure или GCP? Cost Optimization Hub в AWS, вкладка «Затраты» в Azure Advisor и рекомендатели простаивающих ресурсов в Google Cloud отмечают диски, IP-адреса и образы, к которым ничего не подключено. Сверьте то, что они возвращают, с вашим состоянием IaC, поскольку ресурс, отсутствующий в состоянии, — это ресурс, которым никто не управляет.

Как найти осиротевшие ресурсы в AWS, Azure или GCP?

Cost Optimization Hub в AWS, вкладка «Затраты» в Azure Advisor и рекомендатели простаивающих ресурсов в Google Cloud отмечают диски, IP-адреса и образы, к которым ничего не подключено. Сверьте то, что они возвращают, с вашим состоянием IaC, поскольку ресурс, отсутствующий в состоянии, — это ресурс, которым никто не управляет.