はじめに
2026 年 7 月 1 日、AWS は Amazon ECS のデプロイ状況を AWS マネジメントコンソール上でリアルタイムに可視化できる新機能を発表しました。デプロイの進行状況や失敗の原因を、コンソールを開くだけで一元的に把握できるようになったことが大きな特徴です。
ECS でサービスを運用している方の中には、デプロイが失敗した際に CLI や CloudWatch、CloudTrail を行き来しながら原因を探し、思いのほか時間がかかってしまった経験がある方もいるのではないでしょうか。今回のアップデートは、その課題に直接応えるものです。
本記事では、何が変わったのか、既存のどの機能と組み合わせると効果的なのか、そして実際にコンソール上でどう見えるのかを中心に解説します。ECS でコンテナサービスを運用しているエンジニアの方を想定読者としています。
何が変わったのか
ECS のコンソールでデプロイの状況を確認できること自体は、今回が初めてではありません。2024 年 10 月に追加された「サービスデプロイ」「サービスリビジョン」機能により、ECS コンソールには既に「デプロイ」タブ(英語版コンソールでは「Deployments」)が存在し、デプロイの進行状況や、設定済みのサーキットブレーカー・CloudWatch アラームの有無程度は確認できていました(2024 年 10 月 25 日以降に作成されたデプロイの履歴を、最新 90 日分まで確認できます)。
今回のアップデートは、この既存の「デプロイ」タブを拡張するものです。
| 項目 | 2024 年 10 月時点 | 2026 年 7 月のアップデート後 |
|---|---|---|
| デプロイの進行状況 | Deployments タブでサマリを確認可能 | 各フェーズ・サービスイベント・タスクの起動終了を自動更新のタイムラインで表示 |
| サーキットブレーカーの状態 | 設定の有無を確認できる程度 | しきい値へのタスク失敗の近接度をリアルタイムで可視化 |
| 障害原因の調査 | CloudWatch や CloudTrail を別途確認する必要がある | 失敗タスクを診断コンテキストとともにタイムライン上で直接確認 |
リアルタイムなデプロイ観測性による強化
今回のアップデートでは、以下の 3 つの機能が Deployments タブに追加されました。
| 機能 | 内容 |
|---|---|
| ライブデプロイタイムライン | デプロイの各フェーズ、サービスイベント、タスクの起動・終了の進行状況を自動更新で表示 |
| デプロイヘルスのリアルタイム監視 | サーキットブレーカーの状態(しきい値への近接度)、デプロイアラームの状態、コンテナ / ロードバランサーレベルのヘルスチェックを表示 |
| 障害診断の迅速化 | 失敗したタスクを診断コンテキストや関連リソースへのディープリンクとともにタイムライン上に表示 |
利用条件や対象デプロイタイプの詳細は後述します。
関連する既存機能
新しいデプロイの観測性は、まったく新しい概念を可視化しているわけではありません。ECS には以前から、デプロイの失敗を自動的に検知して対処する仕組みが 2 つ用意されており、今回のコンソール強化は、これらの状態をリアルタイムに表示する形で活かされています。
デプロイサーキットブレーカー
デプロイサーキットブレーカーは、ローリングアップデート中にタスクが安定状態に到達できるかどうかを監視する仕組みです。タスクの起動失敗が一定のしきい値を超えるとデプロイを失敗と判定し、rollback を有効にしていれば直前に成功したデプロイまで自動的に切り戻します。しきい値は固定数またはデプロイ済みタスク数に対する割合で指定でき、失敗を連続でカウントするか累積でカウントするかも選択できます。
新しい観測性機能では、このサーキットブレーカーが今どれだけしきい値に近づいているかを、タイムライン上でリアルタイムに追跡できるようになりました。
CloudWatch アラームによるロールバック
もう 1 つの仕組みが、CloudWatch アラームに基づく自動ロールバックです。サーキットブレーカーがタスクの起動失敗を検知するのに対し、こちらは CPU 使用率やレスポンスレイテンシーといった、デプロイ後にじわじわと現れるパフォーマンス劣化を検知の対象にできます。デプロイ完了後も一定の bake time の間はアラームの状態を監視し続け、その間に ALARM 状態に変化するとロールバックが実行される仕組みです。
新しい観測性機能の「デプロイアラームの状態」は、この bake time 中のアラームの状態をコンソール上で直接確認できるようにしたものです。
いずれの仕組みも対象は rolling update デプロイタイプに限られており、この点は今回の観測性強化の対象範囲とも一致しています。サーキットブレーカーやアラームベースロールバックを設定していないサービスでは、タイムライン上のこれらの情報は意味を持たないため、新しい観測性を最大限活用するには、まずこれらの設定を見直しておく価値があります。
利用条件・注意点
今回のデプロイ観測性強化を使う上で、事前に把握しておきたい点をまとめます。
まず、有効化のための作業は一切必要ありません。対象の ECS サービスをコンソールで開き、「Deployments」タブを選択するだけで、新しい画面がそのまま表示されます。追加料金もかからず、すべての AWS 商用リージョンおよび AWS GovCloud(US)リージョンで利用できます。
一方で、対象となるデプロイタイプには制限があります。
| 項目 | 内容 |
|---|---|
| 対象デプロイタイプ | rolling update(ECS デプロイコントローラー)のみ |
| 有効化作業 | 不要(コンソールの Deployments タブを開くだけ) |
| 追加料金 | なし |
| 利用可能リージョン | すべての AWS 商用リージョン、AWS GovCloud(US) |
Blue/Green デプロイや EXTERNAL デプロイコントローラーを使っているサービスが今回のタイムライン表示の対象に含まれるかどうかは、発表内容に明記がなく確認が取れていません。rolling update 以外のデプロイタイプを利用している場合は、実際にコンソールを開いて表示内容を確認することをおすすめします。
動作確認の手順
実際に手を動かして、新しいデプロイ観測性がどのように機能するかを確認してみます。ここでは、あえて失敗するデプロイを行い、コンソール上でどのような情報が得られるかを見ていきます。
サーキットブレーカーを有効にしたサービスを用意する
まず、デプロイサーキットブレーカーとロールバックを有効にした ECS サービスを作成します。
aws ecs create-service \
--cluster <cluster-name> \
--service-name <service-name> \
--deployment-controller type=ECS \
--desired-count 3 \
--deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
--task-definition <task-family>:<revision> \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}"
サービスが安定稼働したら、次に意図的に失敗するタスク定義を新しいリビジョンとして登録し、そのリビジョンへのデプロイを実行します。存在しないコンテナイメージタグを指定するなど、タスクが起動できない状態を作るのが手軽な方法です。
aws ecs update-service \
--cluster <cluster-name> \
--service <service-name> \
--task-definition <task-family>:<broken-revision>
コンソールで確認する
デプロイを実行したら、対象サービスを開き、「デプロイ」タブ(英語版コンソールでは「Deployments」)を選択します。タブ上部には直近のデプロイの状況が表示され、実際の画面では以下の情報が確認できます。
デプロイタイムラインには、デプロイの「開始」「進行中」「完了」の各フェーズが、開始時刻や所要時間とともに時系列で表示され、進行中は自動的に更新されます。あわせて「CloudTrail で表示」ボタンが用意されており、このデプロイに関連する CloudTrail のイベントへ直接遷移できます。
同じ画面内の「モニタリング」セクションでは、以下がリアルタイムで確認できます。
| 項目 | 内容 |
|---|---|
| サービスデプロイサーキットブレーカー | 有効時の稼働状況(監視中 / モニタリング完了など) |
| 失敗の発生間近 | 発生した失敗タスク数と、設定されている失敗しきい値の対比 |
| デプロイアラーム | CloudWatch アラームによるロールバック設定の有効 / 無効 |
| ヘルスチェックステータス | ロードバランサーのターゲット正常性、コンテナのヘルスチェックの設定状況 |
サーキットブレーカーやアラームを設定していないサービスでは、これらの項目は「オフになっています」「未設定」のように表示され、監視対象がないことがそのまま示されます。これらの情報を意味のあるものにするには、事前にサーキットブレーカーやアラームベースロールバックを設定しておく必要がある点は、前章で触れた通りです。
タスクの起動失敗が続き、サーキットブレーカーのしきい値に達すると、デプロイは失敗と判定され、rollback を有効にしていれば直前の安定した状態へ自動的に切り戻されます。
なお、同じ「デプロイ」タブの下部には、2024 年 10 月から提供されている過去のサービスデプロイ一覧やサービスイベントの表示もそのまま残っています。今回追加されたのは、この画面上部に表示される、直近のデプロイに対するリアルタイムのタイムラインとモニタリング部分です。
活用シーン
ここまで見てきた新しい観測性が、具体的にどのような場面で役立つのかを整理します。
トラブルシューティングの起点を一本化できる
これまでデプロイの失敗原因を調べるには、サービスイベントの確認、CloudWatch Logs でのログ追跡、CloudTrail での API 呼び出し履歴確認など、複数ツールを横断する作業が必要でした。今回のアップデートにより、失敗したタスクの診断コンテキストと関連リソースへのディープリンクがタイムライン上に集約されるため、調査の起点をコンソール 1 画面に絞り込めます。インシデント対応の初動で「直近のデプロイが原因かどうか」を切り分ける場面でも同様に、デプロイアラームの状態やヘルスチェックの結果がまとまっていることで、ECS の CLI 操作に不慣れなメンバーでも状況を把握しやすくなります。
手動ロールバックの判断材料になる
ECS には、サーキットブレーカーやアラームによる自動ロールバックとは別に、stopDeployment API を使って手動でロールバックを実行する手段も用意されています。サーキットブレーカーのしきい値への近接度をリアルタイムに確認できるようになったことで、自動ロールバックが発動する前の段階でも、タスク失敗の傾向を見ながら手動でのロールバック判断を早めに下しやすくなります。
まとめ
Amazon ECS のデプロイ観測性強化は、2024 年 11 月に追加された Deployments タブを土台に、ライブデプロイタイムライン、デプロイヘルスのリアルタイム監視、障害診断の迅速化という 3 つの機能を組み合わせたアップデートです。デプロイサーキットブレーカーや CloudWatch アラームによるロールバックといった既存の仕組みと組み合わせることで、その価値が最大化されます。
対象は rolling update デプロイタイプに限られますが、追加料金なしですぐに利用できる機能です。
参考リンク
- Amazon ECS now provides real-time deployment observability in the Amazon ECS Console
- How the Amazon ECS deployment circuit breaker detects failures
- Automate rollbacks for Amazon ECS rolling deployments with CloudWatch alarms
- Amazon ECS introduces 1-click rollbacks for service deployments
- Improving deployment visibility for Amazon ECS services
- Amazon ECS サービスデプロイを使用してサービス履歴を表示する