はじめに
Linear で本番トラフィックを 10% ずつ、6 分おきに切り替えると (API の既定値の場合)、待機時間だけで約 54 分かかります。その間、「いま何割まで進んだのか」「止まって見えるのは、フックの待ちなのか、失敗なのか」を、どこで確かめればよいでしょうか。
2026 年 9 月 21 日、AWS は Amazon ECS コンソールのデプロイ可観測性が、ECS ネイティブの Linear・Canary・Blue/Green に対応したと発表しました。デプロイの進捗、ヘルス、失敗の原因を、「Deployments」タブでまとめて確認できるようになるアップデートです。
本記事は、公式発表と ECS デベロッパーガイド、AWS CLI リファレンスの記載をもとにまとめました。発表にある「現在のライフサイクルステージ」の例が、ドキュメント上のどのステージに当たるのかも整理しています。
何が変わったのか
Before / After は次のとおりです。
| Before | After | |
|---|---|---|
| 進捗の確認 | 段階的なデプロイの進み具合を、ECS コンソールのほかに、たとえば CloudWatch のアラーム、ロードバランサーのターゲットグループのヘルス、CloudTrail のイベントなどを、それぞれ別に見て確かめる必要があった | 「Deployments」タブのライブタイムラインに、デプロイの各フェーズ、サービスイベント、タスクの起動・終了の進捗が出る。ソースとターゲットのリビジョン間のトラフィックの分布と、現在のライフサイクルステージ (グリーンタスクのスケールアップ中、フックの待機中、ベイクタイム中など) も同じ画面にある |
| 健全性の確認 | サーキットブレーカー、アラーム、ヘルスチェックの情報が、別々の画面に分かれていた | サーキットブレーカーの状況、デプロイアラームの状態、コンテナとロードバランサーのヘルスチェック、ライフサイクルフックの状態が、タイムラインと並ぶ |
| 失敗時の調査 | タスクの状態、イベント、ログ、ロードバランサーの状態などを横断して調べる必要があった | 失敗したタスクがタイムライン上に診断情報つきで出て、AWS CloudTrail などへのディープリンクから原因を追える |
| コスト | ー | 追加料金なし。全 AWS コマーシャルリージョンと AWS GovCloud (US) で利用できる |
この機能が出たのは、今回が初めてではありません。2026 年 7 月 1 日に、まずローリングアップデート向けとして、ライブタイムライン、ヘルスの確認、失敗時の調査が提供されました。今回の発表で、対象が ECS ネイティブの Linear・Canary・Blue/Green に広がります。
| デプロイ戦略 | 対応時期 |
|---|---|
| ローリングアップデート | 2026 年 7 月 |
| Linear (ECS ネイティブ) | 2026 年 9 月 (今回) |
| Canary (ECS ネイティブ) | 2026 年 9 月 (今回) |
| Blue/Green (ECS ネイティブ) | 2026 年 9 月 (今回) |
使い始めるには、ECS コンソールで対象のサービスを開き、「Deployments」タブを選びます。
アーキテクチャ解説
Linear・Canary・Blue/Green は、新しいリビジョン (グリーン) を現行のリビジョン (ブルー) と並べて起動し、トラフィックを少しずつ、あるいは一度に移します。ECS はこの流れを「ライフサイクルステージ」に分けて管理していて、今回のアップデートで、いまどのステージにいるのかがコンソールに出るようになりました。
ステージの全体像は次の図のとおりです。
ステージは 11 個あり、3 つの戦略に共通です。点線の SCALE_UP・BAKE_TIME・CLEAN_UP 以外には、ライフサイクルフックを設定できます。フックは 2 種類で、Lambda 関数を実行する Lambda フックと、デプロイを止めて ContinueServiceDeployment の呼び出しを待つ一時停止 (Pause) フックです。TEST_TRAFFIC_SHIFT と PRODUCTION_TRAFFIC_SHIFT に置けるのは、Lambda フックだけです。
発表の例とステージの対応
発表が挙げている状態を、ドキュメント上のステージに当てはめると、次のようになります。
| 発表で挙げられている状態 | 関連するライフサイクルステージ |
|---|---|
| グリーンタスクのスケールアップ |
SCALE_UP (グリーンのタスクを起動している段階で、まだトラフィックは受けていない) |
| ライフサイクルフックの待機 | フックを設定したステージ (PRE_SCALE_UP、POST_SCALE_UP、TEST_TRAFFIC_SHIFT など) |
| トラフィックシフトの分布 |
PRODUCTION_TRAFFIC_SHIFT (ブルーからグリーンへ本番トラフィックが移っていく段階) |
| ベイクタイム |
BAKE_TIME (ブルーとグリーンが同時に動いている段階) |
この対応は、各ステージの定義からの整理です。コンソール上の表示名は、これと異なる場合があります。
戦略ごとの違い
いちばん大きな違いは、本番トラフィックの切り替え方です。
| 戦略 | 本番トラフィックの切り替え | 切り替え中の待機 | 既定値 | 切り替え前のフック (PRE_PRODUCTION_TRAFFIC_SHIFT) |
|---|---|---|---|---|
| Linear | 等間隔のステップで段階的に切り替える (ステップの割合は step percent で指定) | 各ステップの間に step bake time の分だけ待つ | step percent は 10%、step bake time は 6 分 | ステップごとに呼び出される |
| Canary | 2 段階で切り替える。まず canary percentage の割合だけ流し、その後に残りをすべて切り替える | canary bake time の分だけ待ってから、残りを切り替える | canary percentage は 5%、canary bake time は 10 分 | canary の切り替え前と、残りの切り替え前に呼び出される |
| Blue/Green | すべてのトラフィックを一度に切り替える | ー | ー | 1 回だけ呼び出される |
既定値は AWS CLI リファレンスに載っている値です。実際の設定は、自分のサービスで確認してください。
既定値のまま待機時間だけを比べると、Linear は 10 ステップのあいだに 6 分の待機が 9 回入るので 54 分、Canary は 5% を流したあとの 10 分です。Canary は待ち時間が短い代わりに、確かめられるのは最初の 5% だけで、残りの 95% は一度に切り替わります。
どの戦略でも、本番トラフィックの切り替えが終わった後は、deployment bake time のあいだ、ブルーとグリーンが同時に動いたままになります。ブルーが残っているので、問題が見つかればすばやく戻せます。
ライフサイクルフックのタイムアウトは、既定で 1,440 分 (24 時間)、最大で 20,160 分 (14 日) です。タイムアウトしたときの動作は、既定ではロールバックで、続行 (CONTINUE) に変えることもできます。
コンソールで確認する
この章は、公式発表とドキュメントの記載をもとに手順をまとめたものです。実際の画面は、環境やコンソールの更新で異なる場合があります。
Deployments タブを見る
Linear・Canary・Blue/Green のサービスに新しいタスク定義リビジョンをデプロイして、「Deployments」タブを開きます。見る順番は、ライブタイムラインで全体の進み具合をつかみ、現在のライフサイクルステージとトラフィックの分布で「いまどこにいるか」を確かめ、最後にヘルスシグナルを見る、という流れがよさそうです。Canary を既定値で使っているなら、5% が新しいリビジョンに流れて 10 分待っている段階か、残りの切り替えに進んだ段階かを、前の章で見たステージと照らして読み取れます。
失敗したデプロイを確認する
失敗したときの見え方は、次の手順で確認できます。サービスの作成時か更新時に、「Deployment failure detection」でサーキットブレーカーと「Rollback on failures」を有効にします。ロールバックを有効にしておくと、失敗時に直前に完了したデプロイへ自動で戻ります。
サーキットブレーカーの対応範囲は、情報源によって書き方が違います。9 月の発表、2026 年 10 月の VPC Lattice 対応の発表、Linear・Canary のサービス作成手順は、これらの戦略でもサーキットブレーカーを扱っています。一方、失敗検知のドキュメントは、ローリングと Blue/Green のみの対応と書いています。設定画面で有効にできるかを、先に確かめてください。
この状態で、存在しないイメージタグを指定したリビジョンをデプロイします。タスクが起動できず、失敗が積み重なります。ECS デベロッパーガイドによると、失敗回数のしきい値は既定ではタスク数の 50% で、最小値は 3 です。タスク数が少ないサービスなら、失敗が 3 回続いた時点でデプロイが失敗扱いになります。
「Deployments」タブには、失敗回数としきい値の状況がデプロイの途中から出ます。失敗したタスクはタイムラインに診断情報つきで並び、AWS CloudTrail などへのリンクから原因を追えます。ロールバックを有効にしていれば、失敗と判定された後に、直前に完了したデプロイへの切り戻しが始まります。
CLI でも確認する
AWS CLI では、list-service-deployments でデプロイの ARN を取得し、describe-service-deployments で詳細を見ます。
aws ecs list-service-deployments \
--cluster <クラスター名> \
--service <サービス名>
aws ecs describe-service-deployments \
--service-deployment-arns <list-service-deployments で取得した ARN> \
--query 'serviceDeployments[0].{status:status,stage:lifecycleStage,hooks:lifecycleHookDetails,circuitBreaker:deploymentCircuitBreaker}'
describe-service-deployments からは、デプロイの状態、現在のライフサイクルステージ、フックの状態、サーキットブレーカーの失敗回数としきい値などを取れます。ただし、トラフィックの割合は取得時点のスナップショットで、デプロイ中の変化は反映されないことがあります。リアルタイムに追うなら、コンソールのほうが向いています。
導入前に確認しておきたいこと
発表の対象は、ECS ネイティブの Linear・Canary・Blue/Green です。AWS CodeDeploy を使うデプロイについては、発表に記載がありません。
Linear と Blue/Green については、ECS デベロッパーガイドに、デプロイ中はブルーとグリーンが同時に動いてリソース使用量が倍になる可能性がある、と書かれています。Canary も、ブルーとグリーンが並走する点は同じです。「追加料金なし」は、この可観測性の機能についての話です。
最小権限でロールを運用している場合は、デプロイを見るための権限も必要です。ECS デベロッパーガイドには、ecs:ListServiceDeployments、ecs:DescribeServiceDeployments、ecs:DescribeServiceRevisions の 3 つが載っています。CloudTrail などのリンク先を開くには、そのサービスを参照する権限が別に要る場合があります。
なお、2026 年 10 月 2 日には、VPC Lattice を使うサービスでも Blue/Green・Linear・Canary が使えるようになりました。ネイティブの 3 戦略を選べるサービスの範囲は、広がっています。
活用シーン
段階的なデプロイの残り時間を知りたい
冒頭の計算のとおり、Linear の既定値では待機だけで約 54 分かかります。その間に「いま何割まで進んだか」「あとどれくらいか」を聞かれても、これまではロードバランサーの設定やサービスのイベントを見比べて答えるしかありませんでした。「Deployments」タブには、トラフィックの分布と現在のステージが出ます。リリースの担当者だけでなく、横から状況を聞く人にも、画面を見せて説明できます。
止まっているのがフック待ちか失敗かを知りたい
ライフサイクルフックのタイムアウトは、既定で 24 時間です。たとえば、一時停止フックを POST_SCALE_UP に置いたまま再開の操作を忘れると、デプロイは待ち続け、24 時間後にタイムアウトして、既定ではロールバックされます。止まっている理由が待機なのか失敗なのかで、やることはまるで違います。現在のステージとフックの状態が同じ画面に出るので、まず「どのステージで、どのフックを待っているのか」を確かめられます。
失敗の原因を探したい
デプロイが失敗したとき、タスクが起動しないのか、起動してもヘルスチェックに通らないのか、ロードバランサー側で弾かれているのかで、見るべき場所が変わります。「Deployments」タブには、コンテナとロードバランサーのヘルスチェックの結果と、失敗したタスクの診断情報が並び、そこから CloudTrail などへ飛べます。当たりをつけるまでの往復が減ります。
まとめ
ECS コンソールのデプロイ可観測性が、7 月のローリングアップデートに続いて、ECS ネイティブの Linear・Canary・Blue/Green にも広がりました。追加料金はかかりません。
派手な機能ではありませんが、段階的なデプロイの途中経過を確かめる手がかりが、1 か所に集まります。Linear・Canary・Blue/Green を使っているなら、次のデプロイで「Deployments」タブを開いてみてください。
参考リンク
- Amazon ECS now provides real-time deployment observability in the AWS Management Console (2026 年 7 月)
- Amazon ECS now provides real-time deployment observability in the AWS Management Console (2026 年 9 月)
- Amazon ECS adds Amazon VPC Lattice support for blue/green, linear, and canary deployments (2026 年 10 月)
- Amazon ECS linear deployments - Amazon ECS デベロッパーガイド
- Amazon ECS canary deployments - Amazon ECS デベロッパーガイド
- Amazon ECS blue/green deployments - Amazon ECS デベロッパーガイド
- Lifecycle hooks for Amazon ECS service deployments - Amazon ECS デベロッパーガイド
- Amazon ECS deployment failure detection - Amazon ECS デベロッパーガイド
- Permissions required for viewing Amazon ECS service deployments - Amazon ECS デベロッパーガイド
- describe-service-deployments - AWS CLI Command Reference
- list-service-deployments - AWS CLI Command Reference