ECS デプロイの待ち時間を242秒から47秒まで短縮してみた
はじめに
ECS のデプロイ周りや、これを支える CloudFormation・CDK が2026年7月に入り、立て続けに変わりました。Express モードの GA、Action Logs の追加、CDK の --express オプション対応など、デプロイ速度に直結するアップデートが続いています。先日の AWS Summit Japan 2026 でも、ECS のアップデートや最適化手法を紹介するセッションがありました。
Express モード自体の動作詳細は以前の記事にまとめています。
本記事では、これらの一部を評価環境で試し、ECS Fargate のデプロイ時間をどこまで短縮できるかを計測しました。
検証内容
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| VPC | vpc-xxxxxxxxx（デフォルト VPC） |
| ワークロード | Spring Petclinic (ARM64) |
| タスク数 | 2（マルチ AZ） |
| CPU / メモリ | 512 / 1024 MiB |
| コンテナイメージ | ECR プライベートリポジトリ（キャッシュ済み） |
| デプロイサーキットブレーカー | 有効 |
計測方法:
- デプロイ発火: タスク定義のイメージタグ
v1↔v2を切り替え（同一イメージ、タグ違い） - ツール完了時間: コマンド実行開始〜完了の wall clock 時間（bash の
SECONDS変数で計測） - ECS デプロイ時間:
describe-service-deploymentsのstartedAt→finishedAt - Action Logs:
SERVICE_DEPLOYMENT_IN_PROGRESS→SERVICE_REVISION_STABLE→SERVICE_DEPLOYMENT_SUCCESSFULタイムスタンプ - 各パターン 3 回計測し平均を算出（Phase 5 のみ計測条件の都合で有効1回、参考値として記載）
検証パターン概要
| # | パターン | 変更点（Phase 1 との差分） | 本番利用 |
|---|---|---|---|
| 1 | CFn 通常 + デフォルト | — | ○ |
| 2 | CFn 通常 + チューニング | ECS パラメータ最適化 | ○ |
| 3 | CFn Express + チューニング | + Express モード（安定化待ちスキップ） | △（安定化確認を別途実装する場合） |
| 4 | CDK Express + チューニング | + CDK 経由 Express（TaskDefinition 切り出し不要） | △（同上） |
| 5 | CDK hotswap + チューニング | CFn バイパス（SDK 直接呼び出し） | ✗（dev/test 専用） |
結果サマリー
| # | パターン | ツール完了 (平均) | Phase 1 比 | 本番利用 | 安定化待ち |
|---|---|---|---|---|---|
| 1 | CFn 通常 + デフォルト | 242秒 (≈4.0分) | ベースライン | ○ | あり |
| 2 | CFn 通常 + チューニング | 222秒 (≈3.7分) | -8% | ○ | あり |
| 3 | CFn Express + チューニング | 61秒 (≈1.0分) | -75% | △ | なし（別途確認要） |
| 4 | CDK Express + チューニング | 47秒 (≈0.8分) | -81% | △ | なし（別途確認要） |
| 5 | CDK hotswap + チューニング | 109秒 (≈1.8分) ※参考値 | -55% | ✗ | あり |
高速化の内訳は大きく3つのステップに分かれます。
- ECS パラメータチューニング (Phase 1→2): ECS デプロイ自体を -14% 短縮。ただし CFn のポーリング間隔に律速されるため、ツール完了時間は -8% に留まる
- CFn Express モード (Phase 2→3): CFn 安定化待ちスキップで Phase 2 比 -73%（Phase 1 比 -75%）。ECS デプロイはバックグラウンドで進行
- CDK Express (Phase 3→4): CDK のスタックイベント即時検知で Phase 3 比 -23%。TaskDefinition 切り出し不要
※ Phase 5（hotswap）は CFn バイパスによる参考計測であり、上記3ステップとは別方式です。
Phase 1: ベースライン計測
デフォルト設定のパラメータ:
| パラメータ | 値 |
|---|---|
| DeregistrationDelay | 300秒 |
| HealthCheckIntervalSeconds | 30秒 |
| HealthyThresholdCount | 5 |
| MinimumHealthyPercent | 100% |
| MaximumPercent | 200% |
| HealthCheckGracePeriod | 60秒 |
| Run | イメージ | ツール完了 | ECS デプロイ | CFn オーバーヘッド |
|---|---|---|---|---|
| #1 | v1→v2 | 242秒 | 141秒 | 101秒 |
| #2 | v2→v1 | 242秒 | 130秒 | 112秒 |
| #3 | v1→v2 | 243秒 | 116秒 | 127秒 |
| 平均 | — | 242秒 | 129秒 | 113秒 |
コンテナ起動の内訳です。ボトルネックではないため、以降はデプロイフロー側に注目します。
| タスク | created → pullStart | pull 時間 | pull → started |
|---|---|---|---|
| Task A | 14秒 | 5秒 | 14秒 |
| Task B | 13秒 | 4秒 | 17秒 |
ECR からの pull は 4〜5秒で完了しており、キャッシュ済みイメージではコンテナ起動自体は高速でした。
Action Logs で Run #1 のタイムライン:
| イベント | タイムスタンプ (UTC) | デプロイ開始からの経過 |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 08:47:01 | 0秒 |
| SERVICE_REVISION_STABLE | 08:47:37 | 36秒 |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 08:49:21 | 140秒 |
SERVICE_REVISION_STABLE（36秒）から SERVICE_DEPLOYMENT_SUCCESSFUL（140秒）まで約104秒かかっています。この区間が旧タスクの Deregistration Delay を含む安定化待ちです。ツール完了242秒のうち ECS デプロイが129秒、残る113秒が CFn のポーリングや状態確認のオーバーヘッドで、デプロイ時間のほぼ半分が CFn 側の処理でした。
Phase 2: ECS パラメータチューニング
以下のパラメータを変更しました。DeregistrationDelay で旧タスクのドレイン待ちを短縮し、HealthCheck の間隔・閾値で新タスクの正常判定を早めています。また、MinimumHealthyPercent で新旧タスクの入れ替えを並列化する狙いです。
| パラメータ | 変更前 | 変更後 |
|---|---|---|
| DeregistrationDelay | 300秒 | 5秒 |
| HealthCheckIntervalSeconds | 30秒 | 10秒 |
| HealthyThresholdCount | 5 | 2 |
| MinimumHealthyPercent | 100% | 50% |
| Run | イメージ | ツール完了 | ECS デプロイ | CFn オーバーヘッド |
|---|---|---|---|---|
| #1 | v2→v1 | 242秒 | 121秒 | 121秒 |
| #2 | v1→v2 | 182秒 | 93秒 | 89秒 |
| #3 | v2→v1 | 242秒 | 119秒 | 123秒 |
| 平均 | — | 222秒 | 111秒 | 111秒 |
Action Logs で Run #1 のタイムライン:
| イベント | タイムスタンプ (UTC) | デプロイ開始からの経過 |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 09:09:19 | 0秒 |
| SERVICE_REVISION_STABLE | 09:10:03 | 44秒 |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 09:11:19 | 120秒 |
REVISION_STABLE → DEPLOYMENT_SUCCESSFUL 間は76秒で、Phase 1 の104秒から短縮されました。ECS デプロイ時間は平均111秒で Phase 1 比 -14% でした。ただし Run #1・#3 のツール完了時間は242秒で Phase 1 と同値です。CFn のポーリング間隔（約60秒）に律速されるため、ECS デプロイが早く終わっても次のポーリングまで待たされる形です。Run #2 のみ、ECS デプロイ完了直後にポーリングが実行されたため182秒に短縮されました。
Phase 3: CloudFormation Express モード
Express モードの動作詳細は以下の記事を参照してください。
Express モードでは TaskDefinition の Replacement（新リビジョン作成による置き換え）を伴う更新が扱えませんでした。そのため、TaskDefinition を CFn テンプレートの管理外に切り出しています。Service リソースの TaskDefinition プロパティはパラメータ経由で ARN を受け取る設計にしました。
Parameters:
TaskDefinitionArn:
Type: String
Description: Task Definition ARN (managed outside this stack)
Resources:
ECSService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: !Ref TaskDefinitionArn
# DeploymentConfiguration, NetworkConfiguration 等は省略
Express モードでのデプロイコマンドです。
aws cloudformation update-stack \
--stack-name ecs-deploy-bench \
--use-previous-template \
--parameters ParameterKey=TaskDefinitionArn,ParameterValue=arn:aws:ecs:ap-northeast-1:123456789012:task-definition/petclinic:9 \
--deployment-config '{"Mode":"EXPRESS"}'
| Run | TaskDef Rev | ツール完了 |
|---|---|---|
| #1 | rev 9 | 62秒 |
| #2 | rev 8 | 61秒 |
| #3 | rev 9 | 61秒 |
| 平均 | — | 61秒 |
Phase 1 比 -75% でした。Express モードは ECS デプロイの安定化完了を待たずにスタック更新完了を報告します。
Action Logs で Run #1 のタイムラインを確認しました。Express モードではツール完了と ECS デプロイ完了のタイミングが異なるため、ツール完了時点を基準に示します。
| イベント | タイムスタンプ (UTC) | ツール完了からの経過 |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 09:40:37 | ツール完了前 |
| SERVICE_REVISION_STABLE | 09:41:06 | ツール完了前 |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 09:42:35 | +約58秒 |
ツール完了時点で ECS デプロイはまだ IN_PROGRESS 状態であり、SERVICE_DEPLOYMENT_SUCCESSFUL はツール完了後にバックグラウンドで記録されます。
Phase 4: CDK Express モード（本命）
CDK での Express モード実行コマンドです。
cdk deploy --express --force
CDK は Replacement 型の更新（TaskDefinition 新リビジョン作成）を内部で処理するため、Phase 3 で必要だったテンプレート設計変更が不要です。
| Run | イメージ | ツール完了 |
|---|---|---|
| #1 | v2→v1 | 47秒 |
| #2 | v1→v2 | 47秒 |
| #3 | v2→v1 | 47秒 |
| 平均 | — | 47秒 |
Phase 1 比 -81%、CFn Express（61秒）比 -23% でした。Phase 3 では aws cloudformation wait のポーリング間隔分の待ちが含まれます。一方、CDK はスタックイベントをストリームで監視するため完了を即時検知でき、その分のオーバーヘッドが削減されます。Phase 3 と同様に安定化待ちはスキップされます。
Phase 5: CDK hotswap（参考）
hotswap は CFn をバイパスし、SDK で直接 update-service を呼び出すモードです。ドリフトが発生するため連続計測は困難であり、有効な計測は1回のみです。
| Run | イメージ | ツール完了 | 備考 |
|---|---|---|---|
| #1 | v2→v1 | 109秒 | 安定化待ちあり |
| #2 | v1→v2 | 9秒 | CFn ドリフト検出で即失敗（除外） |
代表値は Run #1 の109秒（Phase 1 比 -55%、参考値）です。
- hotswap は CFn をスキップするが、ECS 安定化を待つため Express モード（47秒）より遅い
- 次回通常デプロイ前にドリフト解消が必要
- 本番非推奨（dev/test 専用）
まとめ
今回の検証では、タスク定義リビジョンをスタック外で登録し、ECS Service が参照するタスク定義を切り替える形でデプロイを発火しました。この経路では、Deregistration Delay やヘルスチェック設定などのチューニングにより、ECS デプロイ時間を平均129秒から111秒へ短縮できました。
ただし、CloudFormation 通常モードでは ECS デプロイの安定化完了を待つため、ECS 側の短縮効果はツール完了時間にそのまま現れませんでした。
一方、CloudFormation Express モードと CDK の --express オプションは、IaC 管理を維持したまま待機時間を短縮できる選択肢です。今回の評価環境では、通常の CloudFormation デプロイが242秒、CDK Express が47秒となり、ツール完了までの待ち時間を約81%短縮できました。
Express モードでは、スタック更新完了と ECS デプロイの安定化完了は別のタイミングになります。そのため、CloudFormation の成功だけでデプロイ成功と判断せず、ECS 側のデプロイ状態も確認する必要があります。
ECS Action Logs、コンソールのリアルタイムデプロイ可視化、デプロイサーキットブレーカーの設定拡張が利用できます。待機を省略した後もデプロイの進行状況・成否・失敗時の挙動を把握しやすくなっています。
開発・テスト環境など、安定化完了を待つことよりも早いフィードバックを優先したい場面では、Express オプションは有力な選択肢です。まずは評価環境で、ECS デプロイの確認方法とセットで試してみてください。
