13.4 Network Performance Optimization & Load-Balancing/Routing Design
Key Takeaways
- Basic Load Balancer was retired on September 30, 2025 — every new AZ-305 design must use Standard SKU, which is zone-redundant capable, carries an SLA, and blocks outbound traffic by default unless an outbound rule or NAT Gateway is configured.
- Traffic Manager is a DNS-based global load balancer with six routing methods (Priority, Weighted, Performance, Geographic, MultiValue, Subnet) that works for any protocol, not just HTTP(S) — unlike Front Door.
- Front Door operates at the HTTP(S) data-plane layer with real-time failover and caching; Traffic Manager only resolves DNS, so failover speed depends on DNS TTL — pick Front Door when sub-second failover for web traffic matters.
- User Defined Routes (UDRs) in a Route Table override Azure's default system routes to force traffic through a network virtual appliance or Azure Firewall — this is how hub-and-spoke topologies implement centralized inspection (forced tunneling).
- NAT Gateway is the recommended way to provide scalable, deterministic outbound internet connectivity and avoid SNAT port exhaustion, especially important since new VNets default to no outbound internet access after March 31, 2026.
Why This Topic Matters
This section merges two closely related official Domain 4 bullets — "Recommend a solution to optimize network performance" and "Recommend a load-balancing and routing solution" (objectives #48-49) — because in practice every AZ-305 performance/routing scenario draws from the same toolbox: Load Balancer, Traffic Manager, Front Door, Route Tables, and NAT Gateway. The exam tests whether you can correctly layer these services (regional vs. global, DNS-based vs. data-plane-based) rather than substitute one for another.
Azure Load Balancer
Load Balancer is a regional, Layer 4 (TCP/UDP) load balancer distributing traffic across backend VMs or VMSS instances.
- Basic Load Balancer was retired on September 30, 2025. Existing Basic instances keep running but are unsupported with no SLA — every new design must specify Standard SKU.
- Standard SKU supports zone-redundant frontends (one IP spread across all zones) or zonal frontends (pinned to one zone), and carries a 99.99% SLA.
- Critical trap: Standard Load Balancer blocks outbound internet access by default for backend instances that only have a Standard Load Balancer frontend — unlike Basic, which allowed implicit outbound. A Standard public Load Balancer needs an explicit outbound rule, or the subnet needs a NAT Gateway, to restore outbound connectivity.
- Load Balancer can be public (internet-facing frontend) or internal (private-IP frontend, for internal tier-to-tier balancing).
Azure Traffic Manager
Traffic Manager is a DNS-based global traffic distribution service — it does not proxy any data itself; it simply answers DNS queries with the IP address of the best endpoint per its routing method, and the client connects directly.
| Routing Method | Use Case |
|---|---|
| Priority | Active/passive failover — primary endpoint always answered unless unhealthy |
| Weighted | Distribute a fixed proportion of traffic across endpoints (e.g., A/B testing, gradual migration) |
| Performance | Route to the endpoint with lowest network latency from the client's region |
| Geographic | Route based on the geographic origin of the DNS query (data-sovereignty/compliance) |
| MultiValue | Return multiple healthy endpoint IPs in one DNS response for client-side selection |
| Subnet | Map ranges of end-user IP addresses to specific endpoints |
Because Traffic Manager works purely at the DNS layer, it supports any protocol (not just HTTP/S) — a key differentiator from Front Door, which is HTTP(S)-only. The trade-off is failover latency: a Traffic Manager failover only takes effect once clients re-resolve DNS, which depends on the record's TTL (often 30-300 seconds), whereas Front Door's data-plane health probing can redirect live HTTP(S) sessions far faster.
Front Door vs. Traffic Manager vs. Load Balancer — Layering
| Layer | Service | Scope | Protocol |
|---|---|---|---|
| Global edge (data plane, HTTP/S) | Azure Front Door | Global | HTTP/HTTPS only |
| Global DNS | Traffic Manager | Global | Any protocol |
| Regional | Load Balancer | Regional | Any TCP/UDP |
| Regional, L7 | Application Gateway | Regional | HTTP/HTTPS |
A common expert-tier design layers all four: Traffic Manager (or Front Door, for HTTP-only) routes globally across regions, each region's entry point is a regional Application Gateway or Front Door origin, and within each region a Standard Load Balancer distributes traffic across a VM Scale Set.
User Defined Routes (Route Tables)
Azure creates system routes automatically (VNet-local, on-premises via gateway, internet default route). A Route Table containing User Defined Routes (UDRs) lets an architect override these defaults — most commonly to implement forced tunneling: sending a subnet's 0.0.0.0/0 (internet-bound) or inter-subnet traffic to the next hop of a Virtual Appliance (an Azure Firewall's or NVA's private IP) instead of directly to the internet or destination. This is exactly how hub-and-spoke topologies force all spoke traffic through a centralized firewall for inspection before it reaches its destination. UDRs work alongside BGP-propagated routes from a VPN Gateway or ExpressRoute circuit — a UDR with a more specific prefix always wins over a less-specific BGP or system route.
NAT Gateway
NAT Gateway provides scalable, managed outbound-only internet connectivity for a subnet, solving the classic SNAT port exhaustion problem that plagues VMs behind a Standard Load Balancer under heavy outbound connection load. It is the modern replacement for relying on Load Balancer outbound rules at scale, and it becomes increasingly relevant because starting March 31, 2026, new virtual networks default to no outbound internet access (private subnets by default) — meaning outbound connectivity must now be explicitly designed rather than assumed, whether via NAT Gateway, Load Balancer outbound rules, or a firewall/NVA default route.
Exam Scenario
A multinational retailer runs a checkout API in three Azure regions and must: (1) route users to the lowest-latency healthy region, (2) support a legacy TCP-based payment protocol that is not HTTP, (3) force all outbound traffic from application VMs through a central Azure Firewall for inspection, and (4) prevent SNAT exhaustion during peak sale events. The design: Traffic Manager with the Performance routing method (handles the non-HTTP protocol requirement that rules out Front Door) directing clients to the nearest healthy region; within each region, a Standard, zone-redundant Load Balancer distributes traffic to a VM Scale Set; a Route Table with a UDR sends each subnet's default route to the regional Azure Firewall's private IP for forced-tunnel inspection; and a NAT Gateway attached to the application subnet handles high-volume outbound connections to third-party payment processors without SNAT exhaustion.
A global application uses a custom TCP-based protocol (not HTTP/HTTPS) and needs global traffic distribution with regional failover. Which service should the architect recommend?
After migrating backend VMs from a Basic to a Standard SKU Load Balancer, the VMs unexpectedly lose outbound internet connectivity. What is the most likely cause and fix?
A hub-and-spoke network needs all traffic leaving spoke VNets — whether destined for the internet or another spoke — to pass through a centralized Azure Firewall for inspection. Which mechanism enforces this?