Back to Blog
AWS Cloud Infrastructure DevOps CI/CD

AWS CloudFormation Express Mode: 4x Faster Deploys, and Where the Old Path Still Wins

CloudFormation Express mode cuts deploy time up to 4x by skipping stabilization. Where it fits (CI, preview stacks) and where we keep the default mode.

AWS CloudFormation Express Mode: 4x Faster Deploys, and Where the Old Path Still Wins

You change one line in a template, run cdk deploy, and then you go get coffee. The stack sits there churning while CloudFormation waits on a Lambda’s network interface to fully detach, or a queue to finish propagating, or some resource to report itself “stable.” On a tight iteration loop (tweak, deploy, check, repeat) that dead time adds up fast. In our client work, it’s one of the most common complaints we hear about the CDK loop, and it’s a big part of why AWS-native tooling can feel like it taxes you.

On June 30, 2026, AWS shipped a direct answer to that gripe: CloudFormation Express mode. It finishes a stack operation the moment your resource configuration is applied, up to 4x faster on AWS’s internal benchmarks, and lets the resources finish coming online in the background. It’s a real improvement, but easy to point at the wrong workload. Here’s how it works and where we’d draw the line.

What Express mode actually changes

In the default deployment mode, CloudFormation doesn’t just apply your configuration. It waits for each resource to stabilize first: an EC2 instance has to reach running, a distribution has to finish propagating, a deleted resource has to finish cleaning up, all before the operation reports success. Those waits are why some resources are shockingly slow to create or delete even when the change itself is trivial.

Express mode skips that waiting. The operation reports complete as soon as the create, update, or delete API call for each resource succeeds, and the slower work of propagating and cleaning up continues afterward in the background. AWS’s published figures show the gap (these are AWS’s own numbers; we haven’t independently reproduced them):

  • Creating an SQS queue with a dead-letter queue: the default mode takes 64 seconds, Express completes in up to 10 seconds.
  • Deleting a Lambda function with an attached network interface (the classic VPC-Lambda cleanup that drags on forever): the default mode takes 20 to 30 minutes, Express completes in up to 10 seconds.

That second one is the headline. If you’ve ever watched a VPC-connected Lambda stack hang for half an hour on DELETE_IN_PROGRESS, you know how much friction that removes from ephemeral environments.

Express mode works with your existing templates (no rewrite), and with nested stacks and change sets. Enable it on a parent stack and the setting propagates to every nested stack below it. It’s available in all commercial AWS Regions at no additional cost.

There’s a caveat the launch framing skips, though. “Works with all your existing templates” is true of the template, but two things limit where the speedup actually lands. StackSets aren’t supported with Express mode, so cross-account and cross-Region StackSet operations stay on the default path. And custom resources still block. Any AWS::CloudFormation::CustomResource or Custom::* resource keeps waiting for its response signal before the operation completes, even under Express, so a custom-resource-heavy template sees far less than the advertised 4x. Cap that exposure with the ServiceTimeout property so a slow or stuck custom resource can’t stall the loop.

Turning it on

For raw CloudFormation, you pass a deployment config when you create, update, or delete a stack (or create a change set). The --deployment-config flag needs a recent AWS CLI (the parameter landed in 2.35.13); update first if create-stack rejects the option:

aws cloudformation create-stack \
  --stack-name preview-api \
  --template-body file://template.yaml \
  --deployment-config '{"mode": "EXPRESS", "disableRollback": false}'

For CDK, it’s a single flag:

cdk deploy --express

The --express flag is new enough that it may not be in your installed CDK CLI yet, so update the CLI if it isn’t recognized.

disableRollback is set to false above on purpose. Omit it and Express turns rollback off for you, because rollback is disabled by default. That default is the part to understand before you use this anywhere real.

The catch: Express disables rollback by default

Express mode turns off automatic rollback by default. In the default mode, a failed deploy rolls the stack back for you. A failed update returns to the last good state; a failed create winds the new resources back out to ROLLBACK_COMPLETE, which you then delete before retrying. That automatic rollback is genuinely one of CloudFormation’s best features. It isn’t magic, though. Rollback can itself fail (an UPDATE_ROLLBACK_FAILED stack needs its own recovery with continue-update-rollback), so treat it as a strong safety net, not a guarantee. Terraform, for its part, doesn’t roll back automatically at all; there the recovery path is fix and re-apply. Express trades that safety net away for speed. On failure the stack stops where it is and you fix and retry, without waiting on a rollback that could take minutes of its own.

For fast iteration that’s the right trade. When you’re redeploying a throwaway preview stack twenty times an hour, automatic rollback on every failed attempt is pure overhead; you were going to redeploy anyway. On a production stack, though, “stopped in a partially-updated state with rollback off” is precisely the situation you built CloudFormation to protect you from.

