AWS CloudFormation Expressモードとは？最大4倍高速化の仕組み・制約と本番適用の判断を実装者目線で解説

IAMのInstanceProfileを1つ作るだけで2分待たされる。CloudFormationでインフラを繰り返し変更していると、テンプレートを書く時間よりもリソースの安定化を待つ時間のほうが長くなります。AWSは2026年6月30日、この待ち時間を切り離す新しいデプロイモードとして、CloudFormation Expressモードの提供を開始しました。

本記事では、Expressモードが完了をどう判定しているのか、有効化にどの版のツールが要るのか、ロールバック既定無効とStackSets非対応という制約が実務にどう跳ね返るのかを、実装者の判断材料として整理します。数値と版番号は2026年8月10日時点で一次情報にあたって確認したものです。

まとめ：Expressモードの要点と本番適用の結論

• 提供状況：2026年6月30日にAWS News Blogで公開。全AWS商用リージョンで利用でき、追加費用はかからない。
• 仕組み：リソース設定を適用するAPI呼び出しが成功した時点で、そのリソース操作を完了とみなす。標準モードのように「EC2インスタンスがrunningになるまで」は待たない。
• 有効化：AWS CLIは --deployment-config に {"mode": "EXPRESS"} を渡す。CDKは cdk deploy --express、SAM CLIは sam deploy --express。テンプレートの書き換えは不要。
• 効果の出方：安定化待ちが長いリソースに限って効く。公式例ではSQSキューが64秒から最大10秒、ENIを持つLambda関数の削除が20〜30分から最大10秒。第三者検証ではEC2とIAM構成が183秒から40秒に縮んだ一方、SQS単体は1分32秒対1分33秒で差が出ていない。
• 制約：ロールバックが既定で無効になり、失敗時はスタックが失敗状態のまま残る。StackSetsは非対応。カスタムリソースは応答シグナルを待つ既定挙動のまま。
• 採用判断：開発・検証環境の反復デプロイには無条件で入れる価値がある。本番は稼働確認を別工程として切り出せている場合に限って採用する。切り戻しを運用手順の柱に据えた本番、デプロイ直後に外部との即時疎通が必要な工程では、既定モードを維持するほうが安全。

Expressモードの動作原理｜安定化待ちを省く完了判定の仕組み

効果を見積もるには、CloudFormationが「完了」をどの時点で宣言しているかを押さえる必要があります。標準モードとの差は1点に集約されます。安定化を待つかどうか、それだけです。

標準モードとExpressモードの完了判定の差｜安定化を待つ範囲

既定の標準モードでは、各リソースが完全に安定した状態に到達するまでCloudFormationが待機し、そこで初めてリソースを完了として報告します。EC2インスタンスの作成なら、インスタンスが running 状態になるまで待つ挙動です。Expressモードは、作成・更新・削除のAPI呼び出しが成功した時点でリソース操作を完了とみなし、最終的な稼働状態への到達を待ちません。

そのため完了直後には、リソースが初期化や変更の伝播を続けている、トラフィックや接続を受け付けられる状態に達していない、削除処理がまだ進行中である、という3つの状態が起こり得ます。テンプレートやリソース定義は一切変わりません。変わるのは報告のタイミングだけで、既存テンプレートをそのまま流せます。前提となるテンプレート構造とスタック操作の基礎はAWS CloudFormationのテンプレートの書き方と使い方に整理してあります。

依存関係の解決順序｜RefとFn::GetAttが担保する実行順

「安定化を待たない」と聞くと、依存関係のあるリソースが壊れるのではという懸念が出ます。ここは仕様で担保されています。テンプレート内で Ref や Fn::GetAtt によって別リソースのIDや属性を参照している場合、CloudFormationは参照先の構成適用を確認したうえで、依存する側のリソース操作を開始する挙動です。

依存リソースが参照先の準備不足に起因する一時的な失敗に遭遇したときは、CloudFormationが操作を再試行します。互いに依存関係のないリソースは並列で進行。つまりExpressモードはリソースの実行順序を変えるものではありません。変えているのは、スタック操作全体をいつ完了と報告するかという1点だけです。ここを取り違えると「依存順が崩れて壊れる」という誤った前提で見送り判断をしてしまいます。

有効化の実装手順｜AWS CLI・CDK・SAM・コンソールでの指定方法

有効化はコマンド引数1つで済みます。ただし引数を認識しないツール版に当たると、不明オプションのエラーで即座に止まります。手順とあわせて必要な版を押さえておきましょう。

AWS CLIでの指定方法｜deployment-configの構文と必要な版

