早速お試し、新機能のAWS CDKのExpressモードはどれぐらい速いのか？

こんにちは。
アプリケーションサービス本部、DevOps担当の兼安です。

2026年6月末、AWS CloudFormationとAWS CDKのExpressモードがリリースされました。

aws.amazon.com

本機能は「デプロイ時間を最大4倍短縮する」という触れ込みの新機能です。
本記事ではこの新機能をAWS CDKの方に絞って試してみたので、その検証結果を共有します。

本記事では、AWS CDKをCDK、AWS CloudFormationをCloudFormationと記述します。

AWS CDKのExpressモードとは
- テンプレート変更は不要と、ロールバック無効の意味
  - テンプレート変更は不要
  - ロールバック無効
本記事の検証環境と検証内容
実際にデプロイしてみた結果
現状、Expressモードを使うなら開発・検証環境までだろう
まとめ
検証用コード
- AWS CloudFormationにおけるExpress モード

AWS CDKのExpressモードとは

Expressモードは、スタック操作の完了判定を「リソースの設定が適用できた時点」に前倒しするデプロイモードです。

従来のCloudFormation/CDKは、リソースを作成したあとに次のような安定化チェックが終わるまで待ってから、
デプロイ完了と判定していました。

トラフィック準備（traffic readiness）
リージョン伝播（region propagation）
リソースのクリーンアップ（resource cleanup）

Expressモードでは、これらの処理をバックグラウンドに回し、設定が適用できた時点で「完了」とみなします。
その結果、デプロイ時間が高速化するとされています。

テンプレート変更は不要と、ロールバック無効の意味

上述のAWS公式ブログには、「テンプレート変更は不要」と「ロールバック無効」という旨の記述があります。

テンプレート変更は不要

CDKおよびCDKから生成されるCloudFormationのデプロイは「テンプレート（何を作るか）」と「デプロイの指定（どう流すか）」という2段階に分かれます。
Expressモードは後者、つまりデプロイ時の指定であり、テンプレート（CDKコード）側には一切書きません。
つまり、CDKおよびCloudFormation側に特に仕込みは必要なく、Expressモードはデプロイコマンドオプションのみで動く・動かないが決まることを意味します。

ロールバック無効

通常CDKおよびCDKから生成されるCloudFormationのデプロイでは、
デプロイ途中でリソースが1つでも失敗すると、スタック全体を直前の正常な状態に自動で巻き戻します。
失敗しても常に一貫した状態が保たれるわけです。
（正直うまくロールバックされないことも多いですが・・・）。
一方Expressモードは、このロールバックがデフォルトで無効です。
失敗しても巻き戻さず、失敗した地点で止まったまま残ります。

作成・更新が済んだリソースは新しい設定のまま
失敗したリソースとそれ以降は古いまま、または未作成

つまりスタックが「新旧の混ざった中途半端な状態」で残ります。
そのうえでコードを直して再デプロイすると、巻き戻しを待たずに続きから進むため、
「失敗 → 即修正 → 即再デプロイ」を高速に回せる、という開発イテレーション向けの思想です。
Expressモードでも、ロールバックは有効化ができるようですが、Expressモード有効化＋ロールバック有効化については、まだ公式ドキュメントの方に十分な記載がないよう見えるので、本記事では検証の対象外としています。

本記事の検証環境と検証内容

検証はAWS CDK（TypeScript）で行いました。
CDKのバージョンは、CDK CLI（aws-cdk）2.1129.0、ライブラリ（aws-cdk-lib）2.260.0を使用しました（いずれも2026年7月初旬時点の最新）。
また、実案件で書くCDKに近い方が検証の意味が高まると考え、cdk-nag・ESLint/Prettier・Jestも入れています。

CDKスタックの内訳は以下の通りです。
選定理由別に列挙します。

公式ブログで効果が高いと挙げられているリソース群
- Amazon SQS（デッドレターキュー付き）
- AWS Lambda（Amazon VPC内に配置。ENI作成・削除が遅い代表例）
- Amazon SNS
- AWS Systems Manager Parameter Store
一般的なコンテナWebサービス構成に必要なリソース群
- Application Load Balancer
- Amazon ECS（AWS Fargate）
- Amazon RDS

この構成のスタックをExpress有無で流してデプロイ時間を比べてみます。

実際にデプロイしてみた結果

前述のリソース群のCDKスタックを作り、それを通常モード・Expressモード、それぞれでデプロイして時間を計測してみます。
体感速度を重視して、時間はcdk deployコマンドが完了して、返ってくるまでで計測するとします。
cdk deployコマンドが完了して、返ってくるまでなので、諸々オーバーヘッド込みとなります。
したがって、公式ブログの記載とはExpressモードの効果の度合いが異なります。

計測は、1回ではAWS側のプロビジョニング時間のばらつきに左右されるため、3回計測してみました。

なお、Expressモードが本当に有効になっていたかはCloudFormationのスタック情報の「状況の理由」で確認できます。

Stack operation completed using Express Mode. Resources may continue becoming available in the background.

全部入りスタックの新規作成

まず、上述のリソース群を全部含んだスタックをデプロイして計測して見ました。
3回計測の平均は次のとおりです。

