Target Groups and Health Checks

A target group is a logical collection of targets that the load balancer routes requests to. Each target group has a target type, a protocol/port, and a health check configuration. The load balancer distributes requests to registered targets in the target group that pass health checks.

Target groups are associated with load balancer listeners through listener rules. One listener can route to multiple target groups based on request attributes. This is the core mechanism behind path-based and host-based routing in ALB.

Target groups support three target types:

• instance: routes to EC2 instances by instance ID; the load balancer sends traffic to the instance's primary network interface on the specified port
• ip: routes to private IP addresses—useful for targets in containers (ECS/EKS), on-premises servers reachable via VPN/Direct Connect, or EC2 instances' secondary IPs
• lambda: routes to a single Lambda function (ALB only); ALB converts the HTTP request to a JSON event and invokes the function synchronously

IP target type is required for ECS tasks with the awsvpc network mode (each task gets its own IP), for EKS pods, and for hybrid architectures with on-premises targets.

You register targets with a target group manually (in the console or CLI) or automatically (via Auto Scaling Group attachment or ECS service configuration). Manually registered targets remain in the group until you explicitly deregister them.

For ASGs, you attach the ASG to a target group, and the ASG automatically registers newly launched instances and deregisters terminated ones. This tight integration with ASG is the standard pattern for elastic compute tiers—new instances come online and start receiving traffic as soon as they pass the health check.

Each target group has an associated health check that the load balancer uses to determine if a target is healthy and eligible to receive traffic. The health check sends periodic requests to each target and evaluates the response:

• Protocol: HTTP, HTTPS, or TCP (for NLB)
• Path: the URL path to request (e.g., /health or /ping)
• Port: the port to check (defaults to the target group port)
• Healthy threshold: consecutive successes before marking healthy
• Unhealthy threshold: consecutive failures before marking unhealthy
• Interval: seconds between health checks (5–300)
• Timeout: seconds to wait for a response

For HTTP/HTTPS health checks, you specify which HTTP response codes indicate a healthy target. The default is 200, but you can configure ranges like 200-299 or comma-separated values like 200,301,302.

Best practice: create a dedicated /health endpoint in your application that returns 200 only when all critical dependencies are available (database connectivity, cache, downstream service). Do not use the root URL (/) as the health check path if it performs expensive operations or requires authentication.

A target progresses through these states after registration:

• initial: ELB is performing the first health checks
• healthy: passed the required consecutive health checks; receives traffic
• unhealthy: failed the required consecutive health checks; removed from rotation
• draining: deregistration is in progress; existing connections are allowed to complete but no new connections are sent
• unused: registered in the group but no listener rule currently routes to this group

Monitor the UnHealthyHostCount and HealthyHostCount CloudWatch metrics to detect problems with your target fleet.

Deregistration delay (formerly called connection draining) is the time ELB waits for existing connections to complete before finally deregistering a target. The default is 300 seconds (5 minutes). During this period, no new requests are sent to the deregistering target, but in-flight requests are allowed to finish.

For quick deployments and auto-scaling terminations, you may want to reduce this to 30–60 seconds if your application handles requests quickly. For long-running operations (file uploads, video processing), keep it long enough for those operations to complete without being interrupted.

Target groups support different load balancing algorithms:

• Round robin (ALB default): requests distributed evenly in rotation—best when all targets are equivalent
• Least outstanding requests (ALB): sends each new request to the target with the fewest in-flight requests—better for variable-length workloads where some requests take longer than others
• Flow hash (NLB): distributes based on protocol, source/destination IP, source/destination port, and TCP sequence number—ensures all packets in a TCP/UDP flow go to the same target

For session-based applications where all requests from a user must reach the same target, enable sticky sessions instead of relying on round-robin distribution.

A single ALB listener rule can distribute traffic across multiple target groups with weighted target groups. For example, route 90% of traffic to a stable target group and 10% to a canary target group for blue-green deployments—without using Route 53 weighted routing.

Weighted target groups are configured at the listener rule level. The weights are relative: 90/10 sends 90% to the first group and 10% to the second. This is different from weighted routing across multiple ALBs; here it is within a single ALB listener rule.

When deploying ECS services behind an ALB, each ECS task gets registered with the ALB target group using the ip target type (for awsvpc network mode). The ECS service manages registration and deregistration automatically: new tasks are registered after passing health checks, and stopping tasks trigger deregistration delay before termination.

Each ECS service can register with a specific port override, allowing multiple ECS services to share a single ALB via different listener rules (path-based or host-based) with different target groups—a common microservices pattern.

NLB health check behaviour differs from ALB:

• NLB supports TCP, HTTP, and HTTPS health check protocols regardless of the listener protocol
• NLB health checks are sent from the NLB's IP addresses in each AZ—ensure security groups allow traffic from the NLB's subnet IPs or use the security group of the NLB itself
• For TCP health checks, NLB considers a target healthy if it accepts a TCP connection on the specified port
• NLB targets that fail health checks are removed per AZ—if an AZ's targets are all unhealthy, NLB may cross-zone load balance to healthy targets in other AZs (if cross-zone LB is enabled)

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: target groups contain healthy registered targets of type instance, IP, or Lambda, health checks periodically probe targets to remove unhealthy ones from rotation, and deregistration delay ensures graceful draining of in-flight requests before target removal. Next up we explore listener rules and path-based routing on the ALB.