Elastic Load Balancing: ALB vs NLB

In one line

An Application Load Balancer routes HTTP(S) requests by host, path, and headers; a Network Load Balancer forwards raw TCP/UDP at very high throughput with static IPs — and both only send traffic to targets that pass health checks.

0/4 · 0%

Think of it like this

An ALB is a hotel concierge who reads your request ('restaurant reservation' vs 'room service') and sends you to the right department. An NLB is a highway toll gate: it doesn't care what's in your car, it just waves you into the next open lane as fast as possible.

Key ideas

01
Structure: a load balancer has LISTENERS (port + protocol, e.g. HTTPS:443), each listener has RULES, and rules forward to TARGET GROUPS — sets of instances, IPs, containers, or Lambdas — each with its own health check.
02
The APPLICATION LOAD BALANCER (ALB) works at layer 7: it terminates TLS (with a free ACM certificate — Phase 7), routes by path (/api/*), host (admin.example.com), headers, or query string, supports weighted target groups for canary deploys, WebSockets, gRPC, and can authenticate users with Cognito/OIDC before requests reach you.
03
The NETWORK LOAD BALANCER (NLB) works at layer 4: TCP/UDP/TLS, millions of requests per second, ultra-low latency, a static IP per AZ (or your own Elastic IPs) — useful when clients must allowlist IPs, for non-HTTP protocols, or to expose a service privately via PrivateLink.
04
HEALTH CHECKS: the load balancer periodically calls a path (e.g. /healthz) on each target and only routes to those passing. Make the health endpoint cheap and honest — it should reflect whether THIS instance can serve, not whether every downstream dependency is up, or one slow database takes your whole fleet out of rotation.
05
The client's real IP: behind an ALB your app sees the ALB's IP as the source; the original client IP is in the X-Forwarded-For header. NLBs preserve the client IP by default for instance targets. Also set DEREGISTRATION DELAY sensibly so in-flight requests finish during deploys.
06
The GATEWAY LOAD BALANCER (GWLB) is the third type: it works at layer 3 and transparently sends all traffic through a fleet of network appliances (firewalls, intrusion detection, deep packet inspection from vendors such as Palo Alto or Fortinet) using GENEVE encapsulation, then back on its way. You meet it in central 'inspection VPCs' in large landing zones (DevOps guide, advanced AWS), not in front of your web apps. The Classic Load Balancer is legacy; don't use it for new work.

Code & diagrams

alb-path-routing.shbash

# HTTPS listener with an ACM certificate, default action → web target group
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN --protocol HTTPS --port 443 \
  --certificates CertificateArn=$CERT_ARN \
  --default-actions Type=forward,TargetGroupArn=$WEB_TG

# /api/* → api target group
aws elbv2 create-rule --listener-arn $LISTENER_ARN --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=$API_TG

# Health check tuned for fast detection
aws elbv2 modify-target-group --target-group-arn $API_TG \
  --health-check-path /healthz --health-check-interval-seconds 10 \
  --healthy-threshold-count 2 --unhealthy-threshold-count 3

# Who's healthy right now?
aws elbv2 describe-target-health --target-group-arn $API_TG \
  --query 'TargetHealthDescriptions[].[Target.Id,TargetHealth.State,TargetHealth.Reason]' --output table

AlbRoutingdiagram

Rendering diagram…

Explain it without notes

A partner company needs to allowlist a fixed set of IP addresses for your API. Which load balancer fits, and why?

Why is a health check that verifies the database, Redis, and three downstream APIs a bad idea?

Practice

Your app logs show every request coming from 10.0.1.x addresses. Why, and how do you get the real client IP?

Describe how you'd do a 10% canary release of a new API version with an ALB.

Trade-offs

↔
ALBs give rich routing, TLS, and auth features but add a few milliseconds and don't offer static IPs; NLBs are faster with stable IPs but know nothing about HTTP, so path routing, redirects, and header inspection move into your application or a proxy behind them.

Done when you can

I know the listener → rule → target group structure.
I can choose between ALB and NLB for a given requirement.
I write health checks that reflect instance health, not dependency health.
I know how the client IP reaches my app behind each load balancer type.