Monitoring ECS On EC2 With LogForge, Without Losing The Host Boundary

Short Answer

Yes, the EC2 LogForge pattern applies to ECS when your ECS tasks run on EC2 container instances that you manage.

The LogForge agent cares about the host boundary. It needs the local Docker socket, container log directory, and host filesystem view. ECS on EC2 still has those things because your tasks are running on EC2 instances registered into an ECS cluster.

AWS now describes ECS capacity in terms of launch types and capacity providers. The important distinction for LogForge is simple: EC2 and EC2 Auto Scaling group capacity providers give you a host you can enroll; pure Fargate does not. AWS covers those compute choices in its ECS launch type and capacity provider docs.

The Shape Of The Setup

Keep the unit of monitoring as the ECS container instance, not the ECS service, task, or container.

ECS service task
ECS service task  --->  EC2 container instance  --->  LogForge Central :9443
ECS service task        LogForge agent

That means:

• One LogForge Central for the fleet.
• One LogForge agent on each active ECS EC2 container instance.
• No LogForge agent inside every application task.
• No inbound LogForge management port required on the ECS hosts.

The LogForge agent is separate from the Amazon ECS container agent. The ECS agent registers the instance into the ECS cluster. The LogForge agent observes the local Docker host and sends telemetry to LogForge Central.

Install Pattern

For a first install, use the same flow as the EC2 guide, but run it on each ECS container instance.

1. Start LogForge Central somewhere stable and reachable.
2. Open Settings > Agents in LogForge.
3. Generate a unique enrollment command for one ECS container instance.
4. Connect to that EC2 host with SSH or AWS Systems Manager Session Manager.
5. Run the generated command on the host.
6. Repeat for each active ECS container instance.

The generated command should still include these host mounts:

/var/run/docker.sock
/var/lib/docker/containers
/

Those mounts are what let the agent see Docker inventory, container logs, host metrics, and local remediation targets.

Autoscaling Notes

ECS on EC2 often means an Auto Scaling group, capacity provider, or instance refresh will replace hosts over time. When an EC2 container instance disappears, its LogForge agent disappears with it. The replacement host needs its own enrollment.

For small or mostly steady clusters, manual enrollment per current container instance is fine. For elastic clusters, plan the enrollment lifecycle before treating coverage as automatic. The clean model is still one agent per host, but automation needs a way to mint a fresh identity for each new instance.

ECS also has a DAEMON scheduling strategy that places one task on each active container instance. That shape maps well to host agents, but the current public LogForge UI emits a Docker run command with a unique enrollment token. Treat an ECS daemon-service version as an advanced conversion that needs a tested task definition, host bind mounts, and unique enrollment handling.

Security Groups

For ECS container instances, the LogForge rule is the same as plain EC2: the agent connects out to Central and keeps an mTLS WebSocket open.

ECS container instance  --->  tcp/9443  --->  LogForge Central

You usually do not need new inbound security group rules on the ECS hosts for LogForge. Central needs inbound 9443/tcp from those hosts or their NAT/VPC path. Keep the dashboard/API port, default 8444, limited to admins, a VPN, a private mesh, or a trusted proxy.

The generated agent command may publish local input ports such as 24224, 9880, 4317, and 4318. Do not open those in the ECS host security group unless another machine is intentionally sending telemetry to the agent.

Verify Coverage

On an ECS container instance, confirm the LogForge agent container is running:

docker ps --filter "name=unicron-agent"

Then confirm the agent can reach Central:

nc -vz logforge.example.com 9443

In LogForge, the agent should appear under Settings > Agents. Container inventory should include ECS task containers from that host, and host metrics should update even when ECS replaces an application task.

This Is Not The Fargate Path

This setup applies when ECS gives you an EC2 host boundary. It does not apply to pure ECS Fargate, because Fargate does not give you a Docker host where you can run a privileged host agent and mount the Docker socket.

If your service is on Fargate, use the Fargate boundary guide instead. If you need LogForge's host-level container inventory and guarded Docker actions, run that workload on ECS EC2 capacity or another Docker host you control.

Troubleshooting

The agent is online, but app logs are missing.

Check the ECS task definition log driver. If the task uses awslogs, awsfirelens, or another non-default driver, stdout may be shipped through that driver instead of remaining available as Docker JSON log files on the host. Host metrics, container inventory, and Docker events can still work while app log visibility depends on the task's logging configuration.

A new ECS instance appeared without a LogForge agent.

That instance was probably launched by the Auto Scaling group or capacity provider after your manual enrollment pass. Generate a fresh enrollment command for the new host, then decide whether you need a real bootstrap automation path.

Several ECS hosts show up as one agent.

Do not reuse enrollment commands. Generate one command per container instance so every host has its own certificate, name, and identity.

Containers are missing.

Confirm the agent command mounted the Docker socket, Docker container log directory, and host root. If your ECS AMI uses a nonstandard Docker data root, adjust the /var/lib/docker/containers mount to match the host.