What's New

Amazon ECS Managed Daemons now support two new task definition parameters—pidMode and ipcMode—that enable daemon tasks to share the host's PID and IPC namespaces with application containers running on the same ECS Managed Instance. This allows observability, tracing, profiling, and security agents to be deployed as standalone daemons rather than embedded sidecars, giving them the process-level and inter-process communication visibility they require. The feature is available across all AWS Regions at no additional cost.

How It Works

• pidMode parameter: When set to "shared", the daemon task can enumerate and inspect all processes running on the underlying EC2 instance, enabling use cases like profiling agents (e.g., eBPF-based tools) and security scanners that need host-level process visibility.
• ipcMode parameter: When set to "shared", the daemon task joins the same IPC namespace as other containers on the instance, allowing it to access shared memory segments, semaphores, and message queues used by application tasks.
• Default isolation: Both parameters default to "none", preserving the existing security posture where daemons are fully isolated from application containers and other tasks unless explicitly configured otherwise.
• Daemon lifecycle guarantees: ECS places exactly one daemon task per managed instance and ensures daemons start before any application tasks, so agents are always present before workloads begin executing.
• Independent deployment: Daemon task definitions are a distinct resource type from standard ECS task definitions, registered via register-daemon-task-definition and managed separately from application task definitions.
• Configuration methods: The new parameters can be set through the AWS Management Console, AWS CLI, CloudFormation, or AWS SDKs by specifying pidMode or ipcMode in the daemon task definition JSON.

Why It's Important

• Eliminates sidecar sprawl: Previously, agents requiring PID or IPC access had to be embedded as sidecar containers in every application task definition, creating maintenance overhead and coupling platform concerns to application definitions.
• Enables advanced observability tooling: Modern APM, distributed tracing (e.g., OpenTelemetry), and continuous profiling tools (e.g., Datadog, Pyroscope, eBPF-based agents) fundamentally require host-level process visibility, which was previously impossible without privileged sidecars.
• Strengthens security posture: Security agents such as runtime threat detection tools (e.g., Falco, CrowdStrike) need to observe all processes on a host; running them as managed daemons ensures consistent, tamper-resistant coverage across every instance.
• Decouples platform and application teams: Platform teams can now own, deploy, and update observability and security agents independently without requiring application teams to modify their task definitions.
• Guarantees consistent coverage: Because ECS enforces exactly one daemon per instance and starts it before application tasks, there are no gaps in agent coverage during instance startup or task churn.

How It's Different

• Versus sidecar pattern: Sidecars are co-located within a specific task and share only that task's namespaces; managed daemons with pidMode=shared can see all processes across all tasks on the instance, providing true host-wide visibility.
• Versus host-level EC2 agents: Traditional EC2-installed agents (e.g., SSM Agent, CloudWatch Agent) run outside of ECS lifecycle management; managed daemons are fully lifecycle-managed by ECS, including placement, startup ordering, and updates via ECS APIs.
• Versus privileged containers in task definitions: Embedding a privileged container in an application task definition couples the agent to that specific workload; managed daemons are decoupled, centrally managed, and applied uniformly across all tasks on an instance.
• Versus standard ECS daemon service type: The ECS daemon service scheduling strategy deploys one task per instance but does not provide the pidMode/ipcMode sharing semantics or the guaranteed pre-application startup ordering that ECS Managed Daemons offer.
• Versus self-managed DaemonSets (Kubernetes): For teams using ECS rather than Kubernetes, this feature brings DaemonSet-like capabilities natively into ECS without requiring a migration to EKS.

When to Prefer It

• Distributed tracing agents: Use when deploying agents like the AWS X-Ray daemon, OpenTelemetry Collector, or Datadog APM that need to correlate traces across all processes on an instance without being embedded in each application task.
• Continuous profiling: Use when running eBPF-based or sampling profilers (e.g., Pyroscope, Parca) that attach to running processes by PID and require visibility into the full process tree on the host.
• Runtime security monitoring: Use when deploying tools like Falco or CrowdStrike Falcon that perform syscall-level or process-level threat detection and must observe all workloads on an instance.
• Shared memory IPC consumers: Use when a monitoring or coordination agent communicates with application containers via POSIX shared memory or System V IPC primitives, requiring a common IPC namespace.
• Platform-wide agent standardization: Use when a central platform team needs to enforce uniform agent deployment across all ECS workloads without requiring individual application teams to update their task definitions.
• Regulated or compliance-sensitive environments: Use when audit and compliance requirements mandate that security and logging agents cannot be disabled or omitted by application teams, leveraging the daemon's independent lifecycle.

Availability

• GA Status: Generally available as of June 10, 2026.
• Regional availability: Available in all AWS commercial and GovCloud Regions where Amazon ECS Managed Instances capacity providers are supported.
• Pricing: No additional charge for the pidMode and ipcMode feature itself; standard ECS and EC2 pricing for the underlying Managed Instances applies.
• Prerequisite: Requires ECS Managed Instances capacity providers; this feature is not applicable to standard ECS clusters backed by self-managed EC2 instances or AWS Fargate.
• Default behavior: Both pidMode and ipcMode default to "none", so existing daemon definitions are unaffected and no opt-out is required.
• Configuration surface: Supported via AWS Management Console, AWS CLI (register-daemon-task-definition), AWS CloudFormation, and AWS SDKs.

Related Resources

• https://aws.amazon.com/ecs/managed-instances/
• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons-task-definitions.html#managed-daemons-taskdef-parameters