Load Balancers — ALB vs Cloud Load Balancing vs Azure LB

Load balancers distribute incoming traffic across multiple backend instances so no single server takes the full hit. You've seen them in system design — now we're looking at what each cloud provider actually offers, where the implementations diverge, and which gotchas will bite you on deploy day.

L4 vs L7 Recap

A Layer 4 load balancer operates at the transport layer (TCP/UDP). It sees IP addresses and ports but not HTTP headers, URLs, or cookies. It's fast, simple, and works for any protocol.

A Layer 7 load balancer understands HTTP(S). It can route based on URL path (/api/* to one target group, /static/* to another), host headers (multiple domains on one LB), HTTP methods, and query strings. It can also terminate TLS, inject headers, and redirect HTTP to HTTPS. Most web workloads want L7.

AWS Implementation

AWS has four load balancer types, and picking the wrong one wastes money or limits your architecture:

Application Load Balancer (ALB) — the default choice for HTTP/HTTPS. Supports path-based routing, host-based routing, weighted target groups, and WebSockets. Targets can be EC2 instances, IP addresses, Lambda functions, or containers. You define listeners (port + protocol), rules (conditions for routing), and target groups (the backends). ALB is the workhorse.

Network Load Balancer (NLB) — Layer 4, handles millions of requests per second with ultra-low latency. Supports static IP addresses (one per AZ) and preserves source IP. Use it for TCP/UDP workloads, gRPC, or when you need a fixed IP for firewall whitelisting.

Gateway Load Balancer (GWLB) — routes traffic through third-party virtual appliances (firewalls, IDS/IPS) transparently. Most teams won't touch this unless they're running network security appliances.

Classic Load Balancer (CLB) — legacy. If you still have one, migrate it. It lacks target groups, path routing, and WebSocket support. AWS keeps it alive for backward compatibility.

GCP Implementation

GCP's load balancing is its standout networking product. The global external HTTP(S) load balancer gives you a single anycast IP address that routes traffic to the nearest healthy backend anywhere in the world — using Google's private backbone, not the public internet. No CloudFront required, no regional ALBs to stitch together.

GCP organizes load balancers by scope and layer:

• Global external HTTP(S) LB: L7, single global IP, backends in any region, URL maps for routing
• Regional external HTTP(S) LB: L7 but region-scoped, useful for data residency requirements
• External TCP/UDP Network LB: L4, regional, preserves source IP
• Internal HTTP(S) LB: L7 for internal services (service mesh without the mesh)
• Internal TCP/UDP LB: L4 for internal traffic

The global HTTP(S) load balancer is the reason GCP wins on networking simplicity for globally distributed apps. One IP, one config, backends worldwide.

Azure Implementation

Azure splits load balancing across four products, each targeting a different use case:

Azure Load Balancer — L4 only. Basic and Standard SKUs (always use Standard — Basic has no SLA and is being retired). Supports both public and internal configurations. Azure's equivalent to NLB.

Application Gateway — L7 with built-in WAF, SSL termination, URL-based routing, and multi-site hosting. Regional. Think of it as ALB + WAF in one product.

Azure Front Door — global L7 load balancer + CDN + WAF. The closest equivalent to GCP's global load balancer. Routes to the nearest backend using anycast, caches static content at the edge, and provides DDoS protection. This is Azure's answer for global apps.

Traffic Manager — DNS-based traffic routing. Not a true load balancer — it returns different DNS answers based on routing method (geographic, performance, weighted, priority). Works across regions and even across providers, but limited to DNS-level granularity and TTL-bound failover times.

Shared Concepts Everyone Gets Wrong

Health checks determine whether a backend is healthy enough to receive traffic. Configure the path (use a dedicated /health endpoint that checks dependencies, not just returns 200), the interval, and the threshold for marking unhealthy. Overly aggressive thresholds cause flapping — one slow response shouldn't take a server out of rotation.

Connection draining (called "deregistration delay" in AWS) is what happens when you remove a target. The load balancer stops sending new connections but lets existing ones finish. The default is usually 300 seconds. If you skip this or set it too low, every deploy will produce 502 errors as the LB tears down connections to targets that are shutting down. This is the number one cause of "502s on every deploy."

Sticky sessions (session affinity) pin a user to the same backend using cookies. This seems convenient but fights against the entire point of load balancing. If that backend dies, the user loses their session. Prefer stateless backends with externalized session storage (Redis, DynamoDB).

TLS termination at the load balancer means the LB handles the SSL/TLS handshake and forwards unencrypted HTTP to backends. This offloads CPU from your app servers and lets you manage certificates in one place (ACM on AWS, Google-managed certs on GCP, Key Vault on Azure). For compliance requirements that demand end-to-end encryption, use TLS re-encryption to the backend.

Cross-zone load balancing distributes traffic evenly across all targets in all AZs, not just the targets in the same AZ as the load balancer node. AWS ALB enables this by default; NLB doesn't (and charges for cross-zone data transfer when you enable it). Without it, uneven instance counts across AZs lead to hotspots.

Idle timeout is how long the LB keeps an idle connection open. ALB defaults to 60 seconds. If your backend's keep-alive timeout is shorter than the LB's idle timeout, the LB will try to reuse a connection the backend already closed — producing intermittent 502s. Set your app's keep-alive higher than the LB's idle timeout.

Side-by-Side Comparison

Aspect	AWS	GCP	Azure
L7 (HTTP)	ALB	Global/Regional HTTP(S) LB	Application Gateway / Front Door
L4 (TCP/UDP)	NLB	Network LB	Azure Load Balancer
Global L7	CloudFront + ALB	Global HTTP(S) LB (single IP)	Front Door
DNS-based routing	Route 53 routing policies	Cloud DNS routing	Traffic Manager
Built-in WAF	AWS WAF (separate)	Cloud Armor (separate)	Integrated in App Gateway / Front Door
Static IP	NLB (per AZ)	Global LB (single anycast IP)	Standard LB
Internal L7	Internal ALB	Internal HTTP(S) LB	Internal App Gateway

Choosing the Right Load Balancer

Start with L7 if your traffic is HTTP(S). Path-based and host-based routing, TLS termination, and richer health checks are almost always what you want. Drop to L4 only if you need raw throughput for non-HTTP protocols, source IP preservation without proxy protocol, or static IPs.

For global distribution: GCP's global LB is the simplest. On AWS, pair CloudFront with regional ALBs. On Azure, use Front Door.

For internal service-to-service traffic: every provider has internal load balancers. Use them — don't route internal traffic through your public-facing LB.

Key Takeaways

• ALB (L7) is the default choice on AWS; NLB (L4) is for TCP/UDP or when you need static IPs — don't use CLB for anything new
• GCP's global HTTP(S) load balancer with a single anycast IP is the most elegant global load balancing solution across all three providers
• Connection draining is the number one cause of deploy-time 502s — set your deregistration delay to match your app's shutdown grace period
• Keep your backend keep-alive timeout longer than the LB's idle timeout, or you'll chase intermittent 502s forever
• Sticky sessions fight against load balancing — externalize state to Redis or a database instead
• Cross-zone load balancing matters: without it, uneven target counts create hotspots that health checks won't catch

Next, we'll look at CDNs — the edge layer that sits in front of these load balancers and caches content closer to users.