Инженер DevOps развернул шаблон CloudFormation, который запускает веб-приложение (ALB, целевую группу, шаблон запуска, использующий AMI Amazon Linux 2, группу Auto Scaling, группу безопасности и базу данных RDS MySQL). Пользовательские данные шаблона запуска выполняют скрипт для установки и запуска приложения. После обновления пользовательских данных до новой версии приложения и повторного развертывания через конвейер CI/CD проверки работоспособности ALB завершаются сбоем, и все цели отображаются как неработоспособные. Стек CloudFormation показывает UPDATE_COMPLETE, но журнал экземпляра EC2 показывает, что Apache не удалось запустить из-за ошибки конфигурации. Как инженер может заставить CloudFormation завершить развертывание сбоем, если скрипт пользовательских данных не завершится успешно?

Правильный ответ — использование cfn-signal с политикой WaitOnResourceSignals. Утилита cfn-signal, запускаемая из пользовательских данных EC2, отправляет сигналы успеха или сбоя в CloudFormation. Политика WaitOnResourceSignals на ресурсе Auto Scaling Group заставляет CloudFormation ждать этих сигналов в течение указанного тайм-аута. Если cfn-signal отправляет сигнал сбоя (например, из-за неудачной установки Apache) или не отправляет сигнал до истечения тайм-аута, CloudFormation помечает развертывание как неудачное. Остальные варианты не подходят: Оповещение CloudWatch по метрике UnhealthyHostCount не может напрямую сигнализировать CloudFormation о сбое развертывания. Хук жизненного цикла Auto Scaling предназначен для выполнения действий во время изменения состояния экземпляра, а не для сигнализации CloudFormation о результате выполнения пользовательских данных. Передача логов cloud-init с помощью агента CloudWatch и вызов Lambda для SignalResource является избыточным и более сложным решением, чем прямое использование cfn-signal, которое специально разработано для этой цели.