In one sentence. A load balancer is one front door with several rooms behind it. Visitors knock on the door; the balancer sends each to a room that is answering. It keeps asking each room "are you alive?" (the health probe) and stops sending people to rooms that go quiet. Azure has four such products; the exam wants you to pick by layer (does it understand web URLs or just ports?) and reach (one region or the world?).
| Product | Understands | Reach | Pick when |
|---|---|---|---|
| Azure Load Balancer | TCP/UDP ports (layer 4) | One region | Spread traffic across VMs; public front or internal |
| Application Gateway | HTTP/HTTPS (layer 7) | One region | Route by URL path or host name, terminate SSL, cookie stickiness, web application firewall |
| Traffic Manager | DNS answers | Global | Send each user to the nearest or healthiest region |
| Azure Front Door | HTTP (layer 7) | Global | Worldwide web acceleration, caching, WAF at the edge |
You, the admin: put web1 and web2 behind one address
- Load balancers › + Create: SKU Standard, type Public, new Standard public IP as the front-end.
- Backend pools tab: add web1 and web2 NICs (same VNet).
- Inbound rules tab: add a health probe HTTP, port 80, path /health, every 5 s. Add a load balancing rule front port 80 → back port 80, TCP, that probe, session persistence None.
- Optional inbound NAT rule: front port 50001 → web1 port 3389 so you can RDP to one specific server through the LB.
- Because Standard is closed by default, the NSG on the Web subnet must allow 80 from Internet and allow the probe (service tag AzureLoadBalancer) or the pool shows unhealthy.
- Public LB has a public front IP; internal LB has a private IP from a subnet and sits between tiers.
- Session persistence: None (round robin), Client IP, Client IP and protocol. Floating IP is for SQL Always On listeners; HA ports (all ports in one rule) is for firewalls behind an internal LB.
- SKUs: Basic is retiring, has no SLA and no zones. Standard is zone-redundant, 99.99%, and requires Standard public IPs everywhere.
When traffic does not arrive, check in this order
- Probe: is the service really listening on the probe port and path? A local Windows firewall blocking 80 fails the probe.
- NSG: is the probe source (AzureLoadBalancer tag, 168.63.129.16) and the client port allowed on both subnet and NIC NSGs?
- Pool: are the VMs in the same VNet as the LB?
- SKU: Standard LB with a Basic public IP, or vice versa, is refused.
Network Watcher: the diagnostic kit
| Question | Tool (Network Watcher › …) |
|---|---|
| Would a packet from X to Y:443 be allowed, and by which NSG rule? | IP flow verify |
| Where does a packet to 10.20.0.4 go next, via which route? | Next hop |
| Can VM A reach VM B port 1433 right now, where does it fail? | Connection troubleshoot |
| Keep testing reachability and latency and alert me | Connection monitor |
| Which rules actually apply to this NIC | Effective security rules |
| Who talked to whom through this NSG last week | NSG / VNet flow logs + Traffic Analytics |
| Capture packets from a VM | Packet capture (needs the Network Watcher agent extension) |
| Draw me the network | Topology |
Trap wording. "URL-path routing / SSL offload" = Application Gateway. "Users to the nearest region by DNS" = Traffic Manager. "RDP to one VM through the LB" = inbound NAT rule. "Standard LB, all VMs unhealthy, service is up" = NSG blocking the probe.