複合スタック	通常平均	Express平均	短縮率
新規作成	451.0秒	455.0秒	≒0%（誤差）

各回の計測値は次のとおりです。

複合スタック	通常1	通常2	通常3	Express1	Express2	Express3
新規作成	453秒	478秒	422秒	479秒	438秒	448秒

全部入りスタックの新規デプロイだと、Expressモードの効果は確認できませんでした。

サービス別の単独スタックの新規作成

全部入りスタックで効果が実感できなかったので、サービス別の単独スタックも試してみました。
スタックを分解してサービス別の単独スタックを複数作ってデプロイしています。
3回計測の平均は次のとおりです。

サービス	通常平均	Express平均	短縮率
Amazon SQS（DLQ付き）	83.0秒	56.7秒	31.7%
AWS Lambda（VPC内）	190.3秒	160.3秒	15.8%
Amazon SNS	16.7秒	16.3秒	≒0%
AWS Systems Manager Parameter Store	16.7秒	16.3秒	≒0%
Application Load Balancer	208.7秒	211.3秒	≒0%（誤差）
Amazon ECS（AWS Fargate）	403.0秒	93.7秒	76.8%
Amazon RDS	453.7秒	435.0秒	4.1%

各回の計測値は次のとおりです。

サービス	通常1	通常2	通常3	Express1	Express2	Express3
Amazon SQS（DLQ付き）	83秒	83秒	83秒	51秒	62秒	57秒
AWS Lambda（VPC内）	191秒	190秒	190秒	160秒	161秒	160秒
Amazon SNS	17秒	17秒	16秒	17秒	16秒	16秒
AWS Systems Manager Parameter Store	17秒	16秒	17秒	17秒	16秒	16秒
Application Load Balancer	205秒	211秒	210秒	201秒	206秒	227秒
Amazon ECS（AWS Fargate）	426秒	396秒	387秒	94秒	109秒	78秒
Amazon RDS	446秒	441秒	474秒	425秒	437秒	443秒

今度は効果が実感できましたが、サービスごとにかなり差があるのが確認できます。
差が出たかどうかは、そのサービスにExpressが処理を飛ばせる「安定化の待ちの部分」がどれだけあるかで決まるようです。
こうやって見てみると、全部入りスタックのデプロイ時間は、ほぼRDSに引っ張られているように見えます。
RDSのような所要時間の大半がリソースの実プロビジョニングであるサービスがデプロイ対象に含まれる場合は、Expressモードの効果は薄いと思われます。

そして、よく考えたらスタックをデプロイする時、依存関係を設定しなければリソースは基本並行でデプロイされるので、一番時間がかかるリソースに引っ張られるのは当然ですね。

全部入りスタックにSQS + DLQを追加する更新

単独スタックなら効果が実感できたので、一度デプロイした全部入りスタックにリソースを追加し、結果的に単独スタックのデプロイのような形になった場合どうなるのかも試してみました。
全部入りスタックを新規デプロイした後、SQS + DLQを追加する更新デプロイをかけます。
3回計測の平均は次のとおりです。

全部入りスタックへの更新	通常平均	Express平均	短縮率
SQS + DLQを1セット追加	183.0秒	69.7秒	61.9%

各回の計測値は次のとおりです。

複合スタックへの更新	通常1	通常2	通常3	Express1	Express2	Express3
SQS + DLQを1セット追加	181秒	187秒	181秒	71秒	68秒	70秒

この場合、差分はSQS + DLQだけになるせいか、Expressモードの効果がしっかりと発揮されるようです。
実際の開発においては、初回デプロイ以降に細かな変更が繰り返されるのは頻繁に起きると思われるので、ここに効力を発揮するなら開発プロセス全体の効率化に寄与しそうです。

現状、Expressモードを使うなら開発・検証環境までだろう

私の方では、Expressモードは開発プロセス全体の効率化に寄与しそうですが、現状では使用するのは開発・検証環境までだろうと考えています。
理由は2つあります。
1つはロールバックがデフォルト無効なので、中途半端なリソースができるリスクがあるからです。
ここは、Expressモード有効化＋ロールバック有効化の解像度が高まれば見解は変わるかもしれません。
もう1つは安定化を待たずに完了判定するので、デプロイ完了してもまだトラフィックを捌けない時間が残っている可能性があるからです。

一方で、トライ＆エラーを繰り返すであろう開発・検証環境には、嬉しい機能であり、開発サイクルを効率化するとても良いアップデートだと考えます。

まとめ

AWS CDKでExpressモードを早速試してみたところ、効率化の度合いは、サービスごとにかなり差がありました。
スタックの構成とデプロイの内容により効果は変わり、体感では初回デプロイではあまり効果を感じず、初回デプロイ以降に細かな変更が繰り返す段階では効果を発揮しそうです。
トータルで見ると、開発プロセス全体の効率化に寄与しそうという感触を得ました。
一方で、現状では使用するのは開発・検証環境までだろうと思いました。

今後、Expressモードをさらに使い込んでいき、新たな知見や違う感触が得られたら、また本ブログで紹介したいと思います。