On 30 June, AWS shipped Express mode for CloudFormation and the CDK. The headline number is that infrastructure deployments run up to 4x faster. A SQS queue with a dead-letter target that used to take 64 seconds now completes in up to 10. Deleting a Lambda function wired into a VPC — the kind of operation that could stall for 20 to 30 minutes while elastic network interfaces detached — also drops to roughly 10 seconds. It is available today in all commercial regions, at no additional cost, and you turn it on without touching your templates.
Read as a speed release, that is a nice quality-of-life win. But I do not think that is what this is. I think AWS just built its first deploy loop designed around an AI agent, not a person, and the design choices give the game away.
What “faster” actually means here
Express mode does not make provisioning faster. The underlying resources take exactly as long as they always did to become real. What changed is the definition of “done.”
In standard mode, CloudFormation waits for stabilization: it confirms the resource is not just created but ready — traffic-serving, propagated across the region, cleaned up on delete. Express mode declares the deployment complete the moment the resource configuration is applied, and lets the rest settle in the background with automatic retries for transient failures. And it disables rollback by default, so a failed change does not unwind the whole stack — it just stops, and you fix and retry.
So the speed is not really speed. It is a shorter feedback loop. You find out whether your change was accepted in seconds instead of minutes, and if it was wrong, you correct it and go again immediately, with no rollback penalty in between.
That is an agent’s edit cycle, exactly
Here is the part worth sitting with. Sub-second-to-sub-minute feedback, plus fix-and-retry with no rollback tax, is not how a human operator works. A human batches changes, reviews a plan, deploys deliberately, and treats a rollback as a safety net worth waiting for. The slow, stabilizing, auto-reverting path is built for the way people want to deploy: cautiously, with guarantees.
The tight loop — apply, observe, correct, repeat, dozens of times a minute if you want — is how an agent works. It is the same edit-run-fix cycle I watch my own agents run against code, moved down into the infrastructure layer. An agent does not need a rollback to feel safe; it needs to know, right now, whether the last action landed, so it can decide the next one. Express mode gives it precisely that: a machine-paced iteration loop where the cost of being wrong once is near zero because you can be right on the next attempt three seconds later.
I do not think that framing is an accident. cdk deploy --express and a {"mode": "EXPRESS", "disableRollback": true} deployment config are the ergonomics of a tool that expects a program, not a person, to be pressing the button.
The tradeoff is the same feature list, read backwards
Everything that makes Express mode good for agent iteration makes it dangerous in production, and it is the identical set of properties — just viewed from the other side.
No stabilization guarantee means the deployment reports success before the resource is actually ready to serve traffic. In a dev loop, fine — you are about to change it again anyway. In production, “the stack succeeded” no longer means “the system is ready,” and anything downstream that trusts that signal — a health gate, a promotion step, the next stage of a pipeline — can now proceed against infrastructure that is still settling.
Rollback off by default means a failed change leaves you in a partially-applied state instead of the last known-good one. For an agent mid-iteration, that is the point: it does not want to lose its progress to an automatic revert. For a production change at 2am, the automatic revert was the plan, and its absence is how you get a half-migrated stack and no clean floor to stand on.
None of this is a flaw. It is a correctly-made tradeoff for one context that happens to be exactly wrong for the other. The mistake would be letting the default leak across the boundary — running your prod deployments the way your agents run their sandbox because the flag was convenient and nobody drew the line.
What I am doing about it
Three things, from the seat of someone running agents against real AWS accounts.
Treat Express mode as a dev-and-agent-loop tool, explicitly. It belongs in the fast inner loop — an agent iterating on a stack, a developer roughing out infrastructure — and I want that decision written down, not left to whoever last edited the deploy command. The activation should be scoped to those environments, not inherited.
Keep stabilization and rollback for anything customers touch. Production deployments should still pay the minutes and keep the safety net. The whole value of the slow path is the guarantee, and the guarantee is worth more than the speed exactly where the speed is least needed.
Do not let an agent’s success signal gate a human’s promotion. If an agent-driven Express deployment feeds a pipeline, the “done” it reports is weaker than the old “done.” Any step that used to assume a completed stack was a ready system needs an explicit readiness check now, or the weaker signal silently propagates.
The tell worth noticing
The specific feature is small. What it signals is not. When a cloud provider starts shipping the default behaviour of its most foundational service — how you deploy infrastructure at all — reshaped around a machine-paced iteration loop, that is a provider designing for a world where the thing holding the controls is increasingly an agent.
That is the direction of travel, and Express mode is an early, honest instance of it: genuinely useful, clearly built for the agent case, and carrying a tradeoff that only stays safe if you know which loop you are in. The work, as usual, is not adopting the feature. It is drawing the line between the loop where its defaults are a gift and the loop where they are a liability — and making sure nobody crosses it by accident.