AWS Builder Center

Builder Center

Amazon ECS Managed Daemons now support inter-task visibility and communication

Amazon ECS Managed Daemons now support pidMode and ipcMode, letting you run tracing, profiling, and security agents as centrally managed daemons instead of per-task sidecars. This post covers how the feature works, how to implement it, and what to watch out for from a security perspective.

haruki

Introduction

On June 10, 2026, AWS announced support for process visibility and IPC sharing via pidMode and ipcMode in Amazon ECS Managed Daemons. By setting either of these to shared in a daemon definition, you can now run tracing, profiling, and security agents as standalone daemons instead of sidecars.
If you're running this kind of agent on ECS, you know the drill: agents that need access to process information or IPC resources had to be embedded individually as sidecars in every application task definition, which turned into an ongoing operational burden. This update addresses that problem directly.
This post walks through what changed, how pidMode and ipcMode work under the hood, how to implement them, and what to watch out for from a security standpoint. Whether you're already frustrated with managing sidecar agents on ECS or are just evaluating Managed Daemons for the first time, this is for you.

What changed

ItemBeforeAfter
Agents requiring process / IPC accessEmbedded individually as sidecars in each task definitionCentrally managed and deployed as an independent daemon
Daemon process visibilityIsolated like any other container (default: none)pidMode: shared exposes every process on the instance
Daemon IPC sharingIsolatedipcMode: shared enables sharing an IPC namespace with other containers
Scope of work to update an agentFind and redeploy every affected task definitionUpdate the daemon definition once; a rolling deployment reaches every instance
Additional cost—None (available in all AWS Regions)

The problem before this update

Amazon ECS Managed Daemons itself launched in April 2026, and agents like log collectors or lightweight monitoring tools could already run as daemons. But daemons were still isolated from process and IPC namespaces just like any other container, so APM tracers that need visibility into every process on the host, or security scanners watching for process launches, still had to be embedded as sidecars in every application task definition. That's why updating a single agent meant finding and redeploying every affected task definition.

How pidMode and ipcMode solve it

Two new settings, pidMode and ipcMode, were added to daemon definitions. Setting either to shared lets the daemon see every process on the instance, or share an IPC namespace with other containers, respectively. This means agents that need process or IPC access can now also be managed centrally as daemons. The default remains none, so existing daemons are unaffected.

How it works

PID and IPC namespaces

Linux provides namespaces to isolate processes and inter-process communication (IPC) resources on a per-container basis. A PID namespace isolates the process ID space: a container normally only sees its own processes, so running ps or looking at /proc won't reveal processes from other containers. IPC namespaces work the same way for resources like shared memory, semaphores, and message queues. Because Docker and ECS containers have independent namespaces by default, one container can't directly reach another container's processes or IPC resources.

What pidMode and ipcMode actually do

pidMode and ipcMode relax this isolation specifically for the daemon. Setting pidMode to shared lets the daemon container see the processes running in other containers on the instance. Setting ipcMode to shared lets it share an IPC namespace with other containers on the same instance, enabling communication through shared memory, message queues, and similar mechanisms. Both default to none, which keeps the daemon isolated from other containers just as before.
Here's what none (the default) and shared look like side by side, using pidMode as the example (ipcMode works the same way):
With none, each container has its own PID namespace (ns-1, ns-2, ns-3 in the diagram), so no container, including the daemon, can see another's processes. With shared, every container belongs to the same PID namespace (ns-shared), and the daemon can inspect other containers' processes via ps or /proc. ipcMode behaves the same way for IPC resources such as shared memory and message queues. Because pidMode and ipcMode are independent settings, you can set just one of them to shared if that's all you need.
One thing worth flagging: the values accepted by pidMode and ipcMode here differ from those in a regular ECS task definition. A standard task definition accepts host or task for pidMode, and host, task, or none for ipcMode. A daemon definition only accepts shared or none. The parameter names are the same, but the semantics aren't, so don't reach for host out of habit.

Comparison with Kubernetes DaemonSets

Kubernetes has an equivalent mechanism. Setting hostPID: true or hostIPC: true on a Pod running as part of a DaemonSet shares the host's PID and IPC namespaces, enabling agents that need visibility into every process on a node. ECS's pidMode and ipcMode bring a similar capability to ECS daemons. If you've built agents this way on EKS before, the mental model carries over directly.

Use cases

The official announcement specifically calls out tracing, profiling, and security agents as the primary targets for this feature. Here's a breakdown of which mode applies to which kind of agent.

