CloudFormationで変更セット作成時にリソース競合などを検出する早期検証が可能になりました

2025年11月のアップデートで、CloudFormationに変更セットの早期検証機能とOperation IDが追加されました。変更セット作成段階でS3バケット名などのリソース競合を検知し、デプロイ失敗とロールバックの待ち時間を回避できるか検証しました。

suzuki.ryo

2025.11.24

2025年11月18日の CloudFormation アップデートで、変更セットの早期検証 と、スタック操作ごとに一意の Operation ID が付与される機能強化がありました。
Amazon CloudFormation accelerates dev-test cycle with early validation and simplified troubleshooting | AWS What's New
これは、変更セット (Change Set) の 作成段階 でリソース名の競合などを検知し、実行自体をブロックしてくれる機能です。
CloudFormation のスタック更新に失敗し、ロールバック完了まで数分〜数十分待たされる...そんな「虚無な時間」を回避できる新機能です。 今回、実際にリソース競合を発生させて「早期検証」の挙動を確認するとともに、新しい「Operation ID」の使い勝手を試す機会がありましたので、紹介します。
 アップデート概要今回の主な変更点は以下の2つです。
早期検証 (Early Validation)
変更セット作成時 (CreateChangeSet) に、構文エラーだけでなく「アカウント内の既存リソースとの名前競合」や「S3バケット削除時の空要件」などを検証します。
検証に失敗するとステータスが FAILED になり、実行 (Execute) できません。

Operation ID
スタック操作（作成・更新・削除）ごとに一意の ID が付与され、イベントログをフィルタリングできるようになりました。

 検証1：リソース名競合の「早期検証」まず、S3バケットの作成で早期検証を試してみました。 これまではプロビジョニングが走り出してからでないと判明しなかった「リソース名の重複」を、デプロイ前に検知できるか確認します。
 検証シナリオStack A: S3バケット cfn-test-bucket-alpha を作成済み（既存の障害物）。
Stack B: S3バケット cfn-test-bucket-beta を管理中。
アクション: Stack B のテンプレートを更新し、新規リソースとして cfn-test-bucket-alpha (Stack Aと重複) を追加する。
期待する挙動:

従来であれば、変更セットは作成され、デプロイ実行時にエラーになります。

新機能が有効であれば、変更セットの作成自体が失敗 (FAILED) するはずです。
 テンプレートの準備Stack B に「名前が重複するバケット」を追加定義したテンプレートを用意しました。
AWSTemplateFormatVersion: '2010-09-09'
Description: Add conflicting bucket
Resources:
  # 既存のリソース
  S3Bucket2:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: cfn-test-bucket-beta-xxxxxx

  # 【追加】新規リソース（Stack Aの既存バケットと名前を被らせる）
  S3Bucket1:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: cfn-test-bucket-alpha-xxxxxx
 結果確認：即座に失敗！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
作成した変更セットの状態を確認すると... Status: FAILED となっていました。
詳細を確認すると、次のエラーメッセージが表示されています。
{
    "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"
            }
        }
    ]
}
AWS::EarlyValidation::ResourceExistenceCheck という検証フックが動作していることがわかります。

また、ExecutionStatus が UNAVAILABLE となっており、そもそも実行ボタンが押せない（誤ってデプロイする心配がない） 状態になっていました。
これまでは変更セットを実際にデプロイする段階でエラーが発生していましたが、変更セットを作った直後にエラーが判別できるようになりました。これは非常に効率的です。
 検証2：IAMユーザーの場合は？（注意点）気になったので、IAMユーザー (AWS::IAM::User) でも全く同じ検証（既存ユーザー名と重複するリソースを追加）を行ってみました。
 結果：検知されなかったIAMユーザーの場合は変更セットのステータスが CREATE_COMPLETE になり、検証を通過してしまいました。

