Amazon ECS マネージドデーモンがタスク間の可視性と通信をサポート

Posted at 2026-06-20

はじめに

2026 年 6 月 10 日、AWS は Amazon ECS Managed Daemons に対して、pidMode / ipcMode によるプロセス可視性・IPC 共有のサポートを発表しました。デーモン定義でこれらを shared に設定するだけで、トレーシング・プロファイリング・セキュリティエージェントをサイドカーではなく独立したデーモンとして配置できるようになります。

ECS 上でこうしたエージェントを運用しているエンジニアの方は、これまでどう管理していたでしょうか。プロセス情報や IPC リソースへのアクセスが必要なエージェントは、各アプリケーションタスク定義にサイドカーとして個別に埋め込む必要があり、運用上の負担になっていました。今回のアップデートはこの問題に直接応えるものです。

何が変わったのか、pidMode / ipcMode がどのような仕組みで動くのか、どのように実装するのか、セキュリティ上どこに気をつけるべきかという順に解説します。サイドカーパターンのエージェント運用に課題を感じているエンジニアの方はもちろん、これから Managed Daemons の導入を検討している方にも読んでいただきたい内容です。

何が変わったのか

項目	Before	After
プロセス・IPC アクセスが必要なエージェントの配置	サイドカーとして各タスク定義に個別に埋め込む	デーモンとして一元管理・独立デプロイ
デーモンのプロセス可視性	他コンテナと同様に隔離（デフォルト none）	pidMode: shared でインスタンス上の全プロセスを参照可能
デーモンの IPC 共有	隔離	ipcMode: shared で他コンテナと IPC ネームスペースを共有可能
エージェント更新時の作業範囲	対象タスク定義をすべて洗い出して修正・再デプロイ	デーモン定義を更新すればローリングデプロイで全インスタンスに反映
追加コスト	—	なし（全 AWS リージョンで利用可能）

従来の課題

Amazon ECS Managed Daemons 自体は 2026 年 4 月に登場しており、ログ収集や軽量な監視エージェントであればデーモンとして配置できるようになっていました。しかし、デーモンも他のアプリケーションコンテナと同様にプロセス・IPC ネームスペースが隔離されていたため、ホスト上の全プロセスを把握する必要がある APM トレーサーや、プロセス起動を監視するセキュリティスキャナーなどは、引き続き各アプリケーションタスク定義にサイドカーとして埋め込まざるを得ませんでした。エージェントを 1 つ更新するだけでも、対象となる全タスク定義を洗い出して修正・再デプロイする必要があったのは、こうした背景があったためです。

pidMode / ipcMode による解決

デーモン定義に pidMode と ipcMode という 2 つの設定が追加され、それぞれを shared に設定することで、デーモンがインスタンス上の全プロセスを参照したり、他コンテナと IPC ネームスペースを共有したりできるようになりました。これにより、プロセスや IPC へのアクセスを必要とするエージェントもデーモンとして一元管理できるようになります。デフォルトは引き続き none のため、既存のデーモンの挙動に影響はありません。

技術的な仕組み

PID namespace と IPC namespace とは

Linux には、プロセスやプロセス間通信（IPC）リソースをコンテナ単位で隔離するための namespace という仕組みがあります。PID namespace はプロセス ID の空間を分離するもので、通常コンテナは自分自身のプロセスしか認識できず、ps コマンドや /proc を見ても他のコンテナのプロセスは見えません。IPC namespace も同様に、共有メモリやセマフォ、メッセージキューといった IPC リソースをコンテナごとに分離します。Docker や ECS のコンテナはデフォルトでこれらの namespace が独立しているため、あるコンテナから別のコンテナのプロセスや IPC リソースに直接アクセスすることはできません。

pidMode / ipcMode の挙動

今回追加された pidMode と ipcMode は、この namespace の分離をデーモン側から緩めるための設定です。pidMode を shared にすると、デーモンコンテナはインスタンス上で稼働する他コンテナのプロセスを参照できるようになります。ipcMode を shared にすると、同一インスタンス上の他コンテナと IPC namespace を共有し、共有メモリやメッセージキューなどを介したやり取りが可能になります。デフォルトはいずれも none で、これまで通りデーモンは他コンテナから隔離された状態が維持されます。

