Before configuring anything, decide which layer the traffic needs handling at and whether it is regional or global. The table below is the quickest way to rule services in or out. Figure 9.1 places each service by traffic type and scope.
| Service | Layer / scope | Handles | Doesn’t fit |
|---|---|---|---|
| Azure Load Balancer (Standard) | L4, regional (cross-region tier for global) | Any TCP/UDP port, internal or public, IPv4/IPv6 dual-stack; cheapest option | HTTP-aware routing |
| Application Gateway (v1/v2) | L7, regional | HTTP(S) proxy (limited TLS/TCP proxy); multi-site by host name | UDP, arbitrary ports, IPv6 backend addresses; costs more |
| Traffic Manager | DNS, global | Chooses an endpoint per DNS query with health checks | Inline traffic handling, NVA HA |
| Front Door | L7 HTTP, global (azurefd.net) |
Global HTTP(S) entry | Internal traffic, non-HTTP |
| NAT gateway | Outbound only | SNAT for a subnet | Any inbound connection |
Some typical design choices follow directly from the table:
- NVAs inspecting internal traffic: the least-effort design is an internal Standard Load Balancer with an HA ports rule (covered later in this chapter).
- Cheap internal L4 balancing for IPv6 VMs across many subnets: a Standard Load Balancer with an internal dual-stack frontend.
- Several apps on different ports (for example TCP 443, 25 and 22) behind one public IP: a public Standard Load Balancer. Application Gateway doesn’t suit SMTP or SFTP.