AWS Target Groups¶

1. What is a Target Group?¶

A Target Group is a logical collection of backend resources that a Load Balancer routes traffic to. It separates the routing decision (load balancer + listener) from the destination (target group + targets).

Client
  ↓
Load Balancer (routing decision: which target group?)
  ↓
Target Group (health tracking, algorithm, attributes)
  ↓
Targets: EC2 / IP / Lambda / ALB

The Load Balancer decides which Target Group to send to (via listener rules). The Target Group decides which target within the group to send to (via algorithm). These are two separate routing decisions.

2. Three-Layer Mental Separation ⭐¶

Never mix these layers mentally. A Listener belongs to a Load Balancer. A Target Group is independent and can be referenced by a Listener rule.

3. Target Types ⭐¶

1. Instances¶

Register EC2 instances by Instance ID. AWS resolves the instance's private IP automatically.

Target Group → EC2 instance-id (i-xxxxxxxx)
             → LB sends to: 10.0.1.10:80 (private IP resolved by AWS)

With Auto Scaling: the ASG registers and deregisters instances from the target group automatically as it scales out/in.

2. IP Addresses¶

Register any IP address — EC2 private IPs, on-premises IPs, container IPs.

Supported CIDR ranges:

• VPC CIDR (same VPC or peered VPC)
• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — RFC 1918
• On-premises CIDRs (via VPN or Direct Connect)

Target Group → 10.0.2.10:8080  (EC2 in private subnet)
             → 192.168.1.20:80  (on-prem server via DX/VPN)
             → 10.0.3.5:9000    (container IP in ECS)

Key distinction from Instances type: you register the IP + port directly, not the instance. Useful when the instance IP is not the right granularity.

3. Lambda Function¶

ALB invokes the Lambda function directly — no server or port needed.

Client → ALB → Lambda function (event payload: HTTP request object)
Lambda returns response → ALB converts → HTTP response to client

Lambda receives the request as a JSON event:

{
  "httpMethod": "GET",
  "path": "/api/data",
  "headers": { "Host": "example.com" },
  "queryStringParameters": { "id": "123" },
  "body": null
}

4. Application Load Balancer (as Target)¶

An NLB can forward traffic to an ALB as its backend target. This enables a two-tier load balancing architecture.

Client
  ↓
NLB (Layer 4 — static IP, TCP)
  ↓
ALB (Layer 7 — path routing, header inspection)
  ↓
EC2 targets

4. Protocol — LB Type Mapping ⭐¶

HTTP Version Clarification ⭐¶

ALB supports HTTP/2 from the client but communicates to targets over HTTP/1.1. So when creating a target group for HTTP/2 workloads, set the target group protocol to HTTP (not HTTP/2). gRPC is the exception — the target group protocol must match (gRPC).

5. Load Balancing Algorithms ⭐¶

Set via load_balancing.algorithm.type attribute on the target group. Least Outstanding Requests is better than Round Robin when some requests take much longer — avoids overloading slow or warming-up instances.

6. Target Group Attributes ⭐¶

Deregistration Delay (Connection Draining)¶

When a target is deregistered (removed or scaling in), the load balancer:

1. Stops sending new requests to it immediately
2. Waits for in-flight requests to complete
3. After timeout → marks target as unused

States:
  healthy → draining (stop new, finish existing) → unused → terminated

Default: 300 seconds
Range:   0–3600 seconds

# Set deregistration delay to 60 seconds (for fast-draining services)
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:... \
  --attributes Key=deregistration_delay.timeout_seconds,Value=60

Set low (30–60s) for stateless services. Set high (300+s) for long-running connections (file uploads, WebSockets).

Slow Start Mode¶

Gradually ramps up traffic to a newly registered target instead of sending it a full share immediately. Useful for targets that need warm-up time (JVM, caches).

Timeline with slow_start.duration_seconds = 120:
  t=0s:    New target registered → receives ~0% of its fair share
  t=60s:   Receives ~50% of fair share
  t=120s:  Fully warmed → receives 100% fair share
  (Linear increase over the duration)

Sticky Sessions (Session Affinity)¶

Binds a user's session to a specific target — all requests from that user go to the same target for the duration of the session.

User A: first request → routed to Target-1
        Cookie: AWSALB=xxxxx (target-1 affinity)
User A: second request → reads cookie → sent to Target-1 again ✅

User B: first request → routed to Target-2
        all subsequent requests → Target-2

Sticky sessions break even distribution — some targets get more load. Use only when your application requires session state on the server. Better alternative: Store session state in ElastiCache (Redis) — removes stickiness need.

7. Weighted Target Groups ⭐ (Blue/Green & Canary)¶

A listener rule can forward traffic to multiple target groups with weights, enabling gradual rollouts:

Listener Rule: forward to
  Target Group v1 (Blue):  Weight 90  → 90% of traffic
  Target Group v2 (Green): Weight 10  → 10% of traffic (canary)

Blue/Green deployment sequence:

# Step 1: Deploy new version to Green TG, send 10% traffic
aws elbv2 modify-listener --listener-arn ... \
  --default-actions '[{"Type":"forward","ForwardConfig":{
    "TargetGroups":[
      {"TargetGroupArn":"<blue-arn>","Weight":90},
      {"TargetGroupArn":"<green-arn>","Weight":10}]}}]'
# Step 2: Monitor — no errors? Shift to 50/50
# Step 3: Full cutover
aws elbv2 modify-listener --listener-arn ... \
  --default-actions '[{"Type":"forward","ForwardConfig":{
    "TargetGroups":[
      {"TargetGroupArn":"<blue-arn>","Weight":0},
      {"TargetGroupArn":"<green-arn>","Weight":100}]}}]'

NLB also supports Weighted Target Groups (added November 2025).

8. Health Checks ⭐¶

Parameters¶

Health Check Port Strategies¶

Strategy 1 — traffic-port (default):
  Health check sent to same port as traffic (e.g., :80)
  ✅ Simple ❌ Health check and traffic compete for same thread pool

Strategy 2 — custom port (e.g., :8081):
  Dedicated health endpoint on different port
  ✅ Isolated ✅ App can return rich health status
  ✅ Best practice for production

Target States¶

9. Auto Scaling Integration¶

Target groups integrate directly with Auto Scaling Groups:

ASG scales OUT → new EC2 launched → automatically registered to TG
ASG scales IN  → EC2 selected → TG sets to draining → waits deregistration delay
              → connections drained → instance terminated

This is why deregistration delay must be set appropriately — if it's too short, in-flight requests are killed when ASG scales in.

Health check grace period (ASG setting, separate from TG health check):

Grace period: time after launch before ASG checks TG health status
Default: 300 seconds
Purpose: Give instance time to boot + start app before health checks run

10. Target Group — Scope and Limits¶

11. When to Use What¶

12. Common Mistakes¶

13. Interview Questions Checklist¶

• What is a Target Group and why does it exist?
• What are the four target types? When do you use each?
• Why must Lambda target type be ALB only?
• Why must ALB-as-target be used with NLB only?
• Why does ALB not forward HTTP/2 to targets?
• What is deregistration delay? What states does a target go through?
• When would you set deregistration delay to 0? To 600?
• What is slow start mode? What algorithm is it incompatible with?
• Sticky sessions — two types? What is the downside?
• What is the better alternative to sticky sessions?
• What are weighted target groups? Describe a blue/green deployment using them
• What are the three load balancing algorithms? When do you choose LOR over Round Robin?
• What is a health check grace period and what sets it? (ASG — not TG)
• Can one target group serve multiple load balancers? (No)
• How does ASG + Target Group integration work for scale-in events?