Set disableRollback back to false and you keep Express’s config-applied speed while restoring rollback (for CDK, cdk deploy --express --rollback does the same). That’s a reasonable middle setting. There’s a second, subtler caveat that no flag fixes, though. Express reports success before resources are verified operational. The configuration is applied, but the resource may still be coming online. A CloudFront distribution, for instance, reports complete under Express yet can still take several minutes to finish propagating to the edge, so the distribution exists before it’s actually serving. If your pipeline’s next step assumes the thing is live (routing production traffic, running smoke tests against a new endpoint, flipping a DNS record) you can race ahead of reality. AWS’s own guidance is explicit. If you need resources fully operational before you proceed, use the default deployment mode.

One thing Express doesn’t loosen is dependency order. It still applies resources in the order your Ref and Fn::GetAtt references imply, and if a dependent resource hits a transient failure because a dependency isn’t ready yet, CloudFormation retries it. You’re getting earlier completion, not a free-for-all.

Where we’d flip it on, and where we wouldn’t

AWS positions Express for two cases: iterative development, and production workloads where you’re comfortable with eventual stabilization. Our default recommendation is more conservative than that second half, and it’s worth being clear that the caution is ours, not AWS’s. In our experience the “eventual stabilization is fine here” call is easy to get wrong under deadline pressure and expensive when it’s wrong, so we treat Express as a dev and CI-loop tool by default and opt specific production cases in. The split we’d actually run:

Turn Express on for:

  • Ephemeral and preview environments. Per-PR stacks, feature-branch infra, anything you spin up and tear down constantly. The VPC-Lambda teardown improvement alone pays for itself here.
  • The inner development loop. A developer iterating on a stack locally with cdk deploy --express, where a broken deploy just means fix and retry, not an incident.
  • CI pipelines that provision then destroy. Integration-test infrastructure that lives for the length of a job. Faster create and faster delete compounds across every run.
  • AI agents provisioning infrastructure. One of AWS’s stated motivations. An agent iterating on infra benefits from the same tight loop a human does, and ephemeral agent-provisioned stacks are exactly the low-stakes case Express fits.

Keep the default deployment mode for:

  • Most production deploys. You usually want automatic rollback, and you want “success” to mean the resource is actually serving. This is a default, not an absolute. A production stack that only creates something with no real stabilization window, an IAM role or an S3 bucket, has little to lose from Express.
  • Anything you can’t cleanly re-provision. Stateful resources, databases, anything where a partially-applied change is expensive to unwind by hand.
  • Pipeline stages whose next step depends on a resource being live. Traffic shifts, post-deploy verification, DNS cutovers. Config-applied is not the same as ready.

In practice we encode it as policy. Express in your non-prod pipelines and local workflows, and the default mode (rollback on) gated for main and production. The same template deploys both ways.

Does this change the IaC decision?

A little. In our Terraform vs. AWS CDK vs. CloudFormation framework, one honest mark against the CloudFormation and CDK side has always been deploy speed. Terraform’s plan and apply loop felt snappier, and in our client work slow stabilization waits come up often as a reason teams lean Terraform. Express narrows that gap without giving up CloudFormation’s managed state and native rollback (when you leave rollback on). It doesn’t erase the other reasons you might choose Terraform, like multi-provider reach, the clarity of plan, and an explicit state model, but “CloudFormation is too slow to iterate on” is a much weaker argument since Express shipped on June 30.

If you’re a CDK user, it’s worth not conflating Express with cdk deploy --hotswap. Hotswap skips CloudFormation entirely and calls service APIs directly, which is why it’s fast but only covers a limited set of resource types (Lambda, ECS, Step Functions, and a few others) and can leave your stack state drifting from the template. Express still goes through CloudFormation, so it works with any resource type, keeps stack state consistent with the template, and keeps rollback available (off by default) where hotswap has none. Hotswap patches a running resource; Express speeds up a real deployment.

It also pairs with how you structure deployment automation. If you’re driving stacks through a pipeline, the kind we walk through in Automating Cloud Deployments with GitHub Actions, S3, and CloudFront, Express is a per-environment setting you toggle in the deploy step, not a template change. And if you’re weighing where serverless and managed infra fit in the first place, the same “match the tool to the blast radius” instinct from Serverless vs. Traditional Servers applies here. Fast and loose for the ephemeral, careful and verified for the things you can’t afford to get wrong.

The takeaway

Express mode fixes a real, specific pain, the slow-deploy tax on iteration. Use it where speed matters and failure is cheap, like preview stacks, CI jobs, the inner dev loop, and agent-provisioned infra. Keep the default deployment mode where correctness matters more, on production, stateful resources, and any step that assumes a resource is live. The rollback and readiness trade-offs are exactly what make it fast, so the real call, made per stack, is whether you can live with them.

Sorting out which deploy paths, environments, and IaC tooling fit your team, and where the fast path is safe, is the kind of architecture call we make with clients every week. Talk to us if you’d like a second set of eyes on yours.

Sources / last verified 2026-07-28: Accelerate your infrastructure deployments by up to 4x with AWS CloudFormation Express mode (AWS News Blog, June 30, 2026) · Deploy AWS CloudFormation stacks faster with express mode (AWS CloudFormation User Guide) · How CloudFormation express mode accelerates your development cycle (AWS DevOps Blog, July 2, 2026) · AWS CloudFormation and CDK express mode speeds up infrastructure deployments by up to 4x (AWS What’s New).

Back to Blog