TECH **AWS Elastic Load Balancing (ALB, NLB, GWLB) – Zero-Fluff Study Guide**

AWS Elastic Load Balancing (ALB, NLB, GWLB) – Zero-Fluff Study Guide

For AWS Solutions Architect – Associate (SAA-C03) & Real-World Deployments

1. What This Is & Why It Matters

You’re a cloud engineer at a fintech startup. Your app runs on EC2 instances, but traffic spikes during market hours crash your servers. Worse, your monolithic backend can’t scale horizontally. Elastic Load Balancing (ELB) is your superpower: it distributes traffic across multiple targets (EC2, Lambda, containers), improves fault tolerance, and enables zero-downtime deployments.

Why this matters in production:
- Without ELB: A single EC2 instance fails → your app goes down. Users see 503 errors.
- With ELB: Traffic auto-routes to healthy instances. You can roll out updates without downtime.
- Security: ALBs terminate TLS, reducing load on your servers. NLBs preserve client IPs for logging.
- Cost: You pay only for what you use ($0.0225/hour for ALB + $0.008/GB data processed).

Real-world scenario:
You inherit a legacy app with a single EC2 instance. Your CTO demands 99.99% uptime. You’ll use an ALB to: 1. Distribute traffic across 3 AZs.
2. Terminate HTTPS at the load balancer (offloading SSL from EC2).
3. Route /api to a new Lambda function and /static to S3.

2. Core Concepts & Components

? Elastic Load Balancer (ELB)

• Definition: AWS-managed service that distributes incoming traffic across multiple targets (EC2, Lambda, IP addresses).
• Production insight: ELB scales automatically, but you pay for data processed. Monitor ProcessedBytes in CloudWatch.

? Application Load Balancer (ALB)

• Definition: Layer 7 (HTTP/HTTPS) load balancer with path/host-based routing, TLS termination, and WebSocket support.
• Production insight: Use ALB for microservices (e.g., /users → User Service, /orders → Order Service). ⚠️ ALB adds ~400ms latency (vs. NLB’s ~100ms).

? Network Load Balancer (NLB)

• Definition: Layer 4 (TCP/UDP) load balancer with ultra-low latency (~100ms), static IPs, and support for TLS passthrough.
• Production insight: Use NLB for gaming, VoIP, or financial trading apps where latency matters. ⚠️ NLB doesn’t terminate TLS (your targets must handle SSL).

? Gateway Load Balancer (GWLB)

• Definition: Layer 3 (IP) load balancer for third-party virtual appliances (firewalls, IDS/IPS). Uses GENEVE encapsulation.
• Production insight: Deploy GWLB to route traffic through a Palo Alto firewall or Cisco ASA before hitting your app. ⚠️ GWLB requires a VPC endpoint.

? Target Group

• Definition: Logical grouping of targets (EC2, Lambda, IP) that the load balancer routes traffic to.
• Production insight: Health checks determine if a target is healthy. Misconfigured health checks cause traffic to dead instances.

? Listener

• Definition: Listens on a port (e.g., 443) and forwards traffic to a target group based on rules.
• Production insight: ALB listeners support HTTPS (TLS termination), but NLB listeners do not (use TLS passthrough).

? Security Groups vs. NACLs

• Security Group: Stateful firewall for the load balancer. ⚠️ ALB must allow inbound 80/443 from 0.0.0.0/0 (public internet).
• NACL: Stateless firewall at the subnet level. ⚠️ NACLs must allow ephemeral ports (1024–65535) for return traffic.

? Cross-Zone Load Balancing

• Definition: Distributes traffic evenly across all targets in all AZs (enabled by default for ALB, disabled for NLB).
• Production insight: Enable for NLB if you want even distribution (extra cost). Disable for ALB if you want to save money (but risk uneven traffic).

? Sticky Sessions (Session Affinity)

• Definition: Binds a user’s session to a specific target (using cookies for ALB, source IP for NLB).
• Production insight: Use for stateful apps (e.g., shopping carts). ⚠️ Breaks horizontal scaling if overused.

3. Step-by-Step: Deploy an ALB for a Web App

Prerequisites:
- AWS account with admin IAM permissions.
- 2+ EC2 instances (Amazon Linux 2) in different AZs (e.g., us-east-1a, us-east-1b).
- A registered domain (e.g., example.com) in Route 53 (optional but recommended).

Step 1: Launch EC2 Instances

# Launch 2 EC2 instances in different AZs
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \  # Amazon Linux 2
  --instance-type t3.micro \
  --key-name MyKeyPair \
  --security-group-ids sg-12345678 \  # Allow HTTP (80) from ALB
  --subnet-id subnet-12345678 \        # us-east-1a
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=WebServer1}]'

aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t3.micro \
  --key-name MyKeyPair \
  --security-group-ids sg-12345678 \
  --subnet-id subnet-87654321 \        # us-east-1b
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=WebServer2}]'

Verify:
- SSH into each instance and install a web server: bash sudo yum update -y sudo yum install -y httpd sudo systemctl start httpd echo "<h1>Hello from $(hostname)</h1>" | sudo tee /var/www/html/index.html

Step 2: Create a Target Group

aws elbv2 create-target-group \
  --name MyWebApp-TG \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-12345678 \
  --health-check-path / \
  --health-check-interval-seconds 30 \
  --health-check-timeout-seconds 5 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2 \
  --target-type instance

