Elastic Load Balancing (ALB, NLB, GWLB)
Key concepts
ALB for HTTP/HTTPS (Layer 7)
NLB for TCP/UDP (Layer 4)
GWLB for third-party appliances
Target groups and health checks
Sticky sessions
Introduction
Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets and virtual appliances in one or more Availability Zones. ELB is a fully managed service that scales automatically based on incoming traffic patterns. Understanding the different load balancer types and their use cases is essential for the SAA-C03 exam.
ELB Core Concept
ELB provides three types of load balancers: Application Load Balancer (Layer 7), Network Load Balancer (Layer 4), and Gateway Load Balancer (Layer 3/4). Each serves different use cases - ALB for HTTP/HTTPS traffic, NLB for ultra-low latency TCP/UDP, and GLB for virtual appliances like firewalls.
Load Balancer Types
Application Load Balancer (ALB)
The Application Load Balancer operates at Layer 7 (application layer) of the OSI model, making it ideal for HTTP and HTTPS traffic.
ALB Routing Rules
Listener Rules determine how the ALB routes requests to target groups based on:
- Path patterns:
/api/*,/images/* - Host headers:
api.example.com,www.example.com - HTTP headers: Custom header values
- HTTP methods: GET, POST, PUT, DELETE
- Query strings:
?action=login - Source IP: CIDR block ranges
Each rule has a priority, conditions, and actions (forward, redirect, fixed-response, or authenticate).
Network Load Balancer (NLB)
The Network Load Balancer operates at Layer 4 (transport layer), designed for extreme performance and ultra-low latency.
Only NLB can be used to expose services via AWS PrivateLink (VPC Endpoint Services). If an exam question mentions exposing services privately to other VPCs or AWS accounts without internet exposure, NLB is the answer.
Gateway Load Balancer (GLB)
The Gateway Load Balancer operates at Layer 3/4, designed for deploying, scaling, and managing third-party virtual appliances.
GLB Architecture Requirements
Gateway Load Balancer requires a separate security/appliance VPC. Traffic flows: Source → GLB Endpoint → GLB → Virtual Appliances → GLB → GLB Endpoint → Destination. The appliances must support GENEVE encapsulation.
Comparison of Load Balancer Types
ELB Type Comparison
| Feature | ALB | NLB | GLB |
|---|---|---|---|
| OSI Layer | Layer 7 | Layer 4 | Layer 3/4 |
| Protocols | HTTP, HTTPS, gRPC | TCP, UDP, TLS | IP (all) |
| Latency | Milliseconds | ~100 microseconds | Low |
| Static IP | No | Yes | Yes |
| Elastic IP | No | Yes | No |
| PrivateLink | No | Yes | No |
| Lambda Targets | Yes | No | No |
| WebSockets | Yes | Yes | N/A |
| Cross-Zone (default) | Enabled | Disabled | Disabled |
| SNI Support | Yes | Yes | N/A |
| Security Groups | Yes | Yes | No |
| Path-based Routing | Yes | No | No |
| Host-based Routing | Yes | No | No |
| Source IP Preserved | No (X-Forwarded-For) | Yes | Yes |
Target Groups
Target groups are logical groupings of targets that receive traffic from the load balancer.
Target Types
Instance: Route to EC2 instance IDs
- Traffic is routed using the primary private IP
IP: Route to specific IP addresses
- Can target IPs outside the VPC (on-premises via Direct Connect/VPN)
- Useful for containers with dynamic ports
Lambda: Route to Lambda functions (ALB only)
- Synchronous invocation
- Request/response payload conversion
Application Load Balancer: Route to another ALB (NLB only)
- Combine Layer 4 and Layer 7 features
- Static IP with advanced routing
```bash
# Create target group
aws elbv2 create-target-group \
--name my-web-targets \
--protocol HTTP \
--port 80 \
--vpc-id vpc-12345678 \
--target-type instance \
--health-check-protocol HTTP \
--health-check-path /health \
--health-check-interval-seconds 30 \
--healthy-threshold-count 2 \
--unhealthy-threshold-count 3
# Create Application Load Balancer
aws elbv2 create-load-balancer \
--name my-application-lb \
--subnets subnet-1a subnet-1b \
--security-groups sg-12345678 \
--type application \
--scheme internet-facing
# Create listener with default action
aws elbv2 create-listener \
--load-balancer-arn $ALB_ARN \
--protocol HTTPS \
--port 443 \
--certificates CertificateArn=$CERT_ARN \
--default-actions Type=forward,TargetGroupArn=$TG_ARN
```Health Checks
ELB continuously monitors the health of registered targets using configurable health checks.
Health Check Configuration
Key Parameters:
- Protocol: HTTP, HTTPS, TCP, or SSL
- Path: Health check endpoint (e.g.,
/health) - Port: Traffic port or override
- Interval: Time between checks (5-300 seconds)
- Timeout: Time to wait for response (2-120 seconds)
- Healthy Threshold: Consecutive successes required (2-10)
- Unhealthy Threshold: Consecutive failures before unhealthy (2-10)
- Success Codes: HTTP status codes for healthy (e.g., 200-299)
If ALL targets in ALL Availability Zones become unhealthy simultaneously, the load balancer enters 'fail-open' mode and routes traffic to all registered targets regardless of health status. This prevents complete service outage when health checks fail broadly.
Cross-Zone Load Balancing
Cross-zone load balancing determines how traffic is distributed across Availability Zones.
Cross-Zone Load Balancing Behavior
Enabled (default for ALB):
- Each load balancer node distributes traffic across all registered targets in all enabled AZs
- Results in more even distribution when AZs have unequal target counts
Disabled (default for NLB/GLB):
- Each load balancer node only distributes traffic to targets in its own AZ
- Reduces inter-AZ data transfer charges
- Can cause uneven distribution if AZs have different target counts
Data Transfer Costs:
- Cross-zone traffic may incur regional data transfer charges for NLB/GLB
- ALB does not charge for cross-zone data transfer
Sticky Sessions (Session Affinity)
Sticky sessions bind a user's session to a specific target for the duration of the session.
Sticky Session Types
| Type | Load Balancer | Cookie | Description |
|---|---|---|---|
| Duration-based | ALB | AWSALB | Generated by ALB, configurable expiration (1 sec - 7 days) |
| Application-based | ALB | Custom name | Application generates cookie, ALB tracks it |
| Load Balancer Cookie | CLB | AWSELB | Generated by Classic Load Balancer |
| Source IP | NLB | N/A | Based on source IP address (no cookie) |
Sticky Sessions Limitation
Sticky sessions require cross-zone load balancing to be enabled. If cross-zone load balancing is disabled, stickiness may break when the sticky target is in a different AZ than the load balancer node handling the request.
SSL/TLS and SNI
Server Name Indication (SNI)
SNI allows a load balancer to serve multiple TLS-secured websites with different certificates on a single listener.
How it works:
- Client includes hostname in TLS handshake
- ALB/NLB selects matching certificate
- If no match, uses default certificate
Key Points:
- Up to 25 certificates per load balancer (plus default)
- Supports both RSA and ECDSA certificates
- Automatic certificate renewal with ACM
- Smart selection chooses optimal certificate for client capabilities
```bash
# Add additional certificate to existing HTTPS listener
aws elbv2 add-listener-certificates \
--listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/def456 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123456789:certificate/xyz789
# List certificates on a listener
aws elbv2 describe-listener-certificates \
--listener-arn $LISTENER_ARN
```Connection Draining (Deregistration Delay)
Connection Draining
When a target is deregistered or becomes unhealthy, connection draining allows in-flight requests to complete before removing the target.
Configuration:
- Timeout: 0-3600 seconds (default: 300 seconds)
- 0 seconds: Immediately terminates connections
- State: Target shows as "draining" during this period
Best Practices:
- Set timeout based on longest expected request duration
- Use shorter timeouts for fast, stateless operations
- Use longer timeouts for long-polling or file uploads
ALB Authentication
ALB Built-in Authentication
ALB can authenticate users before passing requests to targets.
Supported Identity Providers:
- Amazon Cognito: User pools for user management
- OIDC-compliant IdPs: Okta, Auth0, Azure AD, Google
Authentication Flow:
- User accesses application
- ALB redirects to IdP for authentication
- User authenticates with IdP
- IdP returns token to ALB
- ALB validates token and forwards request with user claims
Benefits:
- Offload authentication from application
- Centralized authentication for multiple services
- No code changes required in backend
Architecture Patterns
Common Exam Scenarios
Load Balancer Selection: Static IP → NLB | PrivateLink → NLB | Path-based routing → ALB | Firewall/IDS → GLB | Lambda target → ALB | Gaming/low latency → NLB | WAF → ALB | Multiple domains/SNI → ALB | Preserve source IP → NLB
A company wants to expose an internal service to partner companies in different VPCs and AWS accounts without exposing it to the internet. What should they use?
A web application runs on EC2 instances behind an ALB. Users report being logged out randomly. The application stores session state locally on each instance. What is the MOST cost-effective solution?
A company needs to deploy a third-party firewall appliance to inspect all traffic entering their VPC. Which components are required? (Select TWO)
Best Practices
ELB Best Practices
- Use multiple AZs: Deploy load balancers across at least 2 AZs for high availability
- Enable access logs: Store access logs in S3 for debugging and compliance
- Configure proper health checks: Use application-specific health check endpoints
- Set appropriate timeouts: Match connection draining timeout to request duration
- Use security groups: Restrict access to load balancers (ALB/NLB)
- Enable deletion protection: Prevent accidental deletion in production
- Monitor with CloudWatch: Set alarms for UnHealthyHostCount, TargetResponseTime
- Use HTTPS/TLS: Always encrypt traffic in transit
- Leverage ACM: Use AWS Certificate Manager for free, auto-renewing certificates
Summary
Elastic Load Balancing is fundamental to building resilient, scalable architectures on AWS. The three load balancer types serve distinct purposes:
- ALB: Layer 7 features, HTTP/HTTPS, advanced routing, WAF integration
- NLB: Layer 4 performance, static IPs, PrivateLink, source IP preservation
- GLB: Virtual appliances, network security, traffic inspection
Understanding when to use each type, their features, and limitations is critical for the SAA-C03 exam.