AWS CloudFormation Express Mode: 4x Faster Deploys and What It Actually Changes

If you've ever sat through a create-stack that takes two minutes to provision an SQS queue with a dead-letter queue, or watched a delete-stack hang for 20+ minutes because a Lambda function still has an ENI attached, you already know CloudFormation's biggest complaint isn't the DSL — it's the wait. AWS shipped a fix for that on June 30, 2026: Express mode, a new deployment option that can cut stack operation time by up to 4x. It works with your existing templates, no rewrites required.

This post covers how to actually turn it on across the CLI, CDK, SAM, and the console, what "faster" really means under the hood, and the rollback behavior that will bite you if you skip the docs.

Why CloudFormation deploys are slow in the first place

In the default deployment mode, CloudFormation doesn't consider a resource "done" when the API call to create/update/delete it succeeds — it waits for the resource to reach a fully stabilized state. For an EC2 instance, that means waiting for running. For a Lambda function with a VPC-attached ENI, deletion means waiting for AWS to actually tear down the network interface, which can take 20-30 minutes on its own.

That stabilization wait is what makes iterative development painful: you tweak one property, redeploy, and wait minutes for a change that AWS accepted in seconds.

How Express mode works

Express mode changes when the stack operation reports complete, not how resources are provisioned. Once CloudFormation confirms your resource configuration was applied (the API call succeeded), it considers the operation done — it doesn't wait for the resource to finish stabilizing in the background.

Concrete numbers from AWS's own benchmarks:

Dependency ordering is unaffected — if resource B references resource A via Ref or Fn::GetAtt, CloudFormation still confirms A's configuration is applied before starting B, and independent resources still run in parallel. Express mode just removes the "wait for full stabilization" tax on top of that.

Enabling Express mode

You don't need to touch your templates. Just pass the deployment config at the tool you already use.

AWS CLI — add --deployment-config:

 1aws cloudformation create-stack --stack-name my-app \
 2    --template-body file://template.yaml \
 3    --deployment-config '{"mode": "EXPRESS"}'
 4
 5aws cloudformation update-stack --stack-name my-app \
 6    --template-body file://template.yaml \
 7    --deployment-config '{"mode": "EXPRESS"}'
 8
 9aws cloudformation delete-stack --stack-name my-app \
10    --deployment-config '{"mode": "EXPRESS"}'

Change sets work the same way — specify the deployment config at creation, and it applies when you execute the change set:

1aws cloudformation create-change-set --stack-name my-app \
2    --change-set-name my-change-set \
3    --template-body file://template.yaml \
4    --deployment-config '{"mode": "EXPRESS"}'

AWS CDK:

1cdk deploy --express

AWS SAM:

1sam deploy --express
2sam sync --express
3
4# persist it so you stop typing the flag
5sam deploy --express --save-params

The --save-params flag writes express = true into samconfig.toml so every subsequent sam deploy in the project uses Express mode automatically.

Console: in the stack creation/update wizard, go to Configure stack options → Deployment options and select Express.

Nested stacks: set Express mode on the parent stack and it propagates automatically to every nested stack in the hierarchy — you don't set it per nested stack.

The rollback gotcha

This is the part that will surprise you in a bad way if you skim past it: Express mode disables automatic rollback by default. If a resource operation fails mid-deploy, CloudFormation leaves the stack in its partial state instead of rolling back.

That's a deliberate trade-off for fast local iteration — rolling back costs time, and if you're redeploying every 30 seconds anyway, a failed resource is something you'll just fix and redeploy over. But it's the wrong default for anything you'd call production. Re-enable rollback explicitly when it matters:

1aws cloudformation create-stack --stack-name my-app \
2    --template-body file://template.yaml \
3    --deployment-config '{"mode": "EXPRESS", "disableRollback": false}'

For SAM, the --disable-rollback flag controls this same setting within the deployment config.

What doesn't work with Express mode