Register targets:

aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyWebApp-TG/1234567890abcdef \
  --targets Id=i-1234567890abcdef0,Port=80 Id=i-0987654321fedcba0,Port=80

Verify health checks:

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyWebApp-TG/1234567890abcdef

Expected output:

{
  "TargetHealthDescriptions": [
    {
      "Target": { "Id": "i-1234567890abcdef0", "Port": 80 },
      "HealthCheckPort": "80",
      "TargetHealth": { "State": "healthy" }
    }
  ]
}

Step 3: Create an ALB

aws elbv2 create-load-balancer \
  --name MyWebApp-ALB \
  --subnets subnet-12345678 subnet-87654321 \  # Must be in 2+ AZs
  --security-groups sg-12345678 \               # Allow HTTP/HTTPS
  --scheme internet-facing \
  --type application

Note the ALB ARN (e.g., arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/MyWebApp-ALB/1234567890abcdef).

Step 4: Configure Listeners & Routing

# Create an HTTP listener (port 80)
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/MyWebApp-ALB/1234567890abcdef \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyWebApp-TG/1234567890abcdef

Optional: Add HTTPS (port 443) with ACM certificate:

aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/MyWebApp-ALB/1234567890abcdef \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyWebApp-TG/1234567890abcdef

Step 5: Test the ALB

1. Get the ALB DNS name:
   bash
aws elbv2 describe-load-balancers \
--names MyWebApp-ALB \
--query 'LoadBalancers[0].DNSName' \
--output text
2. Curl the DNS name:
   bash
curl http://MyWebApp-ALB-1234567890.us-east-1.elb.amazonaws.com
   Expected output:
   ```
   

   Hello from ip-10-0-1-123.ec2.internal

``` 3. Refresh multiple times—you should see responses from both EC2 instances.

Step 6: (Optional) Route 53 + Custom Domain

1. Create a Route 53 record:
   bash
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABCDEFGHIJ \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K", # ALB hosted zone ID (us-east-1)
"DNSName": "dualstack.MyWebApp-ALB-1234567890.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}]
}'
2. Test:
   bash
curl https://app.example.com

4. ? Production-Ready Best Practices

Security

• IAM: Restrict ALB access with security groups. ⚠️ Never allow 0.0.0.0/0 to your EC2 instances—only allow the ALB’s security group.
• TLS: Always terminate HTTPS at the ALB (not EC2). Use ACM certificates (free).
• WAF: Attach AWS WAF to ALB to block SQLi, XSS, and DDoS.
• Private ALBs: Use internal scheme for backend services (e.g., databases).

Cost Optimization

• ALB vs. NLB: ALB is ~2x more expensive than NLB. Use NLB for TCP/UDP (e.g., gaming, VoIP).
• Idle ALBs: Delete unused ALBs—you pay $0.0225/hour even if no traffic.
• Data Processing: Monitor ProcessedBytes in CloudWatch. Compress responses to reduce costs.

Reliability & Maintainability

• Multi-AZ: Deploy ALB in 2+ AZs (mandatory for high availability).
• Health Checks: Use /health endpoint (not /). Set healthy-threshold=2, unhealthy-threshold=2.
• Deregistration Delay: Set to 300s (5 mins) to avoid dropping in-flight requests during deployments.
• Tags: Tag ALBs with Environment=prod, Team=backend.

Observability

• CloudWatch Metrics:
• HTTPCode_Target_5XX_Count (backend errors).
• UnHealthyHostCount (failed health checks).
• RequestCount (traffic volume).
• Access Logs: Enable ALB access logs to S3 (debug 5XX errors).
• Alarms: Set up CloudWatch alarms for HTTPCode_ELB_5XX_Count > 0.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (SAA-C03)

Question Patterns

1. ALB vs. NLB:
2. "You need to route HTTP traffic to Lambda and EC2. Which LB?" → ALB (supports Lambda, path-based routing).

3. "You need ultra-low latency for a trading app. Which LB?" → NLB (~100ms latency).

4. TLS Termination:

5. "Where should you terminate TLS for a web app?" → ALB (offloads SSL from EC2).

6. Sticky Sessions:

7. "A user’s shopping cart disappears after refresh. What’s missing?" → Sticky sessions (ALB with app-cookie or lb-cookie).

8. GWLB:

9. "You need to route traffic through a Palo Alto firewall. Which LB?" → GWLB (GENEVE encapsulation).

⚠️ Trap Distinctions

7. ? Hands-On Challenge

Challenge:
Deploy an ALB that routes: - /api → Lambda function (returns {"status": "ok"}).
- /static → S3 bucket (serves index.html).

Solution:
1. Create a Lambda function:
python
def lambda_handler(event, context):
return {"statusCode": 200, "body": '{"status": "ok"}'} 2. Create an S3 bucket and upload index.html.
3. Create 2 target groups:
- Lambda-TG (target type: Lambda).
- S3-TG (target type: IP, point to S3 bucket’s VPC endpoint).
4. Configure ALB listeners with path-based routing:
- /api → Lambda-TG.
- /static → S3-TG.

Why it works:
ALB supports Lambda as a target and can route to S3 via VPC endpoints.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. AWS ELB Documentation
2. ALB Best Practices 3