Я заметил, что если шаблон содержит пользовательскую лямбда-форму ресурса, которая не работает (возникает ошибка времени выполнения или неправильно отправляется тело ответа), тогда стек CloudFormation зависает на этапе создания этого конкретного ресурса.
Когда вы пытаетесь принудительно удалить стек - он зависает на том же пользовательском ресурсе (потому что он вызывает ту же лямбду при удалении и получает ту же ошибку).
Для получения состояния «DELETE_FAILED» требуется 1 час, после чего вы можете принудительно удалить стек, игнорируя эту ошибку, с помощью пользовательской лямбды ресурса.
Мой вопрос: можно ли как-то избежать или уменьшить эту огромную (1 час) задержку?
И разве такое поведение не является ошибкой CloudFormation? Потому что, с моей точки зрения, если пользовательская лямбда завершилась ошибкой, ждать нет смысла.
Я не думаю, что есть способ. Однако есть несколько вещей, которые вы можете иметь в виду при разработке собственных ресурсов, чтобы этих проблем можно было избежать с самого начала.
Проверять, выписываться https://aws.amazon.com/premiumsupport/knowledge-center/best-practices-custom-cf-lambda/ для передового опыта разработки пользовательских ресурсов.
Другое дело - провести модульные тесты перед развертыванием. Я в основном пишу лямбда-функции на C # и всегда выполняю модульное тестирование перед развертыванием. А это довольно просто.
Здесь вы можете найти образец лямбда-выражения для пользовательских ресурсов: https://github.com/turjachaudhuri/CF-custom-resources