Ankit ☁︎ ❯@ankit_ops2799
Azure Load Balancer: The Layer 4 Mechanics Everyone Misunderstands
Your app is running on three VMs behind an Azure Load Balancer. Traffic spikes. One VM hits 95% CPU while the other two sit idle at 10%. Users start seeing timeouts.
If ALB distributes traffic, why is your cluster uneven? Because ALB uses a five-tuple hash to route packets, not round-robin. When connection patterns are skewed, so is your load.
Here is exactly how it works under the hood.
Layer 4 vs Layer 7:
The most common mistake is treating ALB like an Application Gateway.
Application Gateway operates at Layer 7. It understands HTTP, cookies, URLs, and SSL termination.
Azure Load Balancer operates at Layer 4. It only understands TCP and UDP packets, IPs, and ports. It does not care about your application data. It just shifts packets at wire speed.
Different tools. Different problems. Picking the wrong one is an architecture mistake, not just a performance tradeoff.
The Five-Tuple Hash Trap:
By default, ALB uses a five-tuple hash to decide which backend instance handles a request.
Source IP. Source Port. Destination IP. Destination Port. Protocol.
Here is where engineers get burned. Modern browsers open multiple TCP connections concurrently. The client source port changes constantly. When the source port changes, the hash changes. Successive requests from the exact same client session can land on different backend VMs.
If your app relies on local in-memory sessions without a distributed cache like Redis, your users will experience broken sessions. This is not a bug. It is the default behavior working exactly as designed.
Solving Stickiness at Layer 4:
If you need traffic from a client to consistently hit the same backend VM, you must explicitly change the distribution mode.
Two-Tuple uses only Source IP and Destination IP. All traffic from a specific client IP lands on the same backend regardless of port changes.
Three-Tuple adds Protocol to the hash. Stickiness is scoped to the same protocol type.
Neither of these is on by default. You have to configure it intentionally.
Basic SKU is Dead:
Microsoft has announced the retirement of Basic Load Balancer SKUs, and organizations should migrate to Standard Load Balancer according to the published retirement timeline.
Standard Load Balancer is the recommended choice for production workloads due to its enhanced security, scalability, availability features, and Microsoft's migration guidance away from Basic SKUs. Secure by default with all inbound traffic blocked unless explicitly allowed via NSG. Scales to 1,000 backend instances. Zone-redundant with a 99.99% SLA.
The traffic flow and full component breakdown are in the blueprint below. Bookmark it before your next Azure architecture review.👇
