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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (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, внедрение стандартных практик тегирования ресурсов и реализацию элементов контроля управления затратами, которые позволят вам соблюдать бюджеты в будущем.

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

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

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

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

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

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

Стоит знать две переменные окружения: INFRACOST_CLI_ARGS добавляет аргументы к команде разбивки (breakdown), что позволяет указать Infracost на файл использования (usage file), чтобы тарифицируемые службы оценивались по вашему реальному потреблению, а не по значениям по умолчанию. 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), многофакторная аутентификация и пулы частных воркеров, встроенные в продукт. Spacelift имеет сертификат SOC 2 Type II и предоставляет артефакты соответствия и безопасности, включая ресурсы GDPR и DPA через Spacelift Trust Center.

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

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

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

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

С помощью Spacelift вы получаете:

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

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

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

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

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

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

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

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

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

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

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

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

Как найти потерянные (orphaned) ресурсы в AWS, Azure или GCP?

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