CloudFormation Express mode ships, returning success before resources are ready

For years a CloudFormation stack operation has stayed IN_PROGRESS until every resource in it stabilized. On July 2 AWS shipped Express mode, a deployment configuration that has CloudFormation report the stack complete as soon as resource configuration is applied, with resources continuing to become available in the background. Rollback is off by default in the new mode. The trade-off is explicit in the announcement on the AWS DevOps blog: you get a faster signal, and you accept a weaker one.

The completion signal, moved forward

Express mode does not change how CloudFormation talks to service APIs. It changes when it reports done. In the default mode the stack sits IN_PROGRESS while each resource stabilizes, the period between the configuration call succeeding and the resource being ready to serve traffic. Under Express mode CloudFormation flips the resource to a completion status as soon as the configuration call returns. Per the announcement, the status message is now literal about what that means: "It may continue becoming available in the background."

Dependencies inside the stack are still respected. Transient failures still retry. The mode changes the finish line, not the race.

Where the time comes from

The example AWS puts forward is CloudFront. The post says Express mode "turns a 5-10 minute CloudFront deployment into a sub-minute confirmation." Most of that wait is edge propagation the caller cannot influence from the API side. On resource types where stabilization is the long pole (CDN distributions, managed database clusters, some IAM propagation delays), Express mode skips a wait you were never going to shorten from outside.

The subtle claim underneath is that the wait was pure toil. For a developer iterating on a template, that is usually right. For a pipeline whose next step assumes the resource is actually serving traffic, it is not. That is where the operational read gets interesting.

Turning it on

The knob lives at deployment-config time. Nothing inside the template changes. The announcement is emphatic on that point: "No template changes. No new resource types."

Direct API call via the CLI:

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

CDK and SAM ship native flags:

cdk deploy --express
sam deploy --express

Change sets accept the same shape at create-change-set time and carry the configuration through to execution. Enabling Express mode on a parent stack propagates it to every nested stack automatically.

The rollback question

One line in the announcement is the one to read twice: "Express mode disables rollback by default for faster iteration." Rollback can be turned back on with "disableRollback": false on the deployment config, or with cdk deploy --express --rollback. If nobody puts it back, the semantics you had in classic mode are gone. A failed update no longer walks itself back to the last good state. It stops where it stopped, and an operator gets to reconcile the delta.

For a developer running cdk deploy in a personal account, that is exactly the trade to make. In production the calculation is different. The pipeline signalled success while the resource was still stabilizing. If the resource then fails to stabilize, there is no automatic path back, and any downstream step gated on the stack outcome (smoke tests, cache warming, canary traffic shift) fires against an environment that CloudFormation itself is not sure about.

The mitigation is not hard. Turn rollback back on for anything past dev. Add an explicit stabilization step in the pipeline where a downstream action depends on the resource actually being live, whether that is a targeted aws ... wait call, a health probe, or a canary. The point worth internalizing is that the default is faster, and the default is what people ship.

How other tools draw the same line

Every declarative infrastructure tool eventually meets this fork between "configuration accepted" and "resource ready." Terraform's apply generally blocks until each provider considers the resource created, which for slow services is the same wait CloudFormation just cut; Pulumi behaves the same way by default. Kubernetes clients have lived with the split for a decade: kubectl apply returns as soon as the API server accepts the manifest, and a caller who wants "ready" reaches for kubectl rollout status or a readiness probe. Argo CD and Flux ship synced as the default reported state and expose healthy as a separate condition on purpose, because the two events are not the same.

Read against that neighbourhood, Express mode is CloudFormation catching up to a convention the Kubernetes side has treated as normal. The novelty is not the pattern. It is that a stack operation no longer means the same thing on both sides of a flag, and the change is a runtime setting the operator picks, not a property of the template committed to the repo.