# Amazon ECS now separates control-plane failures from auxiliary-daemon failures on managed capacity ECS now has two distinct failure paths for managed container capacity: lost ECS-agent connectivity can trigger automatic repair, while auxiliary Managed Daemons can be marked non-critical so their failure does not churn otherwise healthy application tasks. The newer `critical=false` daemon control changes ECS Managed Instances from an all-daemons-are-instance-critical model to an explicit reliability trade-off: logging, metrics or security agents can fail without forcing application workloads off the host, while ECS still emits health events and action logs. - Status: Active - Published: 2026-09-01T06:27:21+12:00 - Updated: 2026-09-04T21:03:52+12:00 - Categories: SaaS, Cloud & Infrastructure, Cloud Platforms, Deployment & DevOps, SaaS Operations - Tags: Amazon ECS, automatic recovery, AWS, container orchestration, high availability - Canonical HTML: https://beyondthe.news/dossiers/amazon-ecs-agent-connectivity-health-automatic-repair ## Latest material change Adds the September 3 non-critical Managed Daemons control. ECS Managed Instances can now keep application tasks running and accept new placement when an auxiliary logging/metrics/security daemon fails, instead of always draining and replacing the instance. This materially extends the dossier's ECS failure-repair semantics. ## What changed Amazon ECS added a second managed-capacity failure control on September 3, 2026. The August `AGENT_CONNECTIVITY` health signal detects when an ECS container instance loses contact with the ECS control plane; on Fargate and ECS Managed Instances, AWS can drain and replace impaired capacity automatically. Managed Daemons on ECS Managed Instances previously followed a similarly strict rule: daemon failure could make the instance unhealthy and trigger drain/replacement. AWS now lets platform teams set a Managed Daemon's `critical` parameter to `false`. If a non-critical logging, metrics, networking or security daemon fails, stops or becomes unhealthy, the instance stays active, existing application tasks continue, ECS can place new application tasks, and instance registration is not blocked. ECS still emits EventBridge events and service action logs so the auxiliary failure can be repaired without automatically disrupting the application workload. ## Why it matters Container hosts run two different classes of software: application tasks whose availability is usually the business objective, and cross-cutting agents that provide logging, monitoring, security or networking functions. Treating every auxiliary-agent failure as an instance failure can turn an observability problem into an application outage. The new non-critical mode lets operators make that trade-off explicitly. It also creates a governance obligation: an agent that is merely convenient can be non-critical, while a security or networking daemon whose absence invalidates the host's policy may still need to remain critical. ## ECS still repairs lost control-plane connectivity The `AGENT_CONNECTIVITY` health signal monitors whether a container instance can still communicate with the ECS control plane. Infrastructure problems such as network or host degradation can leave capacity physically present but uncontrollable. Fargate and ECS Managed Instances can drain and replace that impaired capacity automatically; ECS on customer-managed EC2 surfaces the event for the operator's own repair workflow. ## Managed Daemons no longer have to be instance-critical ECS Managed Daemons run one centrally managed agent per ECS Managed Instance for functions such as security, observability and networking. With the September 3 release, a daemon can be configured with `critical=false`. Failure of that daemon no longer marks the instance for drain/replacement, so current application tasks remain in place and new application tasks can still be scheduled. ## The default reliability choice now belongs to the platform team A critical daemon preserves the earlier guarantee that ECS repairs the instance when that agent is not healthy. A non-critical daemon favors application continuity over guaranteed auxiliary-agent coverage. Teams should classify daemons by consequence rather than setting all of them non-critical for convenience. ## Failure visibility remains available without workload churn AWS emits an EventBridge event when a non-critical daemon fails to start and records service action logs for critical and non-critical daemon operations. That lets operators alert or automate a daemon-specific repair path while leaving application tasks alone. ## Application health still needs separate controls Neither agent connectivity nor daemon health proves that an application is serving correctly. Container health checks, load-balancer checks and application observability still cover different failure modes and should remain part of the reliability model. ## Key details - Amazon ECS introduced the `AGENT_CONNECTIVITY` container-instance health event in August 2026. - The agent-connectivity signal is available for Fargate, ECS Managed Instances and ECS on EC2. - Fargate and ECS Managed Instances can automatically drain and replace capacity after ECS-agent connectivity impairment. - On September 3, ECS Managed Daemons added a `critical=false` option for ECS Managed Instances. - When a non-critical daemon fails, stops or becomes unhealthy, the container instance remains active and existing application tasks continue running. - ECS continues placing new application tasks on an instance with a failed non-critical daemon and instance registration is not blocked. - EventBridge events and service action logs remain available for daemon failures. - Non-critical Managed Daemons are available wherever ECS Managed Daemons are supported. ## Builder takeaways - Inventory Managed Daemons and classify each by whether losing it should actually make the host unacceptable for application traffic. - Use `critical=false` for auxiliary agents where application continuity is more important than immediate agent coverage, rather than treating every logging or metrics failure as a reason to churn workloads. - Keep security, networking or compliance daemons critical when their absence means the instance no longer satisfies your operating policy. - Route daemon failure events into EventBridge and action-log monitoring so non-critical does not become invisible. - For ECS on EC2, continue wiring `AGENT_CONNECTIVITY` into your own replacement automation; the new non-critical-daemon behavior is specific to ECS Managed Instances. - Keep application and load-balancer health checks because these ECS signals cover the management/host layer, not service correctness. ## What to watch - Whether AWS adds daemon-specific restart/remediation policies that sit between simple alerting and full instance replacement. - Whether non-critical daemon state becomes available in additional scheduling or placement constraints. - Operational evidence on how teams classify security/observability agents between critical and non-critical modes. - Whether automatic connectivity repair expands further for customer-managed ECS on EC2 capacity. ## Uncertainties - AWS does not publish a universal detection or recovery time for agent-connectivity failures. - A non-critical daemon can leave an application running without its normal logging, metrics, networking or security coverage; whether that is acceptable is workload-specific. - The new non-critical mode applies to ECS Managed Daemons on ECS Managed Instances, not every daemon-style workload on ECS. ## Timeline - **2026-08-24 — ECS adds agent-connectivity health and repair:** ECS begins surfacing `AGENT_CONNECTIVITY`; managed compute can automatically replace capacity that loses control-plane connectivity. - **2026-09-03 — Managed Daemons gain a non-critical mode:** ECS Managed Instances can keep application tasks running and accept new placement when a daemon configured `critical=false` fails. ## Sources - [Amazon ECS now automatically detects and repairs container instances with impaired agent connectivity](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ecs-agent-connectivity-health/) — Amazon Web Services · primary announcement · 2026-08-24T00:00:00+12:00. Primary description of the agent-connectivity health event and automatic managed-capacity repair behavior. - [Amazon ECS Managed Daemons now support non-critical daemons](https://aws.amazon.com/about-aws/whats-new/2026/09/ecs-managed-daemons-non-critical/) — Amazon Web Services · primary announcement · 2026-09-03T00:00:00+12:00. Primary source for `critical=false`, continued task placement/application execution and daemon failure events. - [Amazon ECS Managed Daemons](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons.html) — Amazon ECS Developer Guide · primary documentation. Current architecture and lifecycle documentation for centrally managed daemon tasks on ECS Managed Instances.