前回、ECSの新たなフルマネージド型コンピューティングオプションECS Managed Instanceを試してみたの記事で、ECS on EC2, Fargate に加わる新たなコンピュートオプションである ECS Managed Instance を紹介しました。
性質的にはちょうど ECS on EC2 と Fargate の中間にあたる存在で、AWS側がEC2のOSなどを管理しつつ、Fargateにはなかったインスタンス選択の柔軟性を確保できることにより、従来のFargateでは利用できなかったGPUや広帯域ネットワークインスタンスなどが利用可能となります。
2026年4月1日、さらにこのサービスを便利にする Managed Daemon という機能がリリースされました。
Managed Daemon をご利用いただくためには、まず最初にコンテナのデプロイパターンであるサイドカーを知ってもらう必要があります。
サイドカーコンテナとは
コンテナを使ったシステム設計の話題で「サイドカーパターン」という言葉を耳にすることがあります。名前の由来はバイクのサイドカーです。バイク（メインの乗り物）に横付けされたサイドカー（補助的な乗り物）のように、メインのアプリコンテナに横付けして補助的な役割を担うコンテナのことを指します。
サイドカーコンテナとは、メインのアプリコンテナと同じタスク内で動作する補助的なコンテナのことです。
アプリの本来の機能とは直接関係しない、横断的な処理——たとえばログの収集、監視、トレース、プロキシなど——をアプリコンテナから切り出して別コンテナに担わせる設計パターンです。「ログ収集くらいアプリに組み込めばいいのでは？」と思うかもしれません。しかしそれをすると以下の問題が生じます。
- アプリのコードに監視・ログ・セキュリティなどの処理が混在し、複雑になる
- 言語やフレームワークが異なるアプリごとに同じ処理を重複実装しなければならない
- エージェントを更新するたびにアプリ自体を修正・再デプロイする必要がある
サイドカーとして分離することで、アプリチームはアプリの開発に集中でき、プラットフォームチームはエージェントを独立して管理できるようになります。
タスク定義とサイドカーコンテナ
サイドカーパターンが成立する重要な前提として、同じタスク内のコンテナはネットワーク名前空間を共有しています。つまりコンテナ同士は localhost で通信できます。このためタスク定義にはアプリケーション本体のコンテナと補助機能を担うサイドカーコンテナを同居させることが一般的です。このパターンのデメリットとして、補助機能側のサイドカーコンテナに変更が入った場合、アプリコンテナと同じタスク定義に含まれているため、アプリチームと調整の上でタスク定義を変更し、アプリごと再デプロイしなければなりません。監視エージェントのバージョンを1つ上げるだけでも、アプリの再デプロイが発生するのです。
ここで登場するのがManaged Daemonです。
Managed Daemon のメリット
Managed Daemon はこうしたサイドカーパターンの運用上の課題を解決するために、ECS Managed Instances に追加された機能です。やっていること自体は従来のサイドカーパターンと変わりません。デーモンはあくまでEC2インスタンス上で動作する別コンテナです。変わったのは「管理方法」です。
従来はアプリと同じタスク定義にサイドカーを含めていましたが、Managed Daemon ではデーモン専用のタスク定義が分離されました。プラットフォームチームはデーモン定義だけを独立して管理・更新でき、アプリチームへの影響はゼロです。
またデーモンはインスタンスごとに1つだけ起動することが保証されます。タスクが何個動いていても、エージェントは1つだけ——これによりリソースの重複が解消されます。
加えて、非常に重要な特徴ですがデーモンはアプリタスクより先に起動し、最後にドレインされることが保証されています。ログや監視エージェントが確実に稼働した状態でアプリが起動するため、起動直後のログが欠損するといった問題も防ぐことができます。
さっそくやってみる
ではやっていきます。まずは前回の記事の内容を終わらせnginxが起動するところまでを終わらせておきます。
https://serverless.co.jp/blog/zabb2q9cm/
左ペインの Daemon Task definitions から作業を進めます。上記の手順では Task Definitions からタスク定義を作成しました。タスク定義の中には1つのコンテナイメージが指定されています。従来の方式ではそこに補助機能用サイドカーコンテナを追加する場合、一つのタスク定義が複数のコンテナイメージの設定を持つこととなるため、どれかの設定が変更されると再デプロイが発生することとなります。それを避けるために 1タスク定義 = 1コンテナイメージ として複数のタスク定義を持つとどうなるか？と言えばサイドカーコンテナアーキテクチャパターンのメリットであるローカル通信が行えなくなる課題があります。この課題を解決するのが Managed Daemon です。
Create new daemon task definition をクリックします。
適当な名前を付けて、Roleを設定します。 Task role は起動するデーモン用コンテナがAWSサービスを呼び出す際に使われます。この手順ではCloudWatch Agentを指定しますが、その場合 CloudWatch Agent を呼び出すパーミッションを持ったIAMロールが必要となります。
Task execution role はアプリケーション基本機能をつかさどるタスク定義で指定したものと同じで問題ありません。
Task Size は少し入力に注意が必要です。vCPUは空欄でもいいのですが、入力したい場合整数値だけではエラーとなります。
1.0 vCPU と入力します。次の画面で補助機能をつかさどるコンテナイメージを指定します。この手順では`CloudWatch Agent`用パブリックイメージを指定します。public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest
後はデフォルトのまま Create をクリックします。
無事作成されました！
つぎに起動済 Cluster に対してこのデーモンを追加してみます。Clusterの詳細画面に Daemons というタブが出来ています。
Create をクリックします。
先ほど作成したDaemon Definitions を指定します。
すでに起動しているClusterが使用しているCapacity Providerを指定します。
Create をクリックしてしばらく待ちます。
もう1種類EC2 インスタンスが起動してきます。
Daemon も無事起動しています。
このデーモン用コンテナはタスク定義に基づいて起動しているコンテナとローカル通信ができるようになっているのが今回のアップデートのポイントです。