はじめに
2026 年 9 月 16 日、AWS は Amazon ECS の Managed Daemons に対して、デプロイ状況をコンソール上で一元的に確認できる新しいビューを発表しました。
Managed Daemons のデーモンを更新したあと、デプロイが進んでいるのか止まっているのかを確かめるために、コンソールの画面をいくつも行き来する。失敗していれば、どのキャパシティプロバイダーで何が起きたのかを、アラームやタスクのログまで順にたどって調べる。これまでは、こうした情報を複数の場所から集める必要がありました。
Managed Daemons は、セキュリティやオブザーバビリティ、ネットワークなどのエージェントを、インスタンスごとに 1 つずつ配置して一元管理する機能です。2026 年 4 月に提供が始まったばかりです。
本記事では、このビューで何が見えるのか、実際の画面でどう確認するのかを整理します。あわせて、実運用で踏みやすい落とし穴を 3 つ取り上げます。ベイク時間の間は進捗が 100% でも完了にならないこと、更新時に指定しなかった設定がデフォルトに戻ること、開始時点ですでに ALARM のアラームはロールバックの判定対象外になることです。ECS を運用しているインフラ・プラットフォームエンジニアの方はもちろん、これから Managed Daemons の導入を検討している方にも参考になる内容です。
何が変わったのか
今回のアップデートで何が変わったのかを、まず Before / After で整理します。
| Before | After | |
|---|---|---|
| 情報の確認 | デプロイ状況を把握するには、複数のコンソール画面、CloudWatch アラーム、タスクログなどを個別に確認する必要があった | デプロイの進捗、失敗、停止要因が、1 つの統合デプロイメントビューに集約された |
| 障害発生時の原因特定 | 停止理由やログを、断片的な情報から手動で繋ぎ合わせて調査する必要があった | 停止理由と、調査に使えるリンクが、画面上に表示されるようになった |
| 提供条件 | 該当なし | コンソール専用のビューとして、追加コストなしで全 AWS コマーシャルリージョンで利用可能 |
それぞれの項目の中身は、次の章で整理します。
新しいデプロイメントビューの中身
統合デプロイメントビューには、大きく分けて次の 5 つの情報が集約されています。右端の列は、実際のコンソールでの表示です。
| 要素 | 表示される主な内容 | コンソールでの表示 |
|---|---|---|
| ライフサイクルタイムライン | 各ステップのタイムスタンプ、総デプロイ時間、中断時のロールバックパス | デプロイタイムライン |
| キャパシティプロバイダーごとの進捗バー | 完了・進行中・残りのインスタンス数、キャパシティプロバイダー削除時のドレイン中・置換中のインスタンス数 | デプロイタイムラインの「進行中」ステップ内に表示される進捗バー |
| モニタリングパネル | デプロイサーキットブレーカー、デプロイアラーム、コンテナヘルスチェックの状態と CloudWatch アラームの詳細 | モニタリング |
| タスク失敗時のリンク集約 | 停止理由、対象タスクへのリンク、ログへのリンク、トラブルシューティングガイドへのリンク | 「最近のデーモンタスクの失敗」と、その下の 3 つのリンク |
| リビジョン情報 | ターゲット / ソースリビジョンのインスタンス数、ドレイン率、ベイク時間 | デーモンリビジョン、ドレイン率、ベイク時間 |
画面上での実際の見え方は、次の「確認手順」で確認します。
確認手順
新しいデプロイメントビューは、Managed Daemons のデーモンを更新するだけで確認できます。ここでは、正常にローリングデプロイが完了するケースと、失敗してロールバックされるケースのそれぞれについて、確認の手順と、画面での表示を整理します。以下の表示は、筆者が実際に Managed Daemons を動かして確認した内容に基づいています。
画面の場所
デプロイの状況は、ECS コンソールでクラスターを開き、「デーモン」タブで対象のデーモン名を選択し、詳細画面の「デプロイ」タブで確認できます。今回の発表で追加されたビューが、このタブです。タブの下部には、過去のデプロイを一覧できる「デーモンデプロイ」の表も用意されています。
事前に必要な環境
ビューを確認するには、Amazon ECS Managed Instances のキャパシティプロバイダーを関連付けたクラスターと、そのキャパシティプロバイダーに配置されたデーモンが必要です。デーモンはインスタンスごとに 1 タスクが配置されるため、あわせてアプリケーションのサービスを 1 つ起動してインスタンスを立ち上げておくと、デプロイの進行がビューに現れやすくなります。インスタンスが 1 台もない状態では、移行の対象がないため、進捗バーの動きはほとんど確認できません。
Managed Instances では EC2 インスタンスが実際に起動するため、課金が発生します。確認が終わったら、サービス、デーモン、キャパシティプロバイダー、クラスターの順に削除します。
正常にデプロイが完了するケース
まず、新しいリビジョンのデーモンタスク定義を register-daemon-task-definition で登録し、続けて update-daemon でデーモンを更新します。デーモンの更新では、指定しなかった設定がデフォルト値に戻る仕様なので、ドレイン率とベイク時間は毎回明示します。
aws ecs update-daemon \
--daemon-arn arn:aws:ecs:<region>:<account-id>:daemon/<cluster-name>/<daemon-name> \
--daemon-task-definition-arn <daemon-task-definition-arn> \
--capacity-provider-arns arn:aws:ecs:<region>:<account-id>:capacity-provider/<capacity-provider-name> \
--deployment-configuration "drainPercent=50,bakeTimeInMinutes=5"
コマンドの実行後にデーモンの「デプロイ」タブを開くと、上部に「進行中のデプロイ」が表示されます。反映までに少し時間がかかることがあるので、表示されない場合は更新ボタンで再読み込みします。
デプロイタイムラインには、「デプロイが開始されました」に続いて「進行中」が表示され、「インスタンスはターゲットリビジョンに移行中です。」というメッセージとともに、キャパシティプロバイダーごとの進捗バーが現れます。バーの上には「0 件が完了 1 件が進行中 残り 0 件」のように件数が表示され、移行が進むにつれて完了の件数と割合が増えていきます。
画面下部の「デーモンリビジョン」の表では、ターゲットリビジョン(新)とソースリビジョン(旧)がそれぞれ別の行で表示され、「1 件が実行中」「1 件をドレイン中」という形で台数が示されます。更新の直後はソースリビジョンのドレイン中が増え、移行が進むにつれてターゲットリビジョンの実行中が増えていく、という入れ替わりを追うことができます。同じ表の下には、設定したドレイン率とベイク時間も表示されます。
右側の「モニタリング」では、サーキットブレーカーが「モニタリング」状態となり、失敗したタスクの数が「0/3 件」のように表示されます。アラームとコンテナの正常性を設定していない場合は、それぞれ「オフになっています」「未設定」と表示されます。
ここで注意したいのがベイク時間の挙動です。進捗バーが 100% に達しても、ベイク時間を設定している間はタイムラインが「進行中」のまま維持されます。ベイク時間を 5 分に設定した場合は、移行が完了してからさらに 5 分間の監視が続き、その後にタイムラインが「完了」に変わって、サーキットブレーカーも「モニタリングが完了しました」になります。完了後はデプロイの所要時間が表示され、「デーモンデプロイ」の表にもステータス「成功」として記録されます。
失敗してロールバックされるケース
失敗時の表示は、存在しないコンテナイメージを指定したデーモンタスク定義を登録し、そのリビジョンに更新すると再現できます。コマンドは先ほどと同じ update-daemon です。--deployment-configuration を省略すると、ドレイン率 25%・ベイク時間 0 分のデフォルト値で実行されます。「デーモンリビジョン」の表には、この値が表示されます。
更新から数分が経つと、デプロイタイムラインの進捗バーの下に「最近のデーモンタスクの失敗」が表示されます。イメージを取得できない場合は、CannotPullContainerError というエラー名と、取得に失敗したイメージ名を含むエラー内容が表示されます。その直下には「タスクの詳細を表示」「ログを表示」「トラブルシューティングガイドを表示」という 3 つのリンクが並び、失敗したタスクの調査を、デプロイ画面から始められます。
失敗が重なると、右側の「モニタリング」にあるサーキットブレーカーの失敗タスクの数が「1/3 件」「2/3 件」と増えていき、「3/3 件」に達するとステータスが「トリガーされました」に変わります。これに合わせて、デプロイタイムラインには「移行が中断されました」が追加され、続いて「ロールバック中」とロールバックの理由が表示されます。この理由のメッセージは、コンソールの表示言語が日本語でも英語で表示されます。
ロールバックが終わると、タイムラインの最後に「ロールバックされました」と所要時間が表示され、「デーモンリビジョン」の表では、ソースリビジョン(旧)の実行中の件数が元に戻ります。失敗の詳細とリンクは、ロールバック後もタイムライン上に残るため、あとからの振り返りにも利用できます。
失敗が確定してロールバックが始まるまでには、イメージ取得のリトライを含めて十数分かかることがあります。この時間は失敗の種類や設定によって変わるので、実運用では余裕を見込んでおきます。
表示に関する補足
進捗バーの件数は、インスタンスが 1 台だけの環境でも、置換用のインスタンスを含めて 2 件分が表示されることがあります。件数の内訳は公式ドキュメントに明記がないので、表示された値をそのまま読み取ります。
既存機能との組み合わせ方
統合デプロイメントビューは、デプロイの状況を「見る」ための機能です。デプロイが止まるのか、ロールバックされるのかといった挙動そのものは、デプロイ設定で決まります。サーキットブレーカー、CloudWatch アラーム、ベイク時間、ドレイン率といった既存の仕組みを、どう組み合わせるかが重要になります。この章では、それぞれの設定がビューにどう映るかを整理します。
| 設定 | 役割 | ビューでの見え方 |
|---|---|---|
| サーキットブレーカー | デーモンタスクの失敗が一定数に達すると、自動でロールバックする(組み込み済み) | 「モニタリング」のサーキットブレーカーと、失敗したタスクの数(「0/3 件」など) |
| デプロイアラーム | 指定した CloudWatch アラームが ALARM 状態になると、自動でロールバックする | 「モニタリング」のアラーム(未設定の場合は「オフになっています」) |
| ベイク時間 | 全インスタンスの更新後も、指定した時間だけ監視を続けてから完了とする | 進捗が 100% になっても「進行中」のまま。「デーモンリビジョン」の下に「ベイク時間」を表示 |
| ドレイン率 | 同時にドレインするインスタンスの割合を決める | 「デーモンリビジョン」の下に「ドレイン率」と、「1 件をドレイン中」の台数を表示 |
サーキットブレーカー
Managed Daemons には、サーキットブレーカーが組み込まれています。デプロイ設定(drainPercent、alarms、bakeTimeInMinutes)には、しきい値を指定する項目がなく、更新時には常に有効な状態で動作します。デーモンタスクの失敗を検知すると、自動で直前のリビジョンにロールバックされます。
コンソールの「モニタリング」に表示されるのは「失敗したタスク」の数です。タスクは正常に起動したものの、アプリケーションの性能に影響が出ている、といった問題は、この数では捉えにくくなります。そうしたケースをカバーするのが、次の CloudWatch アラームです。
CloudWatch アラーム
デプロイ設定の alarms に CloudWatch アラームを指定すると、デプロイ中にそのアラームが ALARM 状態になった時点で、自動でロールバックされます。コンソールでは、アラームを使用するオプションを有効にして、監視対象のアラームを選択します。
デーモンの更新では、ドレインされたインスタンスで動いていたアプリケーションのタスクも自動で入れ替えられます。つまり、更新はデーモン自身だけでなく、アプリケーションにも影響を及ぼしえます。アラームには、デーモンのメトリクスに加えて、アプリケーションのエラー率やレイテンシなど、更新の影響が現れそうな指標を選ぶと、安全網として実用的になります。
注意したいのは、デプロイの開始時点ですでに ALARM 状態になっているアラームは、ロールバックの判定対象にならない点です。たとえば、別の原因でアラームが鳴ったままの状態でデーモンを更新すると、そのアラームはロールバックの判定に使われません。更新の前に、次のコマンドで、指定するアラームが正常な状態(OK)であることを確認します。
aws cloudwatch describe-alarms \
--alarm-names <alarm-name> \
--query 'MetricAlarms[].StateValue' \
--output text
ALARM と表示された場合は、原因を解消してから更新します。指定するアラームが複合アラームの場合は、--alarm-types CompositeAlarm を付け、--query を CompositeAlarms[].StateValue に変えます。
ベイク時間
ベイク時間(英語では bake time、API のパラメーター名は bakeTimeInMinutes)は、全インスタンスの更新後、デプロイを完了させるまでに待機する時間です。0 分から 1440 分(24 時間)の範囲で指定でき、デフォルトは 0 分です。待機している間も CloudWatch アラームの監視は続き、ALARM 状態になればロールバックされます。
デフォルトの 0 分のままだと、全インスタンスの更新が終わった時点でデプロイが完了するため、更新の完了後に現れる問題はアラームで検知できません。影響が時間をおいて現れるものであれば、アラームのメトリクスの集計間隔を考慮して、異常を検知できるだけの時間を設定します。長くするほどデプロイの完了も遅れるので、検知したい問題と待てる時間のバランスで決めます。
ドレイン率
ドレイン率は、デプロイ中に同時にドレインするインスタンスの割合で、デフォルトは 25% です。たとえば 20% を指定すると、全体の 20% のインスタンスずつ順番に入れ替えます。値を大きくするとデプロイは速く終わりますが、その分、一時的に利用できるキャパシティが減ります。デーモンの更新ではアプリケーションのタスクも入れ替わるため、アプリケーションに残しておきたい余力に合わせて決め、更新中は「デーモンリビジョン」の表で、ドレイン中の台数も確認します。
更新のたびに設定をすべて指定する
「確認手順」で触れたとおり、更新では指定しなかった設定がデフォルト値に戻ります。ここで見落としやすいのが critical です。これは、デーモンタスクが失敗したり停止したりしたときのインスタンスの扱いを決める設定です。true(デフォルト)ではインスタンスがドレインされて置換され、false(non-critical)ではインスタンスがそのまま稼働を続け、アプリケーションのタスクにも影響しません。更新で省略すると true に戻ります。更新のたびに、必要な設定をすべて指定します。アラームとベイク時間を設定して更新する場合は、次のようになります。
aws ecs update-daemon \
--daemon-arn arn:aws:ecs:<region>:<account-id>:daemon/<cluster-name>/<daemon-name> \
--daemon-task-definition-arn <daemon-task-definition-arn> \
--capacity-provider-arns arn:aws:ecs:<region>:<account-id>:capacity-provider/<capacity-provider-name> \
--deployment-configuration '{"drainPercent":25.0,"bakeTimeInMinutes":5,"alarms":{"alarmNames":["<alarm-name>"],"enable":true}}'
non-critical のデーモンは、このコマンドに --no-critical を加えて更新します。指定を忘れると、デーモンの失敗でインスタンスがドレイン・置換される critical の挙動に戻ってしまうため、注意が必要です。
活用シーン
デプロイ中の見守り方は「確認手順」で触れたとおりですが、このビューが特に力を発揮するのは、終わったあとの振り返りです。
ロールバック後の振り返り(ポストモーテム)
ロールバックが発生したデプロイでは、中断の原因となった失敗の内容が、ロールバック後もタイムラインに残ります。「いつ、どこで、何が起きて、どう元に戻ったのか」を、あとから時系列でそのまま追えます。「デーモンリビジョン」には、そのデプロイで使われたドレイン率とベイク時間も表示されるので、設定が妥当だったかを見直す材料にもなります。
過去のデプロイは、「デプロイ」タブ下部の「デーモンデプロイ」の表に、ステータス、開始時刻、終了時刻、デプロイ期間とともに一覧で表示されます。ポストモーテムのレポートを書く際は、この画面を開いて、タイムスタンプや失敗の内容を転記するだけで、事実関係の整理が進みます。
履歴をいつまで参照できるかは、公式発表やドキュメントに記載が見当たりませんでした。重要なインシデントについては、タイムラインの内容を、レポートや運用記録に早めに残しておくことをおすすめします。
使用上の注意点
便利なビューですが、使い始める前に押さえておきたい点が 2 つあります。
コンソール専用の機能である
統合デプロイメントビューは、AWS マネジメントコンソールでのみ利用できる機能です。AWS CLI、SDK、CloudFormation、Terraform といったコードからは利用できません。Managed Daemons 自体の作成や更新は CLI や CloudFormation からも行えますが、このビューの画面そのものを、コードから利用することはできません。
CI/CD のパイプライン内でデプロイの成否を判定したり、失敗を自動で通知したりする用途には向きません。そうした用途では、list-daemon-deployments と describe-daemon-deployments でデプロイの状態を取得できます。デーモンタスクの起動失敗は、Amazon EventBridge のイベントで検知できます。
対象は Managed Daemons のデプロイ
Managed Daemons は、Amazon ECS Managed Instances を対象とした機能です。EC2 起動タイプの ECS サービスには、以前から DAEMON スケジューリング戦略がありますが、Managed Daemons はそれとは別の新しい機能として提供されています。今回のビューが対象とするのは、この Managed Daemons のデプロイです。
通常の ECS サービスのデプロイについては、2026 年 7 月に別のデプロイ可観測性の強化が発表されています。こちらはローリングアップデート型のサービスが対象で、ECS サービスの Deployments タブから確認する機能です。名前が似ているので、混同に注意が必要です。
Managed Daemons は登場して間もない機能のため、今後、機能の追加や画面の変更が入る可能性があります。利用する際は、最新の公式ドキュメントもあわせて確認してください。
まとめ
今回のアップデートで、Managed Daemons のデプロイ状況を追うための情報が、デーモンの「デプロイ」タブに集約されました。更新の最中も、終わったあとの振り返りも、画面を行き来せずに進められます。
ビューが映すのは設定の結果です。ロールバックの条件や監視の厳しさは、デプロイ設定で決まります。コンソール専用なので、自動化や通知には既存の仕組みを使います。
Managed Daemons を使っているなら、次の更新で一度「デプロイ」タブを開いてみてください。
参考リンク
- Amazon ECS deployment observability for Amazon ECS Managed Daemons in AWS Management Console(AWS 公式発表)
- Amazon ECS Managed Daemons(AWS 公式ドキュメント)
- Daemon deployments(AWS 公式ドキュメント)
- Creating and managing daemons(AWS 公式ドキュメント)
- Daemon task definitions(AWS 公式ドキュメント)
- DaemonDeploymentConfiguration(Amazon ECS API リファレンス)
- Amazon ECS が ECS マネージドインスタンス用の Managed Daemons を発表(AWS 公式発表)
- Amazon ECS Managed Daemons now support non-critical daemons(AWS 公式発表)
- Amazon ECS now provides real-time deployment observability in the AWS Management Console(AWS 公式発表)