Skip to main content
Source

This page is generated from skills/ecs-architect/references/networking-and-eni-density.md. Edit the source, not this page.

ECS Networking and ENI Density

Part of: ecs-architect Purpose: Design task networking for ECS — awsvpc task ENIs, ENI density and trunking on EC2, subnet/SG placement, load-balancer choice, and Service Connect vs Service Discovery. Facts verified against AWS docs on 2026-07-09.

Table of Contents​

  1. Network Modes
  2. awsvpc Task ENIs
  3. ENI Density and Trunking on EC2
  4. Subnet and Security-Group Design
  5. Load Balancer Selection
  6. Service Connect vs Service Discovery
  7. VPC Lattice (cross-account / cross-VPC east-west)
  8. Sources

Network Modes​

ModeWhere it appliesNotes
awsvpcFargate (required), EC2, Managed InstancesEach task gets its own ENI, its own private IP, and its own security group. Recommended for security and observability. Not available on ECS Anywhere (EXTERNAL).
bridgeEC2, ECS Anywhere (EXTERNAL)Docker's built-in virtual network; dynamic port mapping. Legacy.
hostEC2, Managed Instances, ECS Anywhere (EXTERNAL)Task binds directly to the host's network. No per-task isolation. MI supports exactly awsvpc + host (MI task networking).
noneEC2, ECS Anywhere (EXTERNAL)No external connectivity.

Default recommendation: awsvpc. It gives each task EC2-like networking — security groups, VPC Flow Logs, and granular monitoring per task — and is mandatory on Fargate. (Allocate a network interface for an Amazon ECS task)

ECS Anywhere (EXTERNAL) caveat. External-instance Linux tasks must use bridge, host, or none — awsvpc is not supported (ECS clusters for external instances). Because awsvpc is unavailable on external instances, you get no per-task ENI and no security-group-per-task there, and the per-task isolation/observability benefits below do not apply.

awsvpc Task ENIs​

With awsvpc, ECS creates one ENI per task, attaches it to the host with the task's security group, and assigns a private IPv4 address (plus IPv6 in a dual-stack subnet). Each task can only have one ENI. These ENIs are ECS-managed — visible in the EC2 console but you can't detach or modify them; they're deleted when the task stops or the service scales in. (task-networking-awsvpc)

Consequence for IP planning: every task consumes a VPC IP. In IP-constrained VPCs, high task counts can exhaust subnets — size subnets for peak task count, not just instance count.

ENI Density and Trunking on EC2​

On EC2, the biggest disadvantage of awsvpc is that EC2 instances cap how many ENIs can attach, which caps tasks per instance. By default a c5.large supports 3 ENIs; the primary counts as one, leaving 2 — so only ~2 awsvpc tasks per c5.large. (container-instance-eni)

ENI trunking raises this. Turn on the awsvpcTrunking account setting and ECS attaches a managed "trunk" ENI to newly-launched (supported) instances. A c5.large with trunking has an ENI limit of 12, so it can run 10 tasks instead of 2 — roughly a 5x density gain. (container-instance-eni) The frequently-cited claim that trunking adds no latency or bandwidth penalty is blog-sourced (AWS Compute Blog), not a hard doc guarantee — treat it as a strong indication rather than an SLA, and load-test if latency is critical. (Optimizing ECS task density using awsvpc — blog)

