An ELB target group is created with a target type of instance, ip, lambda or alb. What does each one register, and why must an ECS task running on Fargate use the ip type?

## The four target types A target group's `TargetType` is chosen at creation and is immutable — switching means creating a new target group and repointing the listener rule. It determines what a registration record even looks like. **`instance`** — you register an EC2 instance ID plus a port. The load balancer resolves that to the primary private IPv4 address of the instance's primary network interface and connects there. This is the simplest type and the one Auto Scaling groups attach to natively, but it can only ever address instances in the same VPC as the target group. **`ip`** — you register a raw address plus a port. Valid addresses are those in the target group's VPC subnets, or private addresses (RFC 1918 ranges, and RFC 6598 `100.64.0.0/10`) reachable from that VPC over peering, Transit Gateway, VPN or Direct Connect. You cannot register a public address, and you cannot register a DNS name — ELB does not resolve names for you, which is why teams fronting a name-addressed backend end up running a small reconciliation job that re-registers resolved addresses. **`lambda`** — the target group holds exactly one function, and only an Application Load Balancer can forward to it. There is no TCP connection to the function: the ALB synthesises a JSON event containing method, path, headers and body, invokes the function synchronously, and turns the returned object (`statusCode`, `headers`, `body`, `isBase64Encoded`) into the HTTP response. Health checks exist but are disabled by default, and concepts that assume a long-lived backend — slow start, deregistration delay — do not apply. **`alb`** — the target is an Application Load Balancer, and the target group can only be used by a Network Load Balancer. This is the standard way to put a static IP or a PrivateLink endpoint service in front of ALB's HTTP routing. ## Why containers force the ip type ECS tasks using the `awsvpc` network mode get their own elastic network interface with a private address inside the VPC. AWS Fargate supports **only** `awsvpc`, so a Fargate task never shares a host's address — and there is no EC2 instance ID for it in the first place. The ECS service therefore registers each task's IP into an `ip`-type target group and deregisters it when the task stops. The same applies to workloads reached through the VPC CNI, where each pod holds a VPC address that is registered directly. The practical difference is a hop. With `instance` targets and a container behind a host port, traffic lands on the instance and is then forwarded to the container; with `ip` targets it lands on the task's own interface. IP mode removes the extra hop and lets health checks target the task rather than the host — but it consumes VPC addresses per task, which is a real constraint in small subnets. ```bash aws elbv2 create-target-group --name api-tasks --target-type ip \ --protocol HTTP --port 8080 --vpc-id vpc-0abc1234def567890 \ --health-check-path /healthz --matcher HttpCode=200 ``` ## Port and protocol overrides The port supplied at registration overrides the target group's default port, so the same target group can hold the same instance on several ports — the classic way to run multiple containers of one service per host in `bridge` mode. The health check has its own port setting: the special value `traffic-port` means "whatever port this target is registered on", while an explicit number lets you probe a dedicated admin or management port that is not the port serving traffic. Protocol can differ too: an ALB target group can forward over HTTP while probing over HTTP, or forward HTTPS to targets doing their own TLS. ## Choosing Use `instance` for plain EC2 fleets behind an Auto Scaling group — it is the least machinery. Use `ip` when the backend is a Fargate task, a container with its own interface, an on-premises host reached over Direct Connect, or anything else without an instance ID. Use `lambda` for lightweight HTTP endpoints where you want ALB routing without running a server. Use `alb` only in the NLB-in-front-of-ALB pattern.