図にすると、none（デフォルト）と shared の違いは次のようになります（pidMode を例にしていますが、ipcMode も同じ考え方です）。

none では各コンテナの PID namespace（図中の ns-1、ns-2、ns-3）がすべて異なり、デーモンを含めて互いのプロセスを見ることができません。shared にすると、すべてのコンテナが同じ PID namespace（ns-shared）に属することになり、デーモンは ps コマンドや /proc 経由で他のコンテナのプロセスを参照できるようになります。ipcMode も同様に、shared にすると共有メモリやメッセージキューといった IPC リソースを介したやり取りが可能になります。pidMode と ipcMode は独立した設定のため、どちらか片方だけを shared にすることもできます。

ここで 1 点注意が必要なのは、通常の ECS タスク定義における pidMode / ipcMode とは指定できる値が異なるという点です。通常のタスク定義では pidMode に host または task、ipcMode に host、task、none のいずれかを指定しますが、デーモン定義では shared と none の 2 値のみが用意されています。同じパラメータ名でも仕様が異なるため、既存のタスク定義の感覚で host を指定しないよう注意してください。

Kubernetes の DaemonSet との比較

同様の仕組みは Kubernetes にも存在します。DaemonSet で稼働する Pod に hostPID: true や hostIPC: true を設定すると、ホストの PID namespace・IPC namespace を共有でき、ノード上の全プロセスを監視するエージェントなどを実現できます。ECS の pidMode / ipcMode は、この DaemonSet の挙動に近い機能を ECS のデーモンに対して提供するものといえます。EKS で同様のエージェント構成を組んだ経験がある方であれば、考え方はそのまま流用できるはずです。

活用シーン

公式発表でも、本機能が主な対象としているのはトレーシング・プロファイリング・セキュリティ系のエージェントだと明記されています。ここでは、どのようなエージェントにどちらのモードが効くのかを、ユースケースごとに整理します。

APM トレーシング（pidMode）

アプリケーションのレイテンシやエラーを可視化する APM トレーシングツールは、対象プロセスの PID を特定して情報を収集する仕組みが一般的です。pidMode: shared を設定したデーモンであれば、インスタンス上で稼働する全アプリケーションコンテナのプロセスをまとめて捕捉できます。

セキュリティ監視（pidMode）

ランタイムセキュリティエージェントは、不審なプロセスの起動や権限昇格をホスト全体で検知する必要があります。pidMode: shared を設定すれば、デーモン 1 つでインスタンス上の全プロセスを監視対象にでき、アプリケーションチーム側にサイドカーの追加を依頼する必要もなくなります。プラットフォームチームがセキュリティポリシーを一元的に適用・更新しやすくなる点もメリットです。

継続的プロファイリング（pidMode）

CPU やメモリのプロファイルを継続的に収集するツールも、アプリケーションプロセスへのアクセスが前提になります。pidMode: shared を設定したデーモンとして配置することで、アプリケーションコードを変更することなく、インスタンス上の各コンテナのプロファイルを横断的に取得できます。

ログ・メトリクスの集約（ipcMode）

複数コンテナから出力されるログやメトリクスを、共有メモリやメッセージキューといった IPC 経由で効率的に収集したい場合は ipcMode が有効です。ipcMode: shared を設定したデーモンが集約ポイントとなり、各アプリケーションコンテナは通常の IPC 呼び出しと同じ感覚でデータを渡せます。高スループットなデータ転送が必要なケースでは、ネットワーク経由の収集よりオーバーヘッドを抑えられる場合があります。

有効化・実装手順

前提条件

ECS Managed Daemons は、ECS Managed Instances キャパシティプロバイダーでのみサポートされています。pidMode / ipcMode を使う場合も同様で、事前に Managed Instances キャパシティプロバイダーを構成したクラスターが必要です。

Step 1：pidMode / ipcMode を設定したデーモンタスク定義を登録する

デーモンタスク定義は、通常の ECS タスク定義とは別の専用リソースとして登録します。以下は、プロセス監視エージェントを想定した JSON 例です。

