ECS supports several network modes, and Fargate requires awsvpc. What does the awsvpc network mode give each task, and how does it change things compared with the bridge network mode on the EC2 launch type?

## What awsvpc allocates When a task launches with `networkMode: awsvpc`, ECS creates an elastic network interface, attaches it to the task, and places it in a subnet you named in the `awsvpcConfiguration` of the service or `RunTask` call: ```json { "awsvpcConfiguration": { "subnets": ["subnet-0a1b", "subnet-2c3d"], "securityGroups": ["sg-0api"], "assignPublicIp": "DISABLED" } } ``` The task now has: - **Its own private IP** inside your VPC CIDR, routable like any other VPC resource. - **Its own security groups**, evaluated independently of anything else running on the same host. - **Its own network namespace**, shared by every container in the task. Two containers in one task reach each other at `localhost:<port>` and cannot both bind the same port. - **VPC flow log records** attributable to that task's ENI rather than to a shared host interface. That last point plus per-task security groups is the real prize: you can write a rule that says "only the payments task may reach the payments database", which under `bridge` you cannot express at all, because every task on the instance shares the instance's security group. ## bridge and host on the EC2 launch type `bridge` uses the Docker bridge network on the container instance. Containers get a host-internal address, and the `portMappings` entry maps `containerPort` to a `hostPort`. Set `hostPort: 0` and ECS picks an ephemeral port from the instance's range, which is what makes it possible to run several copies of the same container on one instance — and what forces the load balancer to register instance-plus-port targets that ECS keeps in sync. `host` skips the bridge and binds the container directly to the instance's network interface. It is the fastest path and the least flexible: one task per port per instance, and the container sees the host's addresses. `awsvpc` is available on both launch types, but it is *required* on Fargate — there are no shared hosts you own to bridge onto. ## Consequences for load balancing This is the part interviewers probe. Under `awsvpc`, the ECS service registers **task IP addresses** into the target group, so the target group must have been created with target type `ip`. Under `bridge` with dynamic ports, ECS registers **instance ID and host port** pairs, so the target group is target type `instance`. Creating the target group with the wrong type is a very common first-deployment failure: the service creation call is rejected, or targets never register and the ALB reports no healthy hosts. Security groups also move. With `awsvpc`, the rule you write is "the task's security group allows 8080 from the ALB's security group". With `bridge`, the rule is on the *instance* security group and must cover the whole ephemeral port range, which is a far coarser grant. ## ENI density on EC2 On the EC2 launch type, `awsvpc` costs an ENI per task, and every instance type has a hard cap on attached ENIs. A small instance may only host two or three `awsvpc` tasks regardless of spare CPU and memory — a nasty surprise if you sized the cluster on CPU alone. The `awsvpcTrunking` account setting (opted into per account and region) attaches a trunk interface to supported instance types and raises the number of tasks per instance substantially. It also means IP address consumption in your subnets scales with task count, so small subnet CIDRs become a real constraint on a busy cluster. On Fargate the ENI is still allocated in your subnet and still consumes an IP, but the instance-level cap is AWS's problem, not yours. ## Egress and metadata Because the task's ENI lives in your subnet, its outbound path is whatever the subnet's route table says. A task in a private subnet reaches the internet only through a NAT gateway, and reaches AWS APIs privately only through VPC endpoints. `assignPublicIp: ENABLED` is only meaningful in a subnet with an internet gateway route; in a private subnet it does nothing useful. Task metadata is served over the same interface at a link-local address, which is how the credentials endpoint and container stats are exposed. ## Choosing On Fargate there is no choice. On EC2, choose `awsvpc` when you want per-task security groups and per-task flow-log attribution — which is nearly always the right default for anything security-relevant — and fall back to `bridge` when task density per instance matters more than network isolation and trunking is not an option.