Stop Waiting for CloudFormation to Tell You Everything's Fine

I was sitting in a standup last month when our DevOps lead mentioned we'd spent 45 minutes waiting for a CloudFormation stack update to complete. The infrastructure change itself took maybe 30 seconds. The rest of the time? CloudFormation running stabilization checks, making sure every resource was fully operational and ready to handle traffic. I remember thinking: do we really need to wait for that every time we're just testing something locally?

Then AWS announced CloudFormation Express mode, and suddenly this problem feels less like an inevitable tax on infrastructure work and more like something we can actually choose to avoid. It's not revolutionary—it's just letting you skip the waiting game when you don't need certainty. But that's the kind of small thing that compounds into real time savings across a development cycle.

What Express Mode Actually Does

CloudFormation has always done stabilization checks after deploying resources. These checks exist for a reason: they make sure your SQS queue can actually receive messages, your Lambda function is callable, your database is accepting connections. In production, that's non-negotiable. You need that confidence before you shift real traffic.

But here's the thing—not every deployment is production. Express mode lets you say: "I don't need you to guarantee everything's stable. Just tell me when the resources are configured and I'll move on." CloudFormation still provisions everything the same way. It still retries transient failures automatically. The only difference is it doesn't wait around for those extended health checks before declaring victory.

The timing improvements AWS mentions are significant. A simple SQS queue with a dead letter queue goes from 64 seconds to 10 seconds. Deleting a Lambda function drops from 20-30 minutes to 10 seconds. But honestly, those numbers undersell the real value—it's the iteration speed that matters. When you're in a feedback loop, even shaving 30 seconds off each deployment compounds into hours saved across a week.

How You Actually Use It

The implementation is refreshingly simple. There's no template changes, no architectural shifts, no new concepts to learn. If you're using the CLI, you just add --deployment-config '{"mode": "EXPRESS"}' to your create-stack or update-stack commands. If you're using CDK, it's literally cdk deploy --express.

Here's what my typical workflow would look like:

# During development iteration
aws cloudformation update-stack \
  --stack-name my-service-dev \
  --template-body file://template.yaml \
  --deployment-config '{"mode": "EXPRESS", "disableRollback": true}'

# Switch back to standard mode for production
aws cloudformation create-stack \
  --stack-name my-service-prod \
  --template-body file://template.yaml \
  --deployment-config '{"mode": "STANDARD", "disableRollback": false}'

The key thing I notice: Express mode disables rollback by default. That's intentional. AWS is saying "we know you're iterating, so if something fails, you'll just fix it and redeploy." In production, you'd re-enable rollback. It's a sensible tradeoff—speed for development, safety for production.

My Take: It's Good, But I Have Questions

I like this feature because it acknowledges something CloudFormation's been missing: the recognition that not all deployments are equal. Development deployments have different requirements than production ones. This is AWS finally giving us the knob to turn.

But I'm cautious about a few things. First, the "automatic retries for transient failures" during background stabilization—I need to understand exactly what gets retried and what doesn't. If my Lambda function fails to attach to an ENI during stabilization, does Express mode retry that automatically or do I need to catch it? The docs are vague here.

Second, I'd want to be really careful about when I enable this in shared environments. Someone deploying in Express mode in a staging environment while someone else is testing against it could cause confusion. You need discipline and clear team norms around which stacks use which mode.

Third, this is perfect for CDK users doing fast iteration, but I wonder how this plays with GitOps workflows where you're managing stack updates through CI/CD pipelines. Do you toggle modes per-environment or per-pipeline stage? That's an operational decision teams will need to think through.

The Bottom Line

This isn't changing how CloudFormation works. It's just letting you trade certainty for speed in the right contexts. For development work and rapid prototyping, that's a huge win. For anything production-facing, you still need the stability guarantees.

The question I'm asking myself: are we using Express mode effectively in our Islamabad team? Are we still running full stabilization checks on development stacks out of habit? If so, we're leaving time on the table.

How do you handle the development vs. production deployment difference in your infrastructure code? Are you also caught in the stabilization wait loop?

Source: This post was inspired by "Accelerate your infrastructure deployments by up to 4x with AWS CloudFormation Express mode" by AWS Blog. Read the original article