{
    "family": "process-monitoring-daemon",
    "pidMode": "shared",
    "containerDefinitions": [
        {
            "name": "monitoring-agent",
            "image": "my-monitoring-agent:latest",
            "essential": true,
            "memoryReservation": 256
        }
    ]
}

ipcMode も同じ要領で、トップレベルに "ipcMode": "shared" を追加するだけです。ファイルを daemon-taskdef.json として保存し、次のコマンドで登録します。

aws ecs register-daemon-task-definition --cli-input-json file://daemon-taskdef.json

Step 2：キャパシティプロバイダーと紐付けてデーモンを作成する

登録したデーモンタスク定義を、ECS Managed Instances キャパシティプロバイダーと紐付けてデーモンとして作成します。<daemon-task-definition-arn> には Step 1 のレスポンスで返ってくる ARN を、<capacity-provider-arn> には対象のキャパシティプロバイダーの ARN を指定してください。

aws ecs create-daemon \
    --daemon-name process-monitoring-daemon \
    --cluster-arn <cluster-arn> \
    --daemon-task-definition-arn <daemon-task-definition-arn> \
    --capacity-provider-arns <capacity-provider-arn>

これで、対象キャパシティプロバイダー配下の各インスタンスにデーモンが 1 つずつ自動的に配置されます。

設定の確認

ECS コンソールで対象クラスターを開き、Daemons タブから作成したデーモンのステータスが ACTIVE になっていることを確認します。既存のデーモンタスク定義を更新したい場合は、新しいリビジョンを register-daemon-task-definition で登録した上で update-daemon コマンドを実行すると、ローリングデプロイで全インスタンスに反映されます。

セキュリティ・注意点

namespace 共有はコンテナ分離を弱める設定

pidMode / ipcMode を shared にすると、デーモンは他のコンテナのプロセスや IPC リソースに一段深くアクセスできるようになります。これは裏を返せば、デーモンコンテナがコンテナ間の隔離境界の一部を越える権限を持つということでもあります。たとえば pidMode: shared を設定したデーモンが侵害された場合、攻撃者はインスタンス上の全アプリケーションプロセスの情報を取得できてしまう可能性があります。トレーシングやセキュリティ監視といった正当な目的のために用意された設定ではありますが、便利だからといって安易に有効化すべき設定ではないという点は意識しておく必要があります。

信頼できるイメージ・エージェントに限定する

shared を設定するデーモンには、出所の明確なコンテナイメージを使うことが重要です。サードパーティ製のエージェントを採用する場合は、提供元の信頼性やイメージの署名・脆弱性スキャン結果を確認した上で導入するのが望ましいです。デーモンは対象キャパシティプロバイダー配下の全インスタンスに自動的に配置されるため、1 つのデーモンの脆弱性がクラスター全体に影響しうる点も踏まえておく必要があります。

IAM ロールは最小権限で構成する

デーモンタスク定義には taskRoleArn / executionRoleArn を指定できます。pidMode / ipcMode による namespace 共有とは別の話ですが、デーモンに付与する IAM ロールについても、必要な API 操作のみを許可する最小権限の原則に従うことが望ましいです。

デフォルトは none のまま変更しない

本当に必要な場合に限定して shared を設定し、特に理由がなければデフォルトの none のままにしておくのが安全です。

まとめ

Amazon ECS Managed Daemons に pidMode / ipcMode が追加され、プロセス情報や IPC リソースへのアクセスを必要とするトレーシング・プロファイリング・セキュリティエージェントも、サイドカーではなくデーモンとして一元管理できるようになりました。Managed Daemons 自体は 2026 年 4 月に登場したばかりで、今回はその 2 ヶ月後の拡張にあたります。

namespace の共有はコンテナ間の隔離を弱める設定でもあるため、セキュリティ・注意点の章で触れた通り、信頼できるエージェントに限定して使うことが重要です。

本機能は全 AWS リージョンで追加料金なしに利用できます。まずは検証環境やステージング環境でサイドカーからデーモンへの置き換えを試し、想定通りプロセスや IPC リソースが見えるかを確認してから本番展開を検討するのが現実的です。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up