I have watched a CloudFormation deploy fail at minute nine because I misspelled a property, and I have quietly made peace with the fact that this is a rite of passage for anyone shipping IaC. AWS just removed one of those rites. In a June 30 post on the AWS DevOps blog, the CloudFormation team extended pre-deployment validation to run automatically on every stack operation, not only on change sets. If your team ships small updates through direct CreateStack and UpdateStack calls, the safety net that used to appear only when you explicitly asked for a preview now shows up by default.
This is one of those quiet infrastructure changes that only reveals its value the third or fourth time your CI does not spend fifteen minutes rolling back a stack that never should have started.
What the CloudFormation team shipped
Validation used to be a change-set exclusive. You called CreateChangeSet, waited, reviewed the preview, then decided whether to execute. In the new behaviour, CreateStack and UpdateStack also run the same synchronous checks before the stack transitions into IN_PROGRESS. Two tiers are involved.
The FAIL tier stops the operation before any resource is touched. It covers property syntax errors and resource name conflicts, the class of mistakes where a stack cannot possibly succeed but the platform previously discovered that only after it had started creating siblings and had to unwind them.
The WARN tier reports issues without blocking. Service Quota limits, AWS Config Recorder conflicts, and ECR repository delete readiness fall in that tier. WARN results are only surfaced on CreateChangeSet, which is a design choice worth calling out: the direct create/update path is fail-fast, the change-set path stays advisory. If you rely on change-set previewability, that gap matters.
Everything runs in every AWS Region where CloudFormation is supported. There is no opt-in.
Where you will feel this on a real pipeline
For a CI job that runs cdk deploy on a merge to main, this trims off the failures that hurt the most: the ones where you find out at minute seven that a logical ID collides with an existing resource, and your rollback costs another five minutes on top. Those are the failures that erode trust in the pipeline, because they arrive after the coffee.
The tighter feedback also matters for anyone letting an AI agent drive CloudFormation on their behalf. An agent that wrote a template with a bad property name used to get a green API response and a slow, opaque failure later. Now the API returns quickly with a specific error, which is the exact signal an agent needs to correct its own draft. AWS mentions agent-driven pipelines alongside human operators when it frames the change.
For local iteration, the story is smaller but genuine: the new cdk validate command runs the same set of checks against a synthesized template without deploying. If you have ever synthesized, eyeballed the output, deployed, and then wondered which of your three recent edits broke it, this is the missing step in the loop.
Turning it on, off, and reading what it found
You do not need to enable anything. It runs. If you need to bypass it for a specific operation, the CLI carries a new flag:
aws cloudformation create-stack \
--stack-name <stack-name> \
--template-body file://<template>.yaml \
--disable-validation
aws cloudformation update-stack \
--stack-name <stack-name> \
--template-body file://<template>.yaml \
--disable-validation
The results, both FAIL and WARN, land in the stack event stream, which you read with DescribeEvents or the console. For pipelines that already tail events, no change is required. For pipelines that parse them, expect new event kinds.
Rough edges worth knowing before you rewrite runbooks
Three things are worth flagging.
First, WARN only exists on CreateChangeSet. If your team standardized on direct CreateStack for speed, you lose the soft warnings entirely. Service-quota exhaustion, the classic Friday-afternoon EIP surprise, still ambushes direct-path teams unless you keep a change-set step in front.
Second, --disable-validation is per operation, not global. That is the right default, but it means somebody, somewhere, will bake it into a CI helper script the first time a legacy stack refuses to update, and forget to remove it. The escape hatch is easy to reach and easy to leave open.
Third, the current list of checks is documented for today but will grow. AWS has a habit of quietly adding validators. If your CI treats validation output as noise and disables it, you inherit whatever new blast radius the next check would have prevented.
How other IaC tools answer the same question
Every major IaC tool has an answer to "catch it before it starts." They just place it at different spots in the loop.
-
Terraform puts the check in
terraform plan. It is not a hard gate at apply time by default, but the plan output is the canonical review artifact and most CI setups block a merge without a green plan. - Pulumi runs a preview step conceptually equivalent to a change set, with the added upside that the language runtime catches type errors at compile time. If you want the strongest possible pre-deploy signal, a real type system does it best.
-
Azure Bicep / ARM ships
az deployment what-if, which is Microsoft's counterpart to the change-set question and is genuinely well documented. If you live in Azure, this is already the pattern you know. -
Google Deployment Manager has a
--previewflag on updates that surfaces a similar preview object. - Crossplane validates through Kubernetes admission controllers, which is a different shape entirely: the check happens at API server time, before the composition ever reconciles.
The honest read: AWS closed one of the gaps that made CloudFormation feel a step behind newer IaC tooling, without asking you to change how you deploy. The default path is now the safer path, and for most teams the default path is the one they actually use.
What I am watching next
Two things. Whether AWS extends the WARN tier into direct CreateStack and UpdateStack, because the current split is the sharpest edge in the release. And whether cdk validate becomes a primitive other tools can invoke, so that a pre-commit hook in a monorepo can call it without spinning up a full synth pipeline. If you try it on your own stacks this week, I would love to hear where it caught you, and where it politely did not.
Top comments (0)