• StackSets are not supported at all. If you're deploying across multiple accounts/regions via StackSets, Express mode isn't an option there.
• Custom resources ignore Express mode. AWS::CloudFormation::CustomResource and Custom::* resources still follow default behavior — CloudFormation waits for the resource's response signal regardless of deployment mode. If a custom resource is slow or gets stuck, it will still block your fast iteration loop. Set ServiceTimeout on it so a hung custom resource fails fast instead of hanging your Express-mode deploy indefinitely.

Express mode vs. CDK hotswap — don't confuse the two

If you've used cdk deploy --hotswap, Express mode looks similar on the surface (both make CDK deploys faster) but they work completely differently:

The practical rule: hotswap is a shortcut that skips CloudFormation entirely and can leave your stack's actual state out of sync with the template — never use it against a stack anyone else depends on. Express mode keeps CloudFormation as the source of truth the whole time, so it's safe to use more broadly, including in some production scenarios where eventual stabilization is acceptable.

Best practices

• Use Express mode by default in dev/sandbox accounts. There's no cost difference, and the iteration speedup is real.
• Keep rollback enabled in anything shared — CI pipelines that deploy to staging or prod, and any stack other engineers depend on. Set disableRollback: false explicitly rather than relying on defaults.
• Set ServiceTimeout on every custom resource you own, Express mode or not — it's the one resource type Express mode can't speed up for you.
• Don't chain a smoke test immediately after an Express-mode deploy without a readiness check. The stack operation reporting "complete" doesn't mean an ECS service has reached steady state or a CloudFront distribution has finished propagating globally — build in an explicit wait/poll for resource-level readiness if your pipeline depends on it.

Common mistakes to avoid

• Assuming "complete" means "operational." An EC2 instance stack update can report Express-mode success while the instance is still running its user-data script. If your next pipeline step immediately hits the instance, it may not be ready yet.
• Using Express mode with StackSets and wondering why it's ignored. It's explicitly unsupported — check the docs before assuming a flag "just doesn't do anything."
• Leaving rollback disabled in a shared environment. A failed Express-mode deploy to a shared staging stack with rollback off leaves other engineers debugging a half-applied stack that isn't obviously broken.
• Forgetting --save-params in SAM projects, then having teammates deploy without Express mode enabled and wondering why their iteration loop is slower than yours.

Troubleshooting

"My delete-stack still takes a long time even with Express mode." Check whether the slow resource is a custom resource — those ignore Express mode entirely and wait for their response signal. Also confirm you actually passed --deployment-config '{"mode": "EXPRESS"}' on the delete call itself; Express mode is set per-operation, not per-stack.

"A resource failed and my stack is stuck in a weird partial state." That's expected default behavior — Express mode disabled rollback. You'll need to manually fix or remove the failed resource and redeploy, or re-run the operation with disableRollback: false going forward.

"CDK hotswap was already fast, why switch to Express mode?" Because hotswap doesn't touch CloudFormation at all, which means your stack's recorded state can drift from what's actually deployed. If you've ever had a cdk deploy (without hotswap) undo a hotswap change unexpectedly, that's the drift catching up with you. Express mode doesn't have that failure mode.

FAQ

Does Express mode cost anything extra? No. It's available in all AWS commercial Regions at no additional cost — you pay for the resources you provision, same as always.

Do I need to change my CloudFormation templates to use Express mode? No. It works with all existing templates unmodified, including change sets and nested stacks.

Is Express mode safe for production? It can be, for scenarios where you're comfortable with eventual resource stabilization — but re-enable rollback explicitly (disableRollback: false) for anything production-facing, since the default is rollback-off.

Does Express mode change resource provisioning order? No. Dependency ordering via Ref and Fn::GetAtt is respected exactly as in standard mode; only the definition of "operation complete" changes.

Can I use Express mode with StackSets? No, StackSets operations don't support Express mode.

Key takeaways

Further Reading

• Create Public and Private VPC With VPC Flow Logs Using CloudFormation
• Create VPC and Private/Public Subnet Using CloudFormation
• GitHub Actions Checkout v7: Fixing the Pwn Request Vulnerability Before July 16
• AWS CloudFormation Express Mode official docs
• AWS News Blog: Accelerate your infrastructure deployments by up to 4x with AWS CloudFormation Express mode