Fargate Networking: The ENI Per Task Model

One Task, One Network Identity

On a shared EC2 node, all containers share the host's network interface. They get private ports on the host's IP address, and you use port mapping to route traffic. This creates complexity: two containers can't both listen on port 80 on the same host.

Fargate eliminates this entirely. In Fargate, awsvpc is the only supported networking mode, and it means every task gets its own Elastic Network Interface (ENI) injected directly into your VPC subnet. The task has its own private IP address, its own security group rules, and its own network identity — as if it were a standalone EC2 instance.

This has several practical consequences:

1. No port conflicts. Two tasks can both listen on port 8080 without any coordination, because they have different IP addresses.

2. Security Groups attach to tasks, not hosts. You define which ports are open at the task level. There is no host-level firewall to manage separately.

3. Public IP assignment. If you launch a task in a public subnet, you can assign a public IP directly to the task's ENI. This is useful for simple standalone services that don't need a load balancer.

4. VPC Flow Logs capture task-level traffic. Because each task has its own ENI, VPC Flow Logs give you per-task network visibility without any additional instrumentation.

The ENI Limit Problem

Every AWS account has a limit on the number of ENIs per subnet and per region. Because Fargate creates one ENI per task, a large Fargate deployment can exhaust ENI limits faster than an equivalent EC2 deployment (where many containers share one ENI per node).

If you plan to run hundreds of concurrent Fargate tasks, request an ENI limit increase proactively via AWS Service Quotas. The symptom of hitting this limit is tasks that fail to start with a ResourceInitializationError mentioning ENI provisioning failure.

The Cold Start Penalty

Fargate's startup sequence involves several steps that don't exist for containers on a pre-warmed EC2 node:

1. AWS allocates a MicroVM on physical hardware.
2. The MicroVM boots (kernel init, containerd start).
3. An ENI is created and attached to the MicroVM.
4. The container image is pulled from ECR (if not cached).
5. Your container process starts.

This sequence typically takes 30–90 seconds for a cold start, compared to 2–5 seconds for a container starting on an already-running EC2 node. For latency-sensitive auto-scaling scenarios, this matters. Mitigation strategies include:

• ECS Service Auto Scaling with buffer capacity: Keep a minimum number of tasks running so scale-out adds to existing capacity rather than starting from zero.
• ECR image optimization: Use smaller base images (Alpine, distroless) to reduce pull time. Enable ECR image caching.
• Fargate Spot with on-demand buffer: Run a baseline of on-demand tasks that are always available, and use Spot for burst capacity where cold start latency is acceptable.