# ECS adds agent-connectivity health events and managed recovery > ECS exposes impaired agent connectivity across compute options, with automatic recovery for Fargate and Managed Instances and events for EC2 operators. Canonical URL: https://www.devobs.io/news/news-aws-ecs-agent-connectivity/ By: Amara Okafor Published: 2026-09-06T11:58:54.635Z Updated: 2026-09-06T11:58:54.635Z Event date: 2026-08-24 Section: Cloud Amazon ECS added agent-connectivity health monitoring on August 24, exposing a new event when a container instance loses contact with the ECS control plane. The recovery behavior depends on how the workload's compute is managed. ## Detection is shared; recovery ownership differs The [AWS announcement](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ecs-agent-connectivity-health/) describes automatic draining, replacement capacity, and deregistration for impaired instances under Fargate and ECS Managed Instances. For ECS on EC2, customers can use the new health-change event to drive their own replacement workflows. That distinction is important for operators reading the launch headline. A cluster may receive the signal without acquiring the same automatic remediation behavior as a managed compute option. Our analysis: infrastructure recovery and application recovery should be observed separately. Replacing capacity can restore a place to run tasks, but teams still need evidence that the service has resumed processing requests or jobs correctly. ## Connect the event to an operational result For an EC2-backed cluster, identify the existing instance-replacement owner before adding another automation path. Coordinate the event handler with capacity management so two systems do not issue conflicting recovery actions. Test how the application handles tasks being drained and recreated. Review in-flight jobs, lease ownership, connection shutdown, and readiness checks. Record whether work is resumed, retried, or explicitly abandoned after replacement. For managed options, update alerts and runbooks so responders understand the recovery already in progress. A page that merely reports lost agent connectivity may otherwise encourage manual intervention that duplicates the platform's action. Start with a controlled failure exercise in a nonproduction cluster. The acceptance condition should be restored application behavior and a clear event trail, not simply the appearance of a replacement instance. ## Source references -