AWS CLIでは、スタック操作コマンドに --deployment-config を追加します。値は {"mode": "EXPRESS"} というJSONで、create-stack、update-stack、delete-stack のいずれにも同じ形で渡せる指定です。マネジメントコンソールから操作する場合は、スタックオプションの設定ステップにあるデプロイオプションで Express を選びます。

注意したいのが必要なCLI版です。--deployment-config はAWS CLI 2.35.13（2026年6月30日公開）で追加されたもので、それ以前の版には引数自体が存在しません。公開されている検証記事では、2.35.6 で「Unknown options: –deployment-config」に遭遇し、2.35.15 へ更新して通ったと報告されています。CI実行環境のCLIを固定版で運用しているなら、更新なしにExpressモードは使えません。

CDKとSAMでの有効化｜expressフラグと設定ファイルへの保存

AWS CDKでは cdk deploy --express でExpressモードが有効になります。CDK側の対応はAWS CDK v2.1129.0（2026年7月1日）で入っており、版が古いと同じくフラグが通りません。CDKとCloudFormationの関係やスタックの扱いはAWS CDKの仕組みとCloudFormation・Terraformとの違いで整理しています。

AWS SAM CLIでは、deploy と sync の両方に --express を付けられます。--save-params を併用すると samconfig.toml に express = true が保存され、以降のデプロイは自動的にExpressモードになる仕組みです。プロジェクト単位で既定化できる一方、同じ設定ファイルを本番デプロイでも読ませている構成では意図せず本番までExpressモードに変わるため、書き込み先の環境設定を確認してください。

変更セットとネストスタックへの伝播｜指定タイミングの落とし穴

変更セットを使う運用でもExpressモードは指定できます。ただしタイミングが決まっています。create-change-set の時点で --deployment-config を渡す必要があり、変更セットを実行する段でCloudFormationが作成時の指定を適用する流れです。実行時に後付けでモードを切り替える設計にはなっていません。

ネストスタックの扱いは素直で、親スタックにExpressモードを指定すると設定が階層内の全ネストスタックへ伝播します。子スタックごとの個別指定は不要。裏を返すと、階層の一部だけを標準モードで慎重に扱うという分割はできません。ネストスタックの中に安定化待ちを厳格に見たいリソースがあるなら、そのリソースをスタック構成から切り離すところから設計を見直します。

デプロイ短縮効果の実測値｜最大4倍が出る条件と効果が出ない構成

「最大4倍」はあらゆるスタックで再現する数字ではありません。公開されている計測値を並べると、効果が出る構成の条件がはっきりします。

公式が示す短縮例｜SQS作成とLambda削除で報告された秒数

AWS News Blogは2つの具体例を挙げています。デッドレターキューを伴うSQSキューの作成は、標準モードの64秒に対してExpressモードでは最大10秒。もう1つはネットワークインターフェースを持つLambda関数の削除で、標準モードの20〜30分に対して最大10秒とされています。

後者の差が極端なのは、ENIのクリーンアップという時間のかかる背景処理を待たなくなるからです。同じ理屈で、CloudFrontのように伝播へ数分かかるリソースほど短縮幅が大きくなります。ただしこの差は「作業が速くなった」のではなく「待ちを後ろへ回した」結果だと読むのが正確な理解です。

第三者検証の計測値｜InstanceProfile待ちが消えた3分の差

第三者の検証記事も数値を公開しています。CDKでの計測（2026年7月2日公開）では、IAMロール、IAM InstanceProfile、セキュリティグループ、EC2インスタンス、IAMポリシーの5リソースを含むスタックで、標準モードの全体183秒に対してExpressモードは40秒。デプロイ工程だけを見ると173秒対31秒で、約5.6倍の差が出ました。短縮の主因は、IAM InstanceProfileの安定化待ちに費やされていた2分11秒が約1秒の完了報告へ置き換わったことです。

別の検証では、CloudFrontとS3の構成が4分3秒から1分2秒へ縮んでいます。一方、同じ記事のSQSとDLQの構成は標準1分32秒に対しExpress 1分33秒で、実質的な差がありませんでした。

短縮効果が出ない構成｜即時生成型のリソースで差が縮まらない理由

同じSQS構成で結果が食い違って見えるのは、待ち時間の内訳が違うためです。SQSキュー自体は即時に生成されるリソースで、安定化待ちがほとんど発生しません。所要時間の大半がスタック操作のオーバーヘッドで占められている構成では、削れる余地がないので差が出ないという結果になります。

