はじめに
2026 年 4 月 1 日、AWS は Amazon ECS において新機能 Managed Daemons を発表しました。ECS Managed Instances を利用するクラスター上で、ロギングや監視、セキュリティといったソフトウェアエージェントをアプリケーションとは独立して一元管理できる仕組みです。全 AWS 商用リージョンで即時利用可能となっています。
本記事では、何が変わったのか・どういった仕組みで動くのか・実際にどう使うのかを中心に解説します。ECS の運用に携わるエンジニアや、コンテナ基盤の信頼性・運用効率に関心のある方を対象にしています。
新機能の概要
Managed Daemons は、ECS Managed Instances のキャパシティプロバイダーに対して、ソフトウェアエージェントをアプリケーションとは独立したプロセスとしてデプロイ・管理できる機能です。
キャパシティプロバイダーに紐づく各インスタンスにデーモンタスクが 1 つだけ自動配置されます。アプリタスクが何本動いていても、インスタンス 1 台につきデーモンは 1 つです。デーモンはアプリタスクよりも先に起動することが保証されているため、ロギング・トレース・メトリクス収集がアプリの起動前に確実に立ち上がります。
更新はアプリのデプロイとは切り離して行えます。バージョンアップ時は ECS がローリングデプロイを自動実行し、サーキットブレーカーと自動ロールバックが組み込まれています。
ホストレベルのアクセスも備えています。デーモンタスクを特権コンテナとして構成したり、Linux Capabilities の付与やホストファイルシステムのマウントが可能です。監視やセキュリティのエージェントがホストのプロセス・システムコールを参照するのに必要なアクセスを、アプリタスクとは独立して設定できます。
何が変わったのか
Managed Daemons が登場する以前、ECS でデーモン的なエージェントを動かすには主に 2 つのアプローチが取られていました。
従来のアプローチと課題
サイドカーパターン
アプリのタスク定義にエージェントコンテナを同梱する方法です。構成がシンプルな反面、課題も多くありました。
タスクが 10 本あればエージェントも 10 本起動し、同じ処理がインスタンス上で多重に動きます。エージェントを更新するたびにアプリ側のタスク定義も変更・再デプロイが必要になるため、プラットフォームチームはアプリチームのデプロイサイクルに合わせて動くことを強いられます。
DAEMON スケジューリング戦略
ECS サービスの DAEMON 戦略を使うと、クラスター内の全インスタンスにタスクを 1 つずつ配置できます。ただし、この戦略は EC2 起動タイプ向けの機能であり、いくつかの制約がありました。
デーモンタスクはスケジューラ上で優先されますが、スケールアウト時にレプリカタスクと競合し、アプリより先の起動が保証されないケースがあります。タスク停止時に再起動は行われますが、インスタンス自体の置き換えは行われません。ローリングアップデートは可能なものの、サーキットブレーカー保護や自動ロールバックはありません。
Managed Daemons による変化
| 観点 | サイドカー | DAEMON 戦略 | Managed Daemons |
|---|---|---|---|
| インスタンスあたりのエージェント数 | タスク数分 | 1 つ | 1 つ |
| アプリより先の起動保証 | なし | 不完全（スケールアウト時に競合の可能性） | あり（完全保証） |
| アプリと独立した更新 | 不可 | 可 | 可 |
| 停止時の復旧 | なし | タスク再起動のみ | あり（インスタンスごと置き換え） |
| ローリングアップデート＋ロールバック | なし | なし | あり |
Managed Daemons では、デーモンのライフサイクルがアプリから切り離されます。プラットフォームチームはアプリチームと調整することなくエージェントを更新できます。
仕組みの解説
Managed Daemons がどのように動作するのか、3 つの観点から説明します。
デーモンの配置フロー
Managed Daemons を利用するには、まずデーモンタスク定義を登録し、クラスター内のキャパシティプロバイダーに関連付けます。デーモンタスク定義は通常のタスク定義とは独立した専用リソースであり、以降の制御は ECS が自動で行います。
アプリタスクの起動リクエストが来ると、ECS は以下の順序で処理を行います。
なお、デーモンとアプリタスク間の通信には daemon_bridge という新しいネットワークモードが使われます。デーモンがアプリタスクと通信しつつ、アプリのネットワーク設定からは独立して動作します。
デーモン停止時の自動復旧
デーモンタスクが停止した場合、ECS はタスクの再起動にとどまらず、インスタンスごと入れ替えます。
バージョン更新時のローリングデプロイ
デーモンのバージョンを更新する際は、ECS がクラスター全体に「start before stop」方式のローリングデプロイを自動実行します。新インスタンスでデーモンが起動してからアプリを移行し、その後に旧インスタンスを終了するため、デプロイ中もロギング・監視・トレーシングが途切れません。
一度にドレインするインスタンスの割合は設定可能で、CloudWatch アラームと連携したベイクタイムも設定できます。
使い方
ここでは AWS 公式ブログの手順をベースに、CloudWatch Agent を例にした Managed Daemons のセットアップ手順を紹介します。
前提条件
ECS Managed Instances のキャパシティプロバイダーが設定済みのクラスターが必要です。
まだ作成していない場合は公式ドキュメントを参照してください。
① デーモンタスク定義を作成する
ECS コンソールのナビゲーションペインに新しく追加された 「Daemon task definitions」 を選択し、「Create new daemon task definition」 をクリックします。
以下の項目を設定します。
| 項目 | 設定例 |
|---|---|
| Daemon task definition family | cloudwatch-agent-daemon |
| Task execution role | ecsTaskExecutionRole |
| CPU | 1 vCPU |
| Memory | 0.5 GB |
| Container name | cloudwatch-agent |
| Image URI | public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest |
設定を確認したら 「Create」 をクリックします。
② クラスターにデーモンを作成する
ECS コンソールの 「Clusters」 ページから対象のクラスターを選択します。クラスター詳細ページに新しく追加された 「Daemons」タブ を開き、「Create daemon」 をクリックします。
以下の項目を設定します。
| 項目 | 設定例 |
|---|---|
| Daemon task definition family | 手順①で作成したタスク定義 |
| Capacity provider | 対象の ECS Managed Instances キャパシティプロバイダー |
設定を確認したら 「Create」 をクリックします。
③ 動作を確認する
デーモンの作成後、ECS はキャパシティプロバイダーに紐づく各インスタンス上でデーモンタスクを自動起動します。
動作確認のため、nginx などのサンプルワークロードをサービスとしてデプロイします。デプロイ後にコンソールから以下を確認できます。
- 各インスタンスに CloudWatch Agent のデーモンタスクが 1 つずつ配置されていること
- アプリタスクより先にデーモンタスクが
RUNNING状態になっていること
④ デーモンを更新する
デーモンのバージョンを更新する場合は、新しいデーモンタスク定義のリビジョンを作成し、クラスターの「Daemons」タブから対象のデーモンを選択して更新します。
ECS が「start before stop」方式のローリングデプロイを自動実行します。新インスタンスでデーモンが RUNNING になってからアプリタスクが移行されるため、更新中もデータ収集の空白期間が生じません。
ユースケース・ベストプラクティス
制約・前提条件
Managed Daemons は ECS Managed Instances（EC2 ベース）専用の機能です。Fargate ではご利用いただけません。現在 Fargate を利用している場合はこの機能の対象外となるため、ご注意ください。
代表的なユースケース
Managed Daemons は、アプリタスクとは独立して全インスタンスに一律に展開したいエージェント全般に適しています。
| カテゴリ | 具体例 |
|---|---|
| オブザーバビリティ | CloudWatch Agent、Datadog Agent、Prometheus Node Exporter |
| ログ収集 | Fluent Bit、Fluentd |
| セキュリティ | Falco、CrowdStrike Falcon Sensor |
| ネットワーク | Envoy（サービスメッシュ）、ネットワークプロキシ |
向いているケース
- インスタンス単位でホストレベルのメトリクスやプロセスを監視したい
- プラットフォームチームがエージェントをアプリチームと独立して管理・更新したい
- 全インスタンスで確実にエージェントが稼働していることを保証したい
- サイドカーパターンによるリソースの多重消費を解消したい
- 既存クラスターにデーモンを後から追加したい（稼働中インスタンスにもローリングで展開可能）
デーモン設計のベストプラクティス
CPU・メモリはアプリタスクと別に管理する
デーモンタスク定義はアプリのタスク定義とは独立しているため、CPU・メモリのリソース割り当てを個別に定義できます。AMI の再ビルドやアプリのタスク定義変更は不要です。インスタンスタイプを選定する際は、アプリタスクに加えてデーモンの消費リソースも考慮してください。
デプロイ設定を環境に合わせて調整する
デーモン作成・更新時には以下のデプロイ設定が可能です。本番環境ではベイクタイムと CloudWatch アラームを組み合わせることで、問題の早期検知と自動ロールバックが実現できます。
| 設定項目 | 内容 | デフォルト値 |
|---|---|---|
| Drain percentage | 同時にドレインするインスタンスの割合 | 25% |
| Bake time | 全インスタンス更新後の監視待機時間（分） | 0 分 |
| CloudWatch alarm | デプロイ中の異常検知・自動ロールバック | 無効 |
複数のキャパシティプロバイダーに展開する
1 つのデーモンを複数のキャパシティプロバイダーに関連付けることができます。本番・ステージングなど環境をまたいで一貫したエージェントを展開する際に活用できます。また、後からキャパシティプロバイダーを追加した場合も、そのインスタンスに自動でデーモンが展開されます。
ECS Exec を活用してデーモンをトラブルシュートする
デーモン作成時に ECS Exec を有効化しておくことで、稼働中のデーモンコンテナに対してインタラクティブなコマンド実行が可能になります。デーモン固有の問題調査に役立ちます。
まとめ
Managed Daemons は、これまでアプリのデプロイに混在させるしかなかったエージェント管理を、プラットフォームチームが独立して担えるようにした機能です。インスタンスごとの起動順序保証、停止時のインスタンス自動置き換え、安全なローリング更新。これらが組み合わさることで、サイドカーパターンや DAEMON 戦略では難しかった運用品質が実現します。
ECS Managed Instances を使っているなら、非本番環境で CloudWatch Agent を試してみるところから始めるのが現実的です。既存クラスターへの後付けも可能なため、大きな構成変更なく動作を確認できます。