Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple targets — EC2 instances, containers, IP addresses, or Lambda functions. ELB provides fault tolerance, SSL termination, and path-based routing for production applications.

Load Balancer Types

Type Layer Use Case Key Features
ALB (Application) Layer 7 (HTTP/HTTPS) Web apps, microservices, APIs Path/host routing, WebSocket, Lambda targets
NLB (Network) Layer 4 (TCP/UDP) High performance, static IP, gaming Millions of req/sec, preserve source IP
GLB (Gateway) Layer 3/4 Security appliances Inline firewall/IDS inspection
CLB (Classic) Layer 4/7 Legacy Avoid for new deployments

Create an Application Load Balancer 

  # Create ALB in public subnets
aws elbv2 create-load-balancer \
    --name web-alb \
    --subnets subnet-public-1a subnet-public-1b \
    --security-groups sg-alb \
    --scheme internet-facing \
    --type application \
    --ip-address-type ipv4

# Create target group
aws elbv2 create-target-group \
    --name web-targets \
    --protocol HTTP \
    --port 8080 \
    --vpc-id vpc-xxx \
    --health-check-path /health \
    --health-check-interval-seconds 30 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 3 \
    --matcher HttpCode=200

# Register EC2 instances
aws elbv2 register-targets \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-targets/xxx \
    --targets Id=i-instance1 Id=i-instance2

# Create listener (HTTP → redirect to HTTPS)
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123:loadbalancer/app/web-alb/xxx \
    --protocol HTTPS \
    --port 443 \
    --certificates CertificateArn=arn:aws:acm:us-east-1:123:certificate/xxx \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-targets/xxx

SSL/TLS with ACM 

  # Request certificate (must validate domain ownership)
aws acm request-certificate \
    --domain-name api.example.com \
    --subject-alternative-names "*.example.com" \
    --validation-method DNS

# ACM certificates are free and auto-renew
# Attach to ALB listener — no manual cert management

Use TLS 1.3 security policy: ELBSecurityPolicy-TLS13-1-2-2021-06

Path-Based and Host-Based Routing 

  # Route /api/* to API target group
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:us-east-1:123:listener/app/web-alb/xxx/yyy \
    --priority 10 \
    --conditions Field=path-pattern,Values='/api/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/api-targets/xxx

# Route admin.example.com to admin target group
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:us-east-1:123:listener/app/web-alb/xxx/yyy \
    --priority 20 \
    --conditions Field=host-header,Values='admin.example.com' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/admin-targets/xxx

Health Checks

ALB health checks determine which targets receive traffic:

Setting Recommended Notes
Path /health Return 200 with minimal processing
Interval 30 seconds Faster = quicker failure detection
Healthy threshold 2 Consecutive successes to mark healthy
Unhealthy threshold 3 Consecutive failures to mark unhealthy
Timeout 5 seconds Must be less than interval 
  # Minimal health check endpoint
@app.route('/health')
def health():
    return {'status': 'ok'}, 200

Important: Health checks should verify dependencies lightly — don’t query the database on every check unless necessary.

Sticky Sessions (Session Affinity) 

  aws elbv2 modify-target-group-attributes \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-targets/xxx \
    --attributes Key=stickiness.enabled,Value=true \
                   Key=stickiness.type,Value=lb_cookie \
                   Key=stickiness.lb_cookie.duration_seconds,Value=86400

Prefer stateless applications with shared session storage (Redis) over sticky sessions when possible.

Network Load Balancer

For TCP/UDP workloads requiring extreme performance:

  aws elbv2 create-load-balancer \
    --name tcp-nlb \
    --type network \
    --scheme internet-facing \
    --subnets subnet-public-1a subnet-public-1b

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123:loadbalancer/net/tcp-nlb/xxx \
    --protocol TCP \
    --port 5432 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/db-targets/xxx

NLB preserves client source IP and handles millions of requests per second.

ALB + Auto Scaling Integration 

  # ASG uses ELB health checks instead of EC2 status checks
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name web-asg \
    --launch-template LaunchTemplateName=web-lt,Version='$Latest' \
    --min-size 2 --max-size 10 --desired-capacity 2 \
    --vpc-zone-identifier "subnet-private-1a,subnet-private-1b" \
    --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-targets/xxx \
    --health-check-type ELB \
    --health-check-grace-period 300

WAF Integration

Protect ALB from common web attacks:

  # Associate WAF Web ACL with ALB
aws wafv2 associate-web-acl \
    --web-acl-arn arn:aws:wafv2:us-east-1:123:regional/webacl/prod-waf/xxx \
    --resource-arn arn:aws:elasticloadbalancing:us-east-1:123:loadbalancer/app/web-alb/xxx

WAF rules: rate limiting, SQL injection, XSS, geo-blocking, IP allowlists.

Real-World Scenario: Microservices Architecture 

                      Internet
                       ↓
              ALB (api.example.com)
              ┌────────┼────────┐
              ↓        ↓        ↓
         /api/users  /api/orders  /api/products
              ↓        ↓        ↓
         Users TG    Orders TG   Products TG
              ↓        ↓        ↓
         ECS Service ECS Service ECS Service
         (2 tasks)   (4 tasks)   (2 tasks)
Component Configuration
ALB HTTPS, WAF attached, access logs to S3
Target groups One per microservice, health check /health
ECS services Auto Scaling on CPU, min 2 tasks per service
DNS Route 53 alias record → ALB

ALB vs NLB Decision Guide

Requirement Choose
HTTP routing by path/host ALB
WebSocket support ALB
Lambda as target ALB
Static IP address NLB
TCP/UDP (non-HTTP) NLB
Extreme low latency NLB
Preserve client IP NLB

Common Mistakes

  1. ALB in single subnet/AZ — deploy across minimum 2 AZs
  2. Health check too aggressive — causes flapping during deployments
  3. Security group misconfiguration — ALB SG must allow 443 inbound; target SG must allow ALB SG on app port
  4. No access logs — enable ALB access logs to S3 for debugging
  5. Classic Load Balancer for new apps — use ALB or NLB
  6. Ignoring connection draining — default 300s; adjust for long-running requests

Troubleshooting

Issue Check Fix
502 Bad Gateway Target unhealthy or not listening Verify health check path and port
503 Service Unavailable No healthy targets Check target group health tab
SSL certificate error Wrong cert or expired Use ACM; verify domain validation
Intermittent timeouts SG or NACL blocking ALB → target SG must allow traffic
High latency Target overloaded Scale ASG; check target response time metric

Best Practices

  • Deploy load balancers across at least 2 AZs
  • Terminate SSL at the ALB with ACM certificates
  • Enable access logs to S3 for audit and debugging
  • Attach WAF for public-facing applications
  • Use target group stickiness only when necessary
  • Configure connection idle timeout (default 60s) for your app’s needs
  • Monitor TargetResponseTime and HTTPCode_Target_5XX_Count in CloudWatch

Next: Well-Architected Framework.