ECS daemons explained: DAEMON services vs Managed Daemons

Log shippers, metrics agents, security scanners and tracing collectors share one requirement: exactly one copy on every host. ECS has two ways to do that, and since April 2026 they work quite differently.

Classic DAEMON services

A normal ECS service runs a desired number of tasks. A service with the DAEMON scheduling strategy instead runs one task on every container instance in the cluster:

aws ecs create-service \
  --cluster production \
  --service-name log-agent \
  --task-definition fluent-bit:12 \
  --scheduling-strategy DAEMON

What changes compared to a normal service:

There is no desired count and no service auto scaling. The number of tasks follows the number of instances.
Placement constraints decide which instances get a task, and ECS keeps checking them. A task that stops matching is stopped.
Placement strategies don’t apply.

The limits:

EC2 only. Fargate doesn’t support the DAEMON strategy, because there are no hosts to run on.
Rolling update deployments only. CODE_DEPLOY and EXTERNAL deployment controllers aren’t supported.
The daemon is just another task. When a new instance joins, ECS doesn’t guarantee that the daemon lands before application tasks take the space. A busy instance can end up without its agent.
Shared ownership. Platform teams own the agents, but the agents run as tasks next to the app teams’ services, so changes to one can affect the other.

The Fargate workaround: sidecars

On Fargate, per-host agents become per-task sidecars: a FireLens log router, an OpenTelemetry collector or a security agent added as a second container to every task definition. It works, but every agent upgrade means touching every task definition and redeploying every service.

Managed Daemons

Managed Daemons, announced in April 2026, are a separate ECS resource built for platform teams. They only work with ECS Managed Instances capacity providers, where AWS provisions and patches the EC2 instances for you.

You describe the daemon in its own daemon task definition and attach it to capacity providers:

aws ecs register-daemon-task-definition \
  --cli-input-json file://cloudwatch-agent-daemon.json

aws ecs create-daemon \
  --cli-input-json file://create-daemon.json

ECS then runs exactly one daemon task on every instance those capacity providers launch. What’s different from a DAEMON service:

Lifecycle ordering. Daemons start before application tasks on an instance and stop after them, so agents see everything from the first log line to the last.
Independent rollouts. Updating a daemon is a rolling deployment of its own. ECS drains a share of instances at a time (the drain percentage, 25% by default), brings up replacements with the new daemon version and moves application tasks over. App teams don’t redeploy anything.
Critical or not. A daemon can be marked critical. If a critical daemon fails, ECS drains and replaces the instance, because an instance without its security agent shouldn’t run workloads. A non-critical daemon never blocks or drains an instance.
Host access. Daemons can be privileged, get extra Linux capabilities and bind-mount host paths, which is what most agents need.

And the constraints:

Fixed networking. Daemons use a special daemon_bridge network mode. All daemons on an instance share one network namespace, reachable from application tasks at 169.254.172.2, so two daemons can’t listen on the same port.
No volumes. Daemon task definitions don’t support EBS, EFS, FSx for Windows File Server, Docker volumes or ephemeral storage. Host bind mounts are the way to persist data.
Managed Instances only. Classic EC2 capacity providers still use DAEMON services.

Which one to use

You run on	Use
Fargate	Sidecars in each task definition
EC2 launch type, Auto Scaling group capacity providers	`DAEMON` services
ECS Managed Instances	Managed Daemons

If you’re already considering Managed Instances, Managed Daemons are a strong reason to move. The platform team gets its own deployment path for agents, application teams stop carrying sidecars, and the “instance came up without its agent” class of problem goes away. For more on choosing a compute option, see Fargate vs EC2 for Amazon ECS.