CloudFormation не видит весь дрейф — что проверить перед исправлением стека

Проверка дрейфа CloudFormation не является полной сверкой инфраструктуры с шаблоном. Статус IN_SYNC подтверждает совпадение только поддерживаемых ресурсов и доступных для чтения свойств, которые явно заданы в шаблоне или параметрах; вложенные стеки проверяются отдельно.

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

1. Отделите управляемые ресурсы от неуправляемых

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

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

Практический разбор AWS от 21 августа 2026 года разделяет переход на получение видимости, принятие ресурсов под управление и последующую автоматизацию. Сгенерированный шаблон показывает отправную точку, но сам по себе не запрещает изменения через консоль, CLI или SDK; решение об импорте либо пересоздании принимается отдельно для каждого ресурса с учётом критичности, зависимостей и допустимого простоя.

2. Сгенерируйте шаблон и проверьте, чего в нём нет

Для инфраструктуры, созданной вне CloudFormation, используйте генератор инфраструктуры как кода IaC Generator. Рабочая последовательность включает региональное сканирование, выбор найденных и связанных ресурсов, создание шаблона и импорт. Для автоматизации предусмотрены команды start-resource-scan, list-resource-scan-resources, list-resource-scan-related-resources и create-generated-template.

Документация IaC Generator устанавливает две важные границы: генератор работает с типами ресурсов, поддерживаемыми AWS Cloud Control API в выбранном регионе, а сканирование охватывает только ресурсы, доступные запускающей роли для чтения. Недостаток разрешений не обязательно завершает сканирование ошибкой — недоступные ресурсы могут просто отсутствовать в результате.

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

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

3. Разберите пропуски и ложные расхождения

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

• Неявное значение — возможный пропуск. Если свойство не записано в шаблоне и не передано параметром, его значение по умолчанию не участвует в проверке. Важные для контроля свойства следует задавать явно, даже если используется стандартное значение сервиса.
• Неподдерживаемый ресурс — пропуск. Такой ресурс получает статус NOT_CHECKED. Стек без ресурсов, поддерживающих обнаружение дрейфа, при этом может получить IN_SYNC, поэтому одного итогового статуса стека недостаточно.
• Вложенный стек — пропуск родительской проверки. Операция для корневого стека не проверяет вложенные. Обнаружение дрейфа нужно запускать непосредственно для каждого из них.
• Недоступное свойство — пропуск. В проверку не попадают значения, которые сервис не возвращает или которые нельзя восстановить из фактического состояния. Среди документированных примеров — пароль профиля входа IAM, исходный код функции Lambda и свойство KMSKeyId.
• Связь между стеками — возможная неточность. CloudFormation анализирует присоединяемые ресурсы внутри шаблона, но не может выполнить такой анализ через границы стеков.
• Эквивалентная запись — возможное ложное расхождение. Одинаковые по смыслу, но различно записанные значения могут считаться разными. Элементы массива, добавленные исходным сервисом по умолчанию, также способны выглядеть как ручное изменение.

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

4. Разделите импорт и изменение конфигурации

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

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

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

5. Проверяйте всё дерево стеков и список исключений

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

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

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

Читайте также:

• WHOIS уже недостаточно: как проверить домен перед покупкой семью способами
• Сквозная аналитика не видит весь путь клиента — но помогает считать прибыль
• Теневой бан в Инстаграме – что это такое, как проверить аккаунт и снять ограничения