見積もりの実務手順はこうなります。標準モードのスタックイベントを時系列で開き、リソースごとのCREATE_IN_PROGRESSからCREATE_COMPLETEまでの間隔を測ります。その合計のうち、IAM InstanceProfile、CloudFrontディストリビューション、ECSサービス、RDSインスタンスのような安定化待ちの長いリソースが占める割合が、Expressモードで削れる上限の目安です。この割合が2割に届かないスタックなら、導入しても体感は変わりません。

制約と失敗時の挙動｜ロールバック既定無効とStackSets非対応

速さの代償は失敗時の挙動に現れます。制約は数として多くありませんが、運用手順の前提を変えるものが含まれています。

ロールバック既定無効の影響｜失敗したスタックが残るときの復旧手順

Expressモードでは、CloudFormationがロールバックを既定で無効にします。リソース操作が失敗しても自動的に変更が巻き戻されません。AWSがこれを既定にした理由は、巻き戻しの完了を待たずに修正して再試行できるようにするためで、反復開発では確かに速い。ただし失敗したスタックは中途半端な状態で残ります。検証記事では、失敗したスタックが CREATE_FAILED のまま残り、手動削除が必要になったと報告されています。

ロールバックを戻すこともできます。--deployment-config に {"mode": "EXPRESS", "disableRollback": false} を渡すと、Expressモードのままロールバックが有効になる設定です。CDKやSAM CLIでは --rollback 系のフラグがデプロイ設定へ反映されます。完了判定の高速化と失敗時の巻き戻しは別の設定であり、片方を捨てずに済む点は設計上の余地として押さえておきたいところです。

非対応機能とカスタムリソース｜StackSets除外と応答待ちの扱い

明確に非対応と書かれている機能は1つです。CloudFormation StackSetsの操作はExpressモードをサポートしません。マルチアカウント・マルチリージョンへの展開をCloudFormation StackSetsによるリソース展開で束ねている環境では、その経路のデプロイが従来どおりの所要時間になります。組織全体の展開速度を縮めたいという動機で検討している場合、期待した箇所には効きません。

カスタムリソースは非対応ではなく、既定の挙動を維持します。AWS::CloudFormation::CustomResource や Custom::* のリソースは、Expressモードでも応答シグナルが返るまでCloudFormationが待ちます。遅いカスタムリソースが反復サイクル全体を止めるのを避けるには、ServiceTimeout プロパティで最大待ち時間を設定してください。

完了報告後に残る背景処理｜疎通確認を切り離す検証工程の設計方針

事故になりやすいのは、デプロイ完了を稼働開始と同一視している既存の自動化です。ユーザーガイドは残り処理の例を挙げています。CloudFrontディストリビューションは設定適用後も世界各地への展開に数分かかる、EC2インスタンスはユーザーデータスクリプトの実行やステータスチェックが続いている、ECSサービスはタスクが起動中で定常状態に達していない、Lambda関数の削除はクリーンアップが継続する、といった状態です。

対処は2段構えになります。まずデプロイ完了と稼働確認を別ステップへ分け、稼働確認側にリソース種別ごとの待機処理を持たせます。ECSサービスならタスクの定常状態、CloudFrontならディストリビューションのデプロイ済み状態を、それぞれのAPIでポーリングして確認する形です。そのポーリングは再実行しても壊れない形へ整えておきます。

本番環境への適用判断｜採用してよい条件と見送るべき場面の線引き

一次情報の記述には微妙なずれがあります。AWS News Blogは反復開発と本番シナリオの両方で最大4倍の短縮と述べる一方、ユーザーガイドは、リソースが完全に安定して稼働していることを確認してから完了とみなしたい本番デプロイには既定モードを使うよう書いています。この食い違いは、判断を運用側へ投げているものと読むのが妥当です。ここでは条件を切って言い切ります。

採用してよい条件｜安定化待ちが支配的になっている開発サイクル短縮

開発環境と検証環境の反復デプロイは、迷わず採用してよい領域です。スタックイベントの実測で安定化待ちが所要時間の2割以上を占めていれば、体感できる短縮が得られます。IAM InstanceProfile、CloudFront、ECSサービス、RDSを含むスタックはこの条件に入りやすい構成。

本番でも、次の2条件を満たすなら採用してよいと判断します。第1に、デプロイ完了後の稼働確認が独立したステップとして存在し、リソース種別ごとの待機処理を持っていること。第2に、障害時の一次対応が「切り戻し」ではなく「前進修正」で回せる体制になっていることです。この2つが揃っている組織では、ロールバック既定無効がむしろ復旧を速めます。IaCを組織へどう定着させるかという上位の設計はIaC（Infrastructure as Code）の仕組みと導入判断で整理しています。

見送るべき場面｜切り戻しを前提にした本番と即時疎通が必要な工程

