AWS добавила в CloudFormation новый режим развёртывания, который в отдельных сценариях срезает ожидание с минут до секунд. CloudFormation Express Mode считает операцию завершённой сразу после успешного вызова API на создание, обновление или удаление ресурса, не дожидаясь его полной стабилизации. Для команд, которые постоянно крутят инфраструктуру в dev- и test-средах, это не косметика, а вполне ощутимая экономия часов и нервов.
О нововведении сообщает InfoQ. Смысл у режима простой: если раньше CloudFormation после применения конфигурации ещё ждал, пока ресурс окончательно поднимется, будет готов принимать трафик или корректно удалится, то теперь в express-сценарии этот хвост можно отрезать. AWS не просит переписывать шаблоны, режим работает с существующими возможностями вроде nested stacks и change sets, а включается через AWS CLI параметром --deployment-config '{"mode": "EXPRESS"}'.
Практическая разница у AWS получилась наглядной. Создание очереди SQS вместе с dead-letter queue в стандартном режиме занимает больше минуты, а в express-режиме, по данным компании, укладывается менее чем в 10 секунд. Ещё показательнее пример с удалением Lambda-функции, у которой есть привязанные сетевые интерфейсы: вместо 20-30 минут операция может завершиться за секунды. Это как раз тот класс задержек, который давно раздражал инженеров: конфигурация уже принята, но пайплайн стоит и смотрит на прогресс-бар, словно это обязательный элемент инфраструктурной философии.
Есть, конечно, и цена ускорения. Если CloudFormation Express Mode помечает стек как завершённый сразу после успешного API-вызова, это не означает, что ресурс уже полностью готов к бою. Он может ещё инициализироваться, не обслуживать трафик или, наоборот, продолжать удаляться. AWS это не прячет: режим рассчитан на сценарии, где важна быстрая обратная связь, а не мгновенная эксплуатационная готовность. Если нужен строгий момент, когда после развёртывания можно сразу переключать трафик, запускать полноценные тесты или отдавать среду пользователям, остаётся стандартное поведение со всеми проверками стабилизации.
Почему AWS пошла в эту сторону
В объяснении AWS, которое цитирует principal developer advocate Channy Yun, у режима две основные зоны применения: итеративная разработка и production-сценарии, где команда готова жить с eventual stabilization. В переводе на нормальный инженерный язык это означает следующее: если вы несколько раз в день меняете инфраструктурные параметры, проверяете отдельные компоненты приложения или гоняете инфраструктуру вместе с AI-инструментами, вам важнее получить результат быстро, чем ждать формального статуса «всё стабильно». Особенно это заметно там, где инфраструктура становится частью короткого цикла экспериментов, а не редкой церемонией под релиз.
Отсюда и акцент AWS на AI-assisted infrastructure development. Формулировка спорная, и рынок на неё отреагировал предсказуемо. Yan Cui, AWS Hero и известный специалист по serverless, написал в LinkedIn, что польза для dev-окружений очевидна, но сама идея объяснять новинку прежде всего AI-сценариями выглядит натянутой. Быстрый feedback loop, по его словам, был важен всегда, и именно из-за этого многие инженеры годами предпочитали Terraform, а не CloudFormation. Ирония здесь в том, что AWS подаёт ускорение как удобство для эпохи AI-агентов, хотя жалоба на медлительность CloudFormation появилась задолго до нынешнего витка автоматизации.
Этот контекст для новости, пожалуй, главный. CloudFormation давно воспринимался как мощный, но вязкий инструмент: хорошо интегрирован в AWS, зато нередко заставляет ждать там, где инженер уже мысленно перешёл к следующей задаче. У Terraform в этой истории был не только вопрос синтаксиса или экосистемы провайдеров, но и вполне приземлённое UX-преимущество: меньше ощущения, что инфраструктура специально тормозит процесс. Появление CloudFormation Express Mode выглядит как поздний, но логичный ответ именно на этот многолетний раздражитель, а не только на моду вокруг AI.
Что это меняет для команд
Для разработчиков и платформенных команд новость хороша тем, что AWS не заставляет выбирать между «быстро» и «совместимо». Шаблоны менять не нужно, nested stacks поддерживаются, а если express включён на родительском стеке, он автоматически применяется и к дочерним. Это делает режим удобным для уже существующих инфраструктурных пайплайнов: не нужно заводить параллельную ветку IaC только ради ускорения локальных и тестовых прогонов. Но вместе с этим меняется контракт между инструментом и инженером. Раньше успешное завершение операции в CloudFormation означало не только то, что конфигурация принята, но и то, что сервис, скорее всего, уже в рабочем состоянии. Теперь этот смысл в express-сценарии надо держать в голове отдельно.
Именно здесь начинается зона операционных компромиссов. CTO Archdesk Michał Piszczek отдельно отметил деталь, которую, по его мнению, легко пропустить: rollback в таком сценарии по умолчанию отключён. Для временных стеков, песочниц и автоматических прогонов это терпимо. Для production-инцидента в три часа ночи, когда инфраструктуру потом придётся разбирать человеку, а не агенту, это уже не выглядит таким обаятельным ускорением. Проще говоря, Express Mode не отменяет инженерную дисциплину: если после создания ресурса следующий шаг критичен к его реальной готовности, придётся либо оставаться на стандартном режиме, либо добавлять собственные проверки readiness в пайплайн.
На этом фоне вторая новость от AWS выглядит не менее показательной. Компания расширила преддеплойную валидацию CloudFormation и включила её автоматически для всех операций создания и обновления стеков. Плюс добавлены новые проверки, команда cdk validate для проектов на AWS CDK и возможность отключить валидацию для конкретных деплоев при необходимости. Сочетание тут любопытное: с одной стороны, AWS убирает ожидание после применения конфигурации, с другой — пытается раньше ловить ошибки до того, как начнётся реальное выделение ресурсов. То есть компания одновременно ускоряет цикл и страхует себя от самых грубых промахов.
Для русскоязычной аудитории это выглядит как достаточно практичное обновление без маркетингового тумана. Если у вас AWS-инфраструктура живёт в частых итерациях, много временных сред, внутренние сервисы поднимаются и сносятся десятками раз в день, CloudFormation Express Mode почти наверняка сократит трение. Если же у вас жёсткие требования к моменту готовности, зависимые этапы пайплайна и цена ошибки высока, ускорение может легко превратиться в дополнительную сложность. Главный вопрос теперь не в том, нужен ли режим вообще, а в том, научатся ли команды достаточно чётко разделять «конфигурация применена» и «сервис реально готов». Подробности исходного анонса и реакцию экспертов можно посмотреть в материале .
