Every fleet operator has met this ghost eventually: the instance that looks perfectly healthy in every dashboard except the one that matters. CPU normal, memory fine, EC2 status checks green — but the ECS agent on that box quietly stopped talking to the control plane hours ago, and every task sitting on it is now running blind. The new AGENT_CONNECTIVITY health event in Amazon ECS exists specifically to kill that ghost, and it does it automatically, for free, in every AWS Commercial and GovCloud (US) Region. Here’s what it’s actually watching, and what changes depending on which compute type your tasks run on.
What “agent connectivity” actually monitors
The ECS agent isn’t your application — it’s the daemon (or, on Fargate, the managed component) that maintains a persistent connection back to the ECS control plane, reporting task state and pulling instructions. That channel can get severed without anything else on the host looking wrong: an EBS volume degrading mid-write, a host thermal event throttling the network stack, a security group or route table change cutting the path to the control plane endpoint, or a plain old network partition. None of that trips an EC2 status check. It does, however, break the one thing ECS needs to keep scheduling and managing tasks correctly on that instance.
ECS now continuously monitors agent connectivity as part of container instance health, independent of the older agentConnected boolean you could already poll. When that connectivity degrades or drops, ECS raises a dedicated health event — AGENT_CONNECTIVITY — against the container instance resource, and that event is consistent across all three compute options: AWS Fargate, Amazon ECS Managed Instances, and self-managed Amazon ECS on EC2.
Where the AGENT_CONNECTIVITY health event actually surfaces
Container instance state changes already ride the EventBridge bus under a well-documented channel, and this is the mechanism the new health event plugs into. You don’t need a new integration to see it — if you’re already watching ECS Container Instance State Change events, you’re already positioned to catch it. A minimal EventBridge pattern to start capturing container instance state transitions looks like this:
{
"source": ["aws.ecs"],
"detail-type": ["ECS Container Instance State Change"],
"detail": {
"status": ["DRAINING"]
}
}
You can also inspect current instance health directly with the CLI, which is useful for scripting a health sweep across a large cluster:
aws ecs describe-container-instances \
--cluster prod-ecs-cluster \
--container-instances arn:aws:ecs:us-east-1:123456789012:container-instance/prod-ecs-cluster/9f8b2e1a4c3d4e5f6a7b8c9d0e1f2a3b \
--query "containerInstances[].{Status:status,AgentConnected:agentConnected}"
That query gets you the coarse view. The point of the new event is that you no longer have to poll for it — ECS pushes the state change the moment it detects impaired connectivity, which is a meaningfully faster detection loop than whatever cron job you were running to catch zombie instances before.
Fargate and Managed Instances: ECS does the whole job
On AWS Fargate and on Amazon ECS Managed Instances, the AGENT_CONNECTIVITY event triggers a fully automatic recovery sequence with no action required from you:
- Running tasks on the impaired instance are drained — the same graceful removal mechanism ECS has long used for manual maintenance, just triggered automatically now.
- Replacement capacity is launched to restore desired task count.
- The impaired instance itself is deregistered from the cluster, so the scheduler stops considering it for future placements.
This is the same operational model that made Fargate attractive in the first place — you don’t manage the underlying host, so AWS closing this particular failure mode without you writing a line of automation is consistent with the deal. Managed Instances gets the same treatment because, despite giving you more visibility into the underlying EC2 instance than Fargate does, AWS still owns the lifecycle of that instance.
EC2: you get the signal, you build the response
Self-managed Amazon ECS on EC2 is where this feature is more “capability” than “magic.” ECS surfaces the exact same AGENT_CONNECTIVITY health event, but it does not touch your Auto Scaling group, does not drain the instance for you, and does not terminate anything. You own those decisions, because you own the instances — maybe that host is running other workloads, maybe you have a debugging process you want to run before you kill it, maybe your termination policy has opinions ECS has no business having.
In practice that means EC2 users need to wire the event to a response themselves — an EventBridge rule targeting a Lambda function or Step Functions workflow that calls the drain API on your behalf:
aws ecs update-container-instances-state \
--cluster prod-ecs-cluster \
--container-instances arn:aws:ecs:us-east-1:123456789012:container-instance/prod-ecs-cluster/9f8b2e1a4c3d4e5f6a7b8c9d0e1f2a3b \
--status DRAINING
Once an instance is DRAINING, ECS stops scheduling new tasks on it and starts replacement tasks elsewhere if cluster capacity allows — the exact same primitive Fargate uses under the hood, you’re just the one pulling the trigger. Pair that with an Auto Scaling group lifecycle hook or a scheduled Lambda that terminates instances once they’ve fully drained, and you’ve rebuilt the automatic behavior Fargate gets for free — with the control an EC2-backed cluster exists to give you in the first place.
Why this matters more than it sounds like
Agent disconnects are exactly the class of failure that’s easy to miss because everything around it looks fine. A host that silently stopped reporting to the control plane can sit there for hours, serving stale task state, before someone notices requests are failing and traces it back. Detecting AGENT_CONNECTIVITY loss as a first-class health event — rather than something you infer from downstream symptoms — closes that blind spot at the layer where it actually originates, which is the whole point of an orchestrator existing in the first place. For more on the underlying health check model this extends, see the ECS Developer Guide and the EventBridge events reference.
Mixed-fleet clusters need to think about both paths
Plenty of real clusters aren’t purely one compute type — a base of ECS Managed Instances or EC2 capacity providers handling steady-state load, with Fargate soaking up burst. That combination means you can’t assume the AGENT_CONNECTIVITY event always resolves itself. Any automation you build against this event needs to check which compute type actually raised it before deciding what to do, because the correct response on Fargate — nothing, ECS already handled it — is a no-op on EC2 that leaves the impaired instance sitting in your cluster indefinitely if you assumed it self-healed. A single EventBridge rule with a Lambda target that branches on the container instance’s capacity provider is cheap insurance against that gap, and it’s a pattern worth building even if EC2 is currently a minority of your fleet.
It’s also worth noting there’s no pricing tier or opt-in flag to worry about here — the detection and (where applicable) the automatic recovery are bundled into the ECS control plane you’re already paying nothing extra for. That’s a meaningfully different posture from bolting on a third-party health-check agent or building your own heartbeat system, both of which cost engineering time up front and ongoing maintenance forever after.
At Enkompass (enkompass.net), this is our home turf. We design AWS architectures that heal themselves at 3 AM so nobody has to. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.