A AWS anunciou em 30 de junho o CloudFormation Express mode, um novo modo de deploy para CloudFormation e CDK que promete reduzir o tempo de operações de infraestrutura em até quatro vezes, segundo a empresa. O AWS News Blog explica que o modo expresso conclui a operação quando o CloudFormation confirma que a configuração dos recursos foi aplicada, sem esperar todas as verificações prolongadas de estabilização.
No modo padrão, um deploy de CloudFormation continua acompanhando a estabilização dos recursos depois que a configuração foi enviada. Isso é útil quando a equipe precisa confirmar que a infraestrutura está pronta para receber tráfego ou sustentar testes imediatamente. No CloudFormation Express mode, a operação termina mais cedo e os recursos seguem estabilizando em segundo plano.
A nota de disponibilidade da AWS apresenta o recurso como uma resposta a ciclos de iteração em desenvolvimento, CDK e ferramentas de IA que constroem infraestrutura incrementalmente. A empresa afirma que não é preciso alterar templates existentes: o modo entra por parâmetro de deploy, pela AWS CLI, SDKs, console, change sets ou pelo comando cdk deploy --express.
Neste artigo
O que muda no tempo de feedback
O ganho principal está no retorno mais rápido para quem está ajustando infraestrutura. Se a pilha precisa criar recursos em sequência, esperar a estabilização completa a cada pequena mudança pode travar a iteração. A AWS usa exemplos como criação de filas, funções Lambda e recursos com propagação longa para mostrar que o tempo percebido pelo desenvolvedor pode cair bastante.
Isso importa também para agentes de IA. Um agente que altera infraestrutura precisa de feedback frequente para planejar o próximo passo. Se cada tentativa fica presa em estabilização longa, a automação perde ritmo e tende a acumular estados intermediários difíceis de interpretar. Com o modo expresso, o ciclo de criar, observar erro de configuração e corrigir fica mais curto.
O que não muda no provisionamento
A AWS reforça que o modo expresso muda o momento em que a operação é considerada concluída, não a forma como os recursos são provisionados. Dependências continuam sendo processadas pela pilha, e recursos que precisam de mais tempo continuam avançando depois do retorno da operação. O deploy não vira instantâneo; ele passa a separar aplicação de configuração e estabilização completa.
Essa distinção é importante para times brasileiros que usam CloudFormation como contrato de produção. Se uma aplicação depende de um endpoint global, propagação de CDN, anexo de rede ou disponibilidade imediata de um recurso, terminar o deploy mais cedo pode dar uma leitura otimista demais para o pipeline. Nesse caso, testes de prontidão, health checks e observabilidade precisam assumir o papel que antes ficava embutido na espera do CloudFormation.
Rollback precisa entrar na decisão
Um detalhe operacional é crítico: o CloudFormation Express mode desabilita rollback por padrão para acelerar a iteração. A documentação em português da AWS sobre opções de falha de pilhas indica que, nesse cenário, a pilha pode permanecer em estado de falha para correção e nova tentativa, em vez de reverter automaticamente todos os recursos já provisionados.
Em ambiente de desenvolvimento, isso pode ser desejável. O time vê o erro, ajusta o template e tenta de novo sem esperar uma reversão demorada. Em produção, a mesma escolha pode deixar recursos parciais, custos temporários ou dependências em estado inesperado. A AWS permite configurar disableRollback como false no parâmetro deployment-config, e essa decisão deveria ser explícita em pipelines críticos.
Como usar sem perder controle
O primeiro uso seguro é em pilhas pequenas ou ambientes de desenvolvimento, onde falha parcial não derruba tráfego real. O segundo é em componentes isolados, como uma fila, uma função ou um recurso que não recebe usuário imediatamente. O terceiro é em loops assistidos por IA, desde que o agente tenha limites de conta, região, custo e permissões.
Para pipelines de produção, o modo expresso pede uma camada adicional de verificação. O deploy pode terminar antes de um recurso estar plenamente operacional, então o pipeline precisa medir disponibilidade, alarmes, erros e rollback de aplicação fora do CloudFormation. O post sobre runners self-hosted do GitHub Actions conversa com essa ideia: velocidade de automação só ajuda quando a base operacional continua previsível.
Quando evitar o modo expresso
Evite o recurso quando a pilha executa mudanças grandes, difíceis de desfazer ou dependentes de propagação externa que precisa terminar antes do próximo passo. Também é melhor manter o modo padrão quando uma equipe ainda não tem observabilidade suficiente para detectar falha parcial depois que a operação retorna sucesso.
O CloudFormation Express mode é uma ferramenta para encurtar o feedback de infraestrutura, não uma dispensa de governança. Em times maduros, ele tende a funcionar melhor como opção de iteração controlada, com rollback, permissões, custos e checks explícitos por ambiente.
