Azure has four load balancing services, and the most common architecture review comment I write is that someone picked the wrong one, or stacked three of them where one would do. The framework that cuts through it is two questions: does the service work at layer 4 or layer 7, and is its scope regional or global?

The Quadrant

Layer 4 regional is Azure Load Balancer: transparent flow distribution to VMs, scale sets, and AKS inside a region, covered in detail yesterday. Layer 7 regional is Application Gateway: TLS termination, path routing, WAF, session affinity for HTTP workloads in a region. Layer 4 global is Traffic Manager: it is DNS based, returning different endpoint addresses per query according to a routing method, so it never touches your traffic at all. Layer 7 global is Front Door: anycast edge network, TLS at the edge, caching, WAF, and origin failover measured in seconds. Almost every design question resolves to placing the workload in this quadrant.

Traffic Manager vs Front Door, the Real Fight

Both do global failover, so which one? Front Door wins for HTTP: faster failover because health probing and routing happen in the data path rather than waiting on DNS TTLs and client resolver caching, plus edge TLS, caching, and WAF while it is there. Traffic Manager wins exactly where Front Door cannot play: non HTTP protocols (a global MQTT ingestion tier, custom TCP services, database endpoints), or when the traffic must not flow through an intermediary for compliance or latency reasons, since DNS based routing leaves clients connecting directly to the regional endpoint. Traffic Manager’s routing methods also cover niche needs elegantly: weighted for gradual regional migration, geographic for data residency steering, priority for classic active passive. The honest caveat with any DNS solution: failover speed is hostage to TTLs and misbehaving resolvers that ignore them, so measure real world failover, not theoretical.

Sane Combinations

These services stack, and some stacks are canonical. Front Door to Application Gateway to AKS: edge WAF and global routing, regional path routing and a second inspection point if regulation demands in region WAF, then the cluster. Front Door directly to App Service or Container Apps via Private Link: the common case, and the gateway in the middle was unnecessary. Traffic Manager over regional Application Gateways: the pre Front Door pattern, still valid when you want DNS steering with direct regional connections. Load Balancer sits underneath almost everything as the regional L4 workhorse. The anti patterns: Front Door in front of Traffic Manager (two global routers fighting), Application Gateway in front of Front Door (backwards, the edge belongs outside), and any HTTP path with three or more hops each doing TLS termination without anyone able to say why. Every hop adds latency, cost, certificate management, and one more place a header gets mangled.

The Decision in Practice

Single region HTTP app: Application Gateway, done. Multi region HTTP app: Front Door, plus regional gateways only if you need in region L7 features beyond what Front Door provides. Global non HTTP: Traffic Manager over regional load balancers. Internal microservices: internal Load Balancer or the platform’s built in service routing. And for the frequent question of API estates: Front Door for edge and global concerns, APIM for API governance behind it, regional backends behind that, each layer doing the job only it can do. Write the reason for every hop into the design document, and if a hop has no reason, delete it.

Cheers
Osama