APM tracing (pidMode)

APM tracing tools that visualize latency and errors typically work by identifying a target process's PID and collecting data from it. With pidMode: shared, a single daemon can capture every application container's processes on the instance at once.

Security monitoring (pidMode)

Runtime security agents need to detect suspicious process launches or privilege escalation across the whole host. With pidMode: shared, one daemon can monitor every process on the instance, removing the need to ask application teams to add a sidecar. This also makes it easier for platform teams to apply and update security policy centrally.

Continuous profiling (pidMode)

Tools that continuously collect CPU and memory profiles also need access to application processes. Deploying them as a daemon with pidMode: shared lets you collect profiles across every container on the instance without touching application code.

Log and metric aggregation (ipcMode)

If you want to efficiently collect logs or metrics from multiple containers via IPC, such as shared memory or message queues, ipcMode is what you need. A daemon with ipcMode: shared acts as an aggregation point, and each application container can hand off data the same way it would for any other IPC call. For high-throughput data transfer, this can reduce overhead compared with collecting data over the network.

Getting started

Prerequisites

ECS Managed Daemons is only supported on the ECS Managed Instances capacity provider. The same applies to pidMode and ipcMode, so you'll need a cluster with a Managed Instances capacity provider already configured.

Step 1: Register a daemon task definition with pidMode / ipcMode

A daemon task definition is a dedicated resource, separate from a standard ECS task definition. Here's a JSON example for a process-monitoring agent:
1
2
3
4
5
6
7
8
9
10
11
12
{
"family": "process-monitoring-daemon",
"pidMode": "shared",
"containerDefinitions": [
{
"name": "monitoring-agent",
"image": "my-monitoring-agent:latest",
"essential": true,
"memoryReservation": 256
}
]
}
ipcMode works the same way; just add "ipcMode": "shared" at the top level. Save the file as daemon-taskdef.json and register it with:
1
aws ecs register-daemon-task-definition --cli-input-json file://daemon-taskdef.json

Step 2: Create a daemon tied to a capacity provider

Associate the daemon task definition you just registered with an ECS Managed Instances capacity provider to create the daemon. Use the ARN returned in the Step 1 response for <daemon-task-definition-arn>, and the ARN of your capacity provider for <capacity-provider-arn>.
1
2
3
4
5
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>
ECS will now automatically place one daemon on each instance under the target capacity provider.

Verifying the setup

Open the target cluster in the ECS console and check the Daemons tab to confirm the daemon's status is ACTIVE. To update an existing daemon task definition, register a new revision with register-daemon-task-definition, then run update-daemon; this triggers a rolling deployment that rolls the change out across every instance.

Security considerations

Namespace sharing weakens container isolation

Setting pidMode or ipcMode to shared gives the daemon deeper access to other containers' processes and IPC resources. In other words, the daemon container gains permission to cross part of the isolation boundary between containers. If a daemon configured with pidMode: shared were compromised, for example, an attacker could potentially obtain information about every application process on the instance. This setting exists for legitimate purposes like tracing and security monitoring, but it isn't something to enable casually just because it's convenient.

Stick to trusted images and agents

Any daemon configured with shared should run a container image from a clearly trusted source. If you're adopting a third-party agent, verify the vendor's reputation and the image's signing and vulnerability scan results before deploying it. Because a daemon is automatically placed on every instance under its capacity provider, a vulnerability in a single daemon can affect the entire cluster.

Scope IAM roles to least privilege

A daemon task definition can specify taskRoleArn and executionRoleArn. Separately from namespace sharing, the IAM role attached to a daemon should also follow the principle of least privilege, allowing only the API calls it actually needs.

Leave the default as none unless you need shared

Set shared only where it's genuinely needed, and leave the default of none in place otherwise; that's the safer default posture.

Conclusion

Amazon ECS Managed Daemons now support pidMode and ipcMode, so agents like tracing, profiling, and security tools that need process or IPC access can be centrally managed as daemons instead of sidecars. Managed Daemons itself only launched in April 2026, and this update arrives two months later.
Because namespace sharing weakens isolation between containers, as covered in the security considerations section above, it's worth limiting shared to agents you actually trust.
This feature is available in all AWS Regions at no additional cost. A reasonable approach is to first try replacing a sidecar with a daemon in a test or staging environment, confirm that process and IPC visibility behave as expected, and then consider a production rollout.

Additional resources

# amazon-ecs# devops# linux# kubernetes# security
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article