見送るべき場面をはっきり挙げます。変更失敗時にロールバックで元の構成へ戻すことを運用手順の柱に据えている本番環境では、Expressモードを採用しません。disableRollback を false に戻せば形式上は使えますが、その構成で速くなる部分は安定化待ちの省略だけになり、失敗時に中途半端な状態を踏むリスクだけが残ります。得るものと失うものが釣り合いません。

もう1つは、デプロイ直後に外部システムとの疎通が必須になる工程です。決済や外部API連携の切り替えをデプロイの一部として扱っているパイプライン、リリース直後に手動の受け入れ確認が入る工程では、完了報告と稼働のずれが誤った判定を生みます。「本番だから使わない」ではなく「切り戻し前提か、即時疎通が必要か」で線を引きます。

CI/CDでの併用設計｜環境ごとにデプロイモードを切り替える運用

現実的な着地点は、全面採用でも全面見送りでもなく環境別の切り替えです。パイプライン変数としてデプロイモードを外出しし、開発・検証はEXPRESS、本番は既定モードという既定値をリポジトリ側に固定します。SAMを使う場合は samconfig.toml の環境ごとのセクションへ書き分け、本番セクションに express = true が入らないようレビュー観点へ加えておきましょう。

あわせて、CLIとCDKの版をパイプライン側で固定する必要があります。AWS CLIは2.35.13以降、AWS CDKはv2.1129.0以降でなければフラグが通らず、実行環境によって挙動が変わる状態は避けたいところです。デプロイ経路の設計や既存パイプラインの見直しは、リソース種別ごとの待機処理の実装まで含めると工数が読みにくい領域になります。AWSのインフラ構築とIaC整備をまとめて任せたい場合は、インフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。

よくある質問

Expressモードの導入検討で論点になりやすい5点を、仕様と一次情報の記述に沿って回答します。

ECS Express Modeと同じ機能ですか？

別の機能です。Amazon ECS側にもExpress Modeという名前の機能があり、こちらはコンテナアプリケーションの公開手順を簡素化する提供形態を指します。本記事で扱うCloudFormation Expressモードは、スタック操作の完了判定を変えるデプロイモードで、対象も指定方法も異なります。名前が近いため検索結果に混在しますが、ECS側の記事に --deployment-config の情報は出てきません。

Expressモードの利用に追加料金はかかりますか？

追加費用は発生しません。AWS News Blogは、全AWS商用リージョンで追加費用なしに利用できると明記しています。ただし短縮されるのはCloudFormationの待ち時間であり、作成されるリソース自体の料金は変わりません。デプロイ回数が増えれば、その分のリソース稼働料金は積み上がります。

既存テンプレートの書き換えは必要ですか？

不要です。Expressモードは既存のCloudFormationテンプレートすべてで動作し、テンプレート側の変更を求めません。変更セットやネストスタックといった既存機能もそのまま使えます。切り替えはコマンド引数、コンソールのデプロイオプション、あるいはCDKやSAM CLIのフラグだけで完結。

本番環境で使ってよいですか？

条件付きで使えます。ユーザーガイドは、リソースが完全に安定してから完了とみなしたい本番デプロイには既定モードを推奨しています。判断基準は2つ。デプロイ完了後の稼働確認を独立ステップとして持っているか、障害時の一次対応が前進修正で回るか。両方満たさない本番では既定モードを維持してください。

–deployment-configがUnknown optionsになるのはなぜですか？

AWS CLIの版が古い可能性が高いところです。--deployment-config はAWS CLI 2.35.13（2026年6月30日公開）で追加された引数で、それより前の版には引数自体が存在しません。CDKで --express が通らない場合も同様で、AWS CDK v2.1129.0以降が必要です。まずは実行環境の版を確認してください。

関連記事

• AWS CloudFormationとは？テンプレートの書き方から使い方までわかりやすく解説：Expressモードの前提となるテンプレート構造とスタック操作の基礎を確認できます。
• AWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違い：cdk deployにフラグを足す前に、CDKとCloudFormationの関係を押さえられます。
• AWS SAMとは？CloudFormationとの違い・CLIの使い方をわかりやすく解説：SAM CLIでExpressモードを既定化する際の設定ファイルの位置づけがわかります。
• CloudFormation Linter（cfn-lint）とは？ツールの概要・機能と特徴を詳しく解説：ロールバック既定無効の環境で、失敗を事前に減らすテンプレート検証を確認できます。
• プロビジョニングとは？サーバー・ユーザー・クラウドの種類と自動化(IaC)の判断まで実装者向けに解説：リソース払い出しの自動化範囲を決める観点をまとめています。