Beyond basic round-robin traffic distribution, ELB provides powerful features for session management, health checking, SSL termination, and access logging.
Sticky sessions ensure a user always reaches the SAME backend instance during their session. Useful for applications that store session state on the server (not recommended for cloud-native apps).
ALB Sticky Session types:
1. Load balancer generated cookie (AWSALB): managed by ALB
2. Application-based cookie: your app sets a custom cookie
# Problem with sticky sessions:
# If the instance fails, user session is lost
# Better solution: store sessions in ElastiCache (Redis)
# Then ANY instance can serve ANY user
When an instance is deregistered (during scale-in or deployment), the load balancer stops sending NEW requests but waits for existing requests to complete. Default: 300 seconds. Set to 0 for instant deregistration.
| Balancer | Cross-Zone Default | Cost of Cross-Zone Traffic |
|---|---|---|
| ALB | Enabled (always) | Free |
| NLB | Disabled by default | Charged (inter-AZ data transfer) |
| GWLB | Disabled by default | Charged |
# Enable access logs on ALB
# Logs stored in S3 bucket
# Format: timestamp, client IP, request path, backend IP,
# response code, latency, user agent
# Useful for:
# - Security analysis (who is hitting your application?)
# - Debugging slow requests
# - Understanding traffic patterns
# - Compliance auditing
When ALB forwards requests to backend instances, the source IP is the ALB's IP — not the real client IP. The real client IP is in the X-Forwarded-For header.
# In your application, read client IP from:
request.headers.get('X-Forwarded-For')
# Not from: request.remote_addr (this is the ALB IP)