Canary / Linear / Blue-Green に対応した Amazon ECS コンソールの「デプロイ」タブを試してみた
はじめに
2026年9月21日のアップデートで、Amazon ECS コンソールの「デプロイ」タブが Linear、Canary、Blue-Green のデプロイタイプに対応しました。
このタイムライン表示は7月にローリングデプロイ向けとして提供され、今回、ほかのデプロイ戦略にも対応が広がりました。
従来、Canary や Linear では、デプロイ中に本番トラフィックを段階的に移行するため、タスク数の増減だけからは、新旧どちらのリビジョンにどの程度の比率でトラフィックが流れているかを判別することは困難でした。
今回のアップデートにより、「デプロイ」タブでは green / blue のトラフィック配分とライフサイクルステージの進行を同じ画面で確認できるようになりました。本記事では Fargate の Canary デプロイを実施し、これらの表示と失敗時の診断を検証しました。
検証環境
ap-northeast-1 で、ALB と blue / green 用の2つのターゲットグループを使用する Fargate サービスを使いました。デプロイ戦略には Canary を選択し、Canary フェーズで green にシフトするトラフィックを 10% に設定しました。ベイク時間は Canary の段階で 5 分、100% 移行後に 3 分としています。
正常な Canary デプロイでの表示
nginx イメージを 1.27 から 1.28 に更新したタスク定義のリビジョン 2 で Canary デプロイを開始しました。
green タスクの起動中は、ロードバランサーのヘルシーなターゲット数が必要数に達しておらず、本番トラフィックは blue のままです。
green のターゲットがすべて健全になった後、デプロイはトラフィックシフトのステージへ進みました。今回は Canary のトラフィックシフトが1段階のみのため、green 10% / blue 90% の状態が 5 分間維持されます。
5 分間のベイクが終了すると green が 100% までシフトし、移行完了後のベイク（3 分）に入ります。
今回のデプロイは、開始から完了まで 11 分 31 秒かかりました。ベイク時間の合計である 8 分を含むため、設定値によって所要時間は変わります。
失敗した Canary デプロイの診断とロールバック
続いて、存在しないイメージタグを指定したタスク定義（リビジョン 3）で意図的にデプロイを失敗させました。
green タスクが停止すると、タイムラインに Recent failure: task stopped と CannotPullContainerError のエラー内容が表示されます。トラフィックシフトへ進んでいないため、本番トラフィックは blue 側のリビジョン 2 に 100% のままルーティングされます。タスク詳細・ログ・トラブルシューティングガイドへのリンクも同じ画面に表示されます。
この状態から、画面上のロールバック（Roll back）ボタンで手動ロールバックを実行しました。
ロールバック完了後は、リビジョン 3 のタスクが 0 になり、リビジョン 2 の2タスクが稼働した状態で維持されました。今回はトラフィックシフト前の失敗だったため、blue 側は当初から 100% を維持していました。
「Amazon Q で検査」で根本原因を確認する
失敗画面には「Amazon Q で検査」（Inspect with Amazon Q）ボタンがあります。押すとチャットが開き、今回は英語のレポートが返りました。日本語で確認したい場合は、次のように再依頼します。
先ほどの ECS デプロイ失敗レポートを、日本語版で改めて表示して
無効なコンテナイメージタグを根本原因として示す日本語の分析が返ってきました。根拠となる証跡テーブルと解決策の推奨事項も日本語で表示されました。
まとめ
ECS コンソールの「デプロイ」タブが機能強化され、Canary、Linear、Blue-Green デプロイの状況もコンソール上で確認できるようになりました。
「デプロイ」タブは、デプロイ中の進捗や異常を確認する監視画面として利用でき、問題が発生した場合はロールバックを実行することで、進行中のデプロイを中断し、迅速に切り戻すことができます。
Amazon Q を使えば、デプロイエラーの調査も可能です。回答を日本語で確認したい場合は、チャットで日本語による再依頼もできます。あわせて活用してみてください。
関連記事
