CloudFormation Now Supports Early Validation That Detects Issues Such as Resource Conflicts When Creating Change Sets

In the November 18, 2025 CloudFormation update, there were enhancements: early validation of change sets, and a unique Operation ID assigned to each stack operation.

Amazon CloudFormation accelerates dev-test cycle with early validation and simplified troubleshooting | AWS What's New

This feature detects issues such as resource name conflicts at the creation stage of a change set (Change Set), and blocks the execution itself.

It is a new feature that lets you avoid the "wasted time" of a failed CloudFormation stack update followed by waiting several minutes to tens of minutes for the rollback to complete. This time, I had the chance to actually cause a resource conflict to check the behavior of "early validation" and to try out the usability of the new "Operation ID", so I'd like to share it.

Update Overview

The two main changes this time are as follows.

1. Early Validation
   • When a change set is created (CreateChangeSet), it validates not only syntax errors but also "name conflicts with existing resources in the account" and "emptiness requirements when deleting S3 buckets".
   • If validation fails, the status becomes FAILED and it cannot be executed (Execute).
2. Operation ID
   • A unique ID is assigned to each stack operation (create, update, delete), making it possible to filter the event log.

Test 1: "Early Validation" of Resource Name Conflicts

First, I tried early validation with S3 bucket creation. I'll check whether "resource name duplication", which previously could not be found until provisioning had started, can be detected before deployment.

Test Scenario

1. Stack A: The S3 bucket cfn-test-bucket-alpha has already been created (an existing obstacle).
2. Stack B: Managing the S3 bucket cfn-test-bucket-beta.
3. Action: Update the Stack B template and add cfn-test-bucket-alpha (duplicating Stack A) as a new resource.

Expected behavior:
Conventionally, the change set would be created, and an error would occur when executing the deployment.
If the new feature is enabled, the creation of the change set itself should fail (FAILED).

Preparing the Template

I prepared a template that adds a "bucket with a duplicate name" to Stack B.

AWSTemplateFormatVersion: '2010-09-09'
Description: Add conflicting bucket
Resources:
  # Existing resource
  S3Bucket2:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: cfn-test-bucket-beta-xxxxxx

  # [Added] New resource (its name conflicts with Stack A's existing bucket)
  S3Bucket1:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: cfn-test-bucket-alpha-xxxxxx

Result: Immediate Failure!

I created a change set with the AWS CLI.

aws cloudformation create-change-set \
  --stack-name stack-s3-2 \
  --change-set-name changeset-add-conflict \
  --template-body file://s3-2-add-conflict.yaml

When I checked the status of the created change set... it was Status: FAILED.

Checking the details, the following error message was displayed.

{
    "Status": "FAILED",
    "StatusReason": "The following hook(s)/validation failed: [AWS::EarlyValidation::ResourceExistenceCheck]. To troubleshoot Early Validation errors, use the DescribeEvents API for detailed failure information.",
    "ExecutionStatus": "UNAVAILABLE",
    "Changes": [
        {
            "Type": "Resource",
            "ResourceChange": {
                "Action": "Add",
                "LogicalResourceId": "S3Bucket1",
                "ResourceType": "AWS::S3::Bucket"
            }
        }
    ]
}

You can see that a validation hook called AWS::EarlyValidation::ResourceExistenceCheck is working.
Also, ExecutionStatus is UNAVAILABLE, so the execute button can't be pressed in the first place (no worry of deploying by mistake).

Previously, errors occurred at the stage of actually deploying the change set, but now errors can be identified immediately after creating the change set. This is very efficient.

Test 2: What About IAM Users? (Caveats)

Out of curiosity, I performed exactly the same test (adding a resource that duplicates an existing user name) with an IAM user (AWS::IAM::User).

Result: Not Detected

For the IAM user, the change set status became CREATE_COMPLETE and it passed validation.
After that, when I executed the change set (Execute), it resulted in CREATE_FAILED (AlreadyExists) and a rollback occurred, as before.

Learnings from the Test

The difference in behavior reveals the characteristics of the new feature.

1. Target resources are limited
   It worked with S3 buckets, but IAM users appear to be out of scope at present. Checking the official documentation, it lists AWS::S3::Bucket, AWS::DynamoDB::Table, AWS::EC2::Instance, and others as target resources, but IAM-related resources were not included.

   Validate stack deployments - AWS CloudFormation

2. Behavior on "update (Replacement)"
   In this S3 bucket test I used "new addition (Add)", but in the case of a "rename an existing resource to cause a conflict (Replacement)" pattern, there were cases that slipped past early validation. It seems to work most reliably on the "new creation" path.

Test 3: Narrowing Down Events with Operation ID

This update also includes the introduction of the Operation ID.
For stacks that have been operated for a long time or are updated frequently, the event history becomes huge, and it can be difficult to check the events of a specific deployment.

I confirmed that I can extract the events of a specific deployment by using the newly supported Operation ID.

Test Results

After three updates, when I extracted the OperationId from the event log, I confirmed that a different ID was assigned to each operation.

Extracting Only the Logs of a Specific Operation

If you want to see only the logs of the "third update (Update 3)", simply filtering by this ID completely excludes unrelated past logs.

aws cloudformation describe-stack-events \
  --stack-name stack-s3-1 \
  --query 'StackEvents[?OperationId==`537edc7b-4f7e-48e3-bd4a-xxxxxxxxxxxx`]'

Filtering result:

2025-11-24T12:02:21  UPDATE_COMPLETE
2025-11-24T12:02:19  S3Bucket1 UPDATE_COMPLETE
...
2025-11-24T12:01:53  UPDATE_IN_PROGRESS (User Initiated)

Previously you had to visually follow the logs using the "time" as a guide, but now you can pinpoint the deployment events you want to investigate just by using the Operation ID as a key. It also looks powerful for automated investigation in CI/CD pipelines.

Summary

Until now the cycle was "deploy, wait, fail, wait", but from now on you can "detect errors right after creating the change set", enabling fixes and retries with minimal waiting time.

In particular, I think the benefits of this feature will be large for resource operations where the deployment or rollback itself takes tens of minutes, such as updating CloudFront distributions and rolling updates of EC2 and ECS/Auto Scaling.

Please try incorporating this new feature, "early validation of change sets", into your CI/CD pipelines that update CloudFormation. The Operation ID is also very effective for managing frequently updated stacks, so please make use of it as well.