その後、変更セットを実行 (Execute) すると、従来どおり CREATE_FAILED (AlreadyExists) でロールバックが発生しました。
 検証からの学びこの挙動の違いから、新機能の特性が見えてきました。
対象リソースは限定的

S3バケットでは動作しましたが、IAMユーザーは現時点では対象外のようでした。公式ドキュメントを確認すると、対象リソースとして AWS::S3::Bucket, AWS::DynamoDB::Table, AWS::EC2::Instance などが挙げられていますが、IAM関連は含まれていませんでした。
Validate stack deployments - AWS CloudFormation
「更新(Replacement)」時の挙動

今回のS3バケット検証では「新規追加(Add)」で行いましたが、「既存リソースの名前を変更して競合させる(Replacement)」パターンの場合、早期検証をすり抜けるケースがありました。「新規作成」のパスで最も確実に動作するようです。
 検証3：Operation ID によるイベントの絞り込み今回のアップデートにはもう一つ、Operation ID の導入が含まれています。

長期間運用していたり、頻繁に更新が行われるスタックでは、イベント履歴が膨大になり、特定のデプロイのイベントを確認するのが大変なことがあります。
今回サポートされた Operation ID を利用して、特定のデプロイイベントを抽出できることを確認してみました。
 検証結果3回の更新後、イベントログから OperationId を抽出してみると、操作ごとに異なるID が付与されていることが確認できました。


回数
タイムスタンプ
付与された Operation ID


Update 1
12:00:15
73e9f432-ca34-40c4-b113-xxxxxxxxxxxx

Update 2
12:01:00
b96fe23c-83a2-4647-83c9-xxxxxxxxxxxx

Update 3
12:01:46
537edc7b-4f7e-48e3-bd4a-xxxxxxxxxxxx

 特定の操作ログだけを抽出する「3回目の更新（Update 3）」のログだけを見たい場合、この ID でフィルタリングするだけで、関係ない過去のログを完全に除外できます。
aws cloudformation describe-stack-events \
  --stack-name stack-s3-1 \
  --query 'StackEvents[?OperationId==`537edc7b-4f7e-48e3-bd4a-xxxxxxxxxxxx`]'
フィルタリング結果:
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)
これまでは「時刻」を目安にログを目視で追う必要がありましたが、これからは Operation ID をキーにするだけで、調査対象のデプロイイベントをピンポイントで特定できます。CI/CD パイプラインでの自動調査などでも威力を発揮しそうです。
 まとめこれまでは「デプロイして、待機、失敗して、待機」サイクルでしたが、これからは「変更セットを作った直後にエラーを検知」でき、最小限の待ち時間で修正、再試行が可能になります。
特に、CloudFront ディストリビューションの更新や、EC2、ECS/Auto Scaling のローリングアップデートなど、デプロイやロールバック自体に数十分単位の時間がかかるリソース操作において、この機能の恩恵は大きくなると思われます。
CloudFormation を更新する CI/CDパイプラインに今回の新機能「変更セットの早期検証」を組み込み、ぜひ活用してみてください。また、Operation ID も頻繁に更新されるスタック管理には非常に有効です。こちらも併せてご活用ください。

CloudFormationで変更セット作成時にリソース競合などを検出する早期検証が可能になりました

アップデート概要

検証1：リソース名競合の「早期検証」

検証シナリオ

テンプレートの準備

結果確認：即座に失敗！

検証2：IAMユーザーの場合は？（注意点）

結果：検知されなかった

検証からの学び

検証3：Operation ID によるイベントの絞り込み

検証結果

特定の操作ログだけを抽出する

まとめ

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

回数	タイムスタンプ	付与された Operation ID
Update 1	12:00:15	`73e9f432-ca34-40c4-b113-xxxxxxxxxxxx`
Update 2	12:01:00	`b96fe23c-83a2-4647-83c9-xxxxxxxxxxxx`
Update 3	12:01:46	`537edc7b-4f7e-48e3-bd4a-xxxxxxxxxxxx`