PreviewLab2.5 hours

Load Balancers (ALB, NLB)

Application and Network Load Balancers, target groups, listeners, routing rules, health checks, static NLB IPs, and access logs.

This builds on The VPC Itself through VPC Endpoints (Policies). Your VPC, subnets, route tables, IGW, and SGs must exist.
In a new terminal session, run the resume script at the end of VPC Endpoints (Policies).
Read the callout before every step. Predict what will happen, then run it.

ALB: Create, Target Group, Listener

Goal

Create an Application Load Balancer end-to-end. Understand the three components (ALB, target group, listener) and how they connect.

Estimated time: 45 minutes

(ALB vs NLB) choose before you create

What's happening here

AWS has two main load balancer types:

ALB (Application Load Balancer): operates at Load Balancers (HTTP/HTTPS). It terminates TLS, reads HTTP headers and paths, and can route based on hostname, path, query string, and HTTP method. It rewrites requests, supports WebSockets, and integrates with WAF. Use ALB for any HTTP/HTTPS workload: APIs, web apps, microservices.

NLB (Network Load Balancer): operates at Security Groups vs NACLs (TCP/UDP/TLS). It forwards packets without modifying them, the client's source IP is preserved end-to-end. It handles millions of requests per second with ultra-low latency and supports static IPs and Elastic IPs per AZ. Use NLB for non-HTTP protocols (gRPC, MQTT, raw TCP), latency-critical paths, and when you need a stable IP address for the load balancer.

The choice is binary: if your protocol is HTTP/HTTPS, use ALB. Everything else, use NLB.

Property	ALB	NLB
Layer	L7 (HTTP/HTTPS)	L4 (TCP/UDP/TLS)
Path routing	Yes	No
Host routing	Yes	No
Header routing	Yes	No
TLS termination	Yes (at ALB)	Yes (pass-through or terminate)
Source IP	X-Forwarded-For header	Preserved natively
Static IP	No (DNS only)	Yes (EIP per AZ)
Throughput	High	Extreme (millions rps)
Latency	Low	Ultra-low
WebSocket	Yes	Yes
WAF integration	Yes	No
gRPC	Yes	Yes
Use when	HTTP/HTTPS workloads	Non-HTTP, static IP, ultra-low latency

Create the ALB

What's happening here

The ALB is placed in public subnets across multiple AZs. AWS requires at least two subnets in different AZs for an internet-facing ALB (this ensures the ALB itself survives an AZ failure. The ALB gets a DNS name (not an IP)) this is important: ALB IPs change as it scales, so you must always use the DNS name. The internet-facing scheme means it has a public-facing DNS name and accepts traffic from the internet. internal scheme means it only accepts traffic from within the VPC (used for internal load balancing between tiers).

bash

export ALB_ARN=$(aws elbv2 create-load-balancer \
  --name networking-lab-alb \
  --type application \
  --scheme internet-facing \
  --subnets $PUBLIC_SUBNET_AZ1 $PUBLIC_SUBNET_AZ2 \
  --security-groups $SG_ALB \
  --region $AWS_REGION \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

echo "ALB ARN: $ALB_ARN"

export ALB_DNS=$(aws elbv2 describe-load-balancers \
  --load-balancer-arns $ALB_ARN \
  --region $AWS_REGION \
  --query 'LoadBalancers[0].DNSName' --output text)

echo "ALB DNS: $ALB_DNS"

# Wait for active state
echo "Waiting for ALB to become active..."
aws elbv2 wait load-balancer-available \
  --load-balancer-arns $ALB_ARN --region $AWS_REGION
echo "ALB active."

Inspect what was created:

bash

aws elbv2 describe-load-balancers \
  --load-balancer-arns $ALB_ARN \
  --region $AWS_REGION \
  --query 'LoadBalancers[0].{DNS:DNSName,Scheme:Scheme,State:State.Code,AZs:AvailabilityZones[*].ZoneName}'

Checkpoint: ALB state is active. DNS name is set. Two AZs listed.

Create a target group

What's happening here

A target group is where the ALB sends matched traffic. It has three key properties:

Target type: ip (Fargate/Lambda (registers private IPs), instance (EC2) registers instance IDs), or lambda. We use ip because that's what ECS Fargate requires.
Health check: the ALB polls each registered target on this path/port every N seconds. Targets that fail the health check are taken out of rotation. Traffic is only sent to healthy targets.
Deregistration delay: when a target is removed, the ALB waits this long (default 300s) to let in-flight requests complete before stopping routing. Set it low (30s) for fast-deploys where you want old tasks to drain quickly.

The target group exists independently of the ALB, it can be shared across multiple ALBs, or exist with no ALB attached.