はじめに

こんにちは。クラウドセントリック株式会社の水田です。2025年6月に入社して、早いもので1年が経ちました。

業務でCloudFormationを使っている中で2026年6月のアップデートで「CloudFormation Expressモード」と「Pre-deployment Validation」という2つの新機能に出会いました。Express modeはデプロイを最大4倍高速化する一方、デフォルトでロールバックが無効化されます。Pre-deployment Validationはプロビジョニング前にエラーを検知する機能ですが、検証範囲は現時点で一部のパターンに限定されています。

では、Pre-deployment Validationの対象外のエラーが、ロールバック無効なExpress mode環境で発生した場合、スタックはどうなるのでしょうか。
作成済みのリソースは残ったままになるのでしょうか。
本記事では、検証対象外であることが分かっているケースを使ってあえてエラーを発生させ、Normal modeとExpress modeでスタックがどのような最終状態になるのかを検証します。

要点

・Pre-deployment ValidationはIAMロールの名前重複のような一部エラーを検知できない
・Express modeはロールバック無効のため、検知漏れの失敗時にスタック操作がCREATE_FAILEDのまま停止し、作成済みのリソースが残る
・「検証を通過した＝安全」ではなく、対象外のケースを踏まえた運用設計が必要

対象読者

・CloudFormation Express modeの導入を検討しているが、ロールバック無効化のリスクをどこまで許容すべきかが知りたい人

必要な前提知識

・CloudFormationの概要、使い方
・CloudFormation Expressモードの概要、使い方
・Pre-deployment Validationの概要、使い方

CloudFormation Expressモードとは

CloudFormation Express modeは、リソースの安定化待ち（伝播確認やクリーンアップなど）を待たずに、設定の適用が確認できた時点でデプロイを完了させる新しいデプロイモードです。これにより、通常最大4倍程度デプロイ時間を短縮できますが、その代わりロールバックがデフォルトで無効化されるため、失敗時の後始末は利用者側で行う前提になります。

Pre-deployment Validationとは

Pre-deployment Validationは、CloudFormationがリソースをプロビジョニングする前にテンプレートを検証する機能です。プロパティの構文エラーや一部リソースの名前競合などを事前に検知できますが、検証対象は現時点で一部のパターンに限定されています。(※)

※AWS公式ドキュメントの「スタックデプロイを検証する」
現在、3 種類の検証がサポートされています: リソーススキーマに対するプロパティ構文の検証、既存のリソースとのリソース名の競合検出、および削除オペレーションの S3 バケット空検証。

試してみた

<検証シナリオ>
(1)Normal modeでこのテンプレートをcreate-stack実行 → RoleOneは作成成功、RoleTwoがEntityAlreadyExistsで失敗 → 自動ロールバックされ、最終的にROLLBACK_COMPLETE、RoleOneも削除される（従来の安全な挙動）
(2)同じテンプレートをExpress mode（–deployment-config ‘{“Mode”:”EXPRESS”}’）でcreate-stack実行
(3)Pre-deployment Validationが「エラーなし」で通過することを確認→ プロビジョニングが進み、RoleTwoで同じく失敗
(4)describe-stacksとdescribe-stack-eventsで最終状態を確認 → ロールバック無効のためCREATE_FAILEDのまま停止し、RoleOneが削除されずに残ることを示す

<検証テンプレート（IAMロール名の重複）>

Resources:
RoleOne:
Type: AWS::IAM::Role
Properties:
RoleName: express-gap-test-role
AssumeRolePolicyDocument:
Version: ‘2012-10-17’
Statement:
– Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: sts:AssumeRole

RoleTwo:
Type: AWS::IAM::Role
Properties:
RoleName: express-gap-test-role # ← わざと同じ名前（コピペミスを想定）
AssumeRolePolicyDocument:
Version: ‘2012-10-17’
Statement:
– Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: sts:AssumeRole
DependsOn: RoleOne

<(1)の検証>
①Stack deployment optionsのExpress modeを「無効」の状態でスタックを実行する。
②describe-stack-eventsの時系列の流れは以下になる。

③IAMロールの一覧で「express-gap-test-role」は作成されていない。
<(2)～(4)の検証>
①Stack deployment optionsのExpress modeを「有効」の状態でスタックを実行する。
②該当のオペレーションIDをクリックし、デプロイの検証タブを見るとバリデーション結果は「エラーなし」で通過することを確認。

③describe-stack-eventsの時系列の流れは以下になる。

④IAMロールの一覧で「express-gap-test-role」は作成されている。

比較表

Pre-deployment Validationはどちらのモードでもエラーを検知できませんでしたが、失敗後の挙動は対照的です。Normal modeでは自動ロールバックによりRoleOneも削除されるのに対し、Express modeではCREATE_FAILEDのまま停止し、RoleOneが残ったままになります。この差が、そのまま復旧作業の手間の差につながります。

まとめ

今回はIAMロールの名前重複という再現性の高いケースを使って検証しました。ただし本質はIAMロール固有の問題ではなく、Pre-deployment Validationの検証対象は現時点で限定的であり、対象外のリソースやランタイム起因のエラーは今後も一定数存在し続けるという点です。Express modeはロールバックが無効化される設計であるため、そうしたすり抜けたエラーは「作成済みリソースが残ったまま」という形で顕在化することになります。

したがって、Express modeを本番環境で採用する際は、「Pre-deployment Validationを通過したから安全」と判断するのではなく、「検証をすり抜けて失敗した場合に、どのリソースが残り得るか」を事前に洗い出した上で、ロールバックを有効化する運用にするか、あるいは失敗時のリソース検知・クリーンアップの仕組みをセットで用意しておくことをおすすめします。
Pre-deployment Validationの検証範囲は今後拡大していくことが予想されます。アップデートがあった際は、改めて本記事の内容を検証し直してみたいと思います。