Design notes:

  • awsvpcTrunking is not available on Fargate (Fargate is one task = one microVM anyway). (container-instance-eni)
  • On self-managed ECS on EC2, trunking is an explicit opt-in (account setting) — a commonly-missed step that leaves the bulk of a Fargate→EC2 migration's density unrealized. On ECS Managed Instances, ENI trunking is on by default, so density planning is automatic there.
  • Trunking uses two ENI attachments by default (the instance's primary ENI plus the ECS-managed trunk ENI). Density scales with instance size on supported types — e.g. larger Graviton instances host many tens of tasks. Check the supported-instance-type list before assuming a density number.
  • The trunk ENI is fully managed by ECS and deleted on instance termination/deregistration.
  • Trunking must be enabled before launching the instances that should benefit — it applies to newly-launched instances.
  • Denser bin-packing via trunking improves cost efficiency for tasks that don't hit CPU/memory limits; quantify with ecs-cost-intelligence.

Subnet and Security-Group Design​

  • Private subnets for tasks, public subnets for internet-facing load balancers. Tasks reach the internet via NAT or, better for cost, VPC endpoints for AWS services (ECR, S3, CloudWatch Logs, Secrets Manager).
  • Security group per task (awsvpc) — apply least-privilege SGs at task granularity rather than one broad host SG. Detailed SG/least-privilege hardening belongs to ecs-security.
  • VPC endpoints eliminate NAT data-processing cost for pulls/logs/secrets and keep traffic private; strongly recommended for private clusters.

Load Balancer Selection​

Load balancerBest forNotes
ALBHTTP/HTTPS web apps and APIs, path/host routing, WebSocketsNative TLS termination, WAF, Cognito auth. Express Mode uses ALB with an AWS-managed ACM cert.
NLBTCP/UDP, ultra-low latency, static IPs, gRPCUDP to Fargate requires platform version 1.4+ (Architect for Fargate — service load balancing).
None (Service Connect)Service-to-service traffic inside/across clustersNo LB needed for east-west; see below.

External instances (ECS Anywhere) have no ELB support — factor this into inbound-traffic designs. (launch-type-external)

Service Connect vs Service Discovery​

Both solve service-to-service connectivity without a load balancer. Service Connect is the recommended choice for new designs. (Interconnect Amazon ECS services)

Service Connect (recommended)Service Discovery (Cloud Map)
MechanismECS-managed proxy (Envoy) sidecar in each task; logical short names + standard portsAWS Cloud Map DNS records per task
ScopeSame cluster, other clusters, across VPCs in the same RegionDNS-resolvable endpoints
TelemetryRich traffic telemetry in the ECS console and CloudWatchNone built-in
Deployment safetyConfig changes apply at deployment; automatic connection draining lets clients cut over to a new endpoint version without traffic errorsDNS TTL means clients may keep hitting old IPs until TTL expires — a classic migration pain
Resource costAdds a managed proxy sidecar that consumes task CPU/memory — AWS recommends budgeting +256 CPU units and ≥64 MiB (more at high RPS/large namespaces); requires a task-level memory limit (Service Connect components)No sidecar; near-zero task overhead
Change modelConfig changes take effect only via a new deployment (replaces tasks) — no live reconfigDNS records update without redeploying tasks
Network-mode supportawsvpc and bridge only — not host, and not ECS Anywhere/EXTERNAL (Interconnect ECS services)awsvpc, bridge, host
App changesUsually none if the app already uses DNS namesNone

Why Service Connect wins: with DNS-based discovery, changing a name to new IPs waits out the max TTL before all clients switch. Service Connect updates config by replacing client tasks during a normal deployment, so you control the cutover with the deployment circuit breaker and other deployment settings. (Networking between ECS services in a VPC)

Coming off App Mesh? AWS App Mesh is discontinued September 30, 2026 (confirmed in the App Mesh doc-history end-of-support notice; no new-customer onboarding since September 24, 2024). Service Connect is the recommended ECS target (managed data plane, no self-managed Envoy sidecars, built-in retries/outlier detection and CloudWatch metrics). Migrate per service, running both in parallel during cutover. The commonly-cited Service Connect gaps vs App Mesh — no fine-grained retry/circuit-breaker tuning, weighted A/B traffic splits, or cross-account sharing — are blog-sourced (the AWS App-Mesh→Service-Connect migration blog), not an authoritative feature matrix; verify against current docs before relying on any specific gap. Where you need cross-account/traffic-split, VPC Lattice (below) is the doc-backed answer. (App Mesh EOL — doc history · Migrating from AWS App Mesh to Amazon ECS Service Connect — blog)

Migration from Service Discovery → Service Connect is covered in launch-type-migration.md.

VPC Lattice (cross-account / cross-VPC east-west)​

Amazon VPC Lattice has built-in Amazon ECS support: an ECS service can be associated directly with a VPC Lattice target group, and ECS auto-registers/deregisters task IPs as targets and replaces tasks that fail VPC Lattice health checks — no intermediate load balancer required. (Use VPC Lattice with ECS · ECS + VPC Lattice launch)

When VPC Lattice over Service Connect: VPC Lattice answers Service Connect's gaps — it connects services across accounts (shared via AWS RAM), across VPCs, and supports weighted/blue-green/canary traffic splitting and IAM auth policies. It works with bridge, awsvpc, and host network modes (interconnect network-mode table).

Constraints:

  • Only ECS rolling deployments work with VPC Lattice — CodeDeploy and blue/green deployment controllers are not supported (Use VPC Lattice with ECS). If you need native blue/green and Lattice, that is a conflict to resolve at design time.
  • Not supported on ECS Anywhere (EXTERNAL).
  • Attaching multiple (up to five) VPC Lattice configurations can lengthen deployment time.
  • Lattice has its own cost dimensions — unlike Service Connect (whose cost is the proxy sidecar's task CPU/memory, above), VPC Lattice bills per service-hour, per GB of data processed, and per HTTP request (or TCP connection for TLS listeners) (VPC Lattice pricing). Weigh both cost models when choosing; quantify with ecs-cost-intelligence.

Sources​