Home / Azure

AzureCheat sheetIntermediate

Advisory: Front Door, Application Gateway, Load Balancer, Traffic Manager or API Management - choosing the traffic entry point

Azure's load-balancing services overlap enough to confuse every design review. Decide by global vs regional scope and HTTP vs non-HTTP traffic, add API management needs separately, and use the common layered patterns - with notes on WAF placement, private origins and failover behaviour.

Deepak Bhardwaj4 min read

Applies toAzure Front Door (Standard/Premium), Application Gateway (v2, WAF), Azure Load Balancer, Traffic Manager, Azure API Management

Two axes

HTTP(S) Any TCP/UDP
Global (multi-region, edge) Front Door Traffic Manager (DNS-based), cross-region Load Balancer
Regional Application Gateway (or App Gateway for Containers for AKS) Azure Load Balancer

API Management is a different layer: it governs APIs (auth, quotas, versioning, transformation, developer portal) and usually sits behind or alongside one of the above.

Comparison

Front Door Application Gateway Load Balancer Traffic Manager API Management
Layer L7, global edge L7, regional L4, regional (or global tier) DNS API gateway
WAF Yes (Premium managed rules, bot protection) Yes (WAF v2) No No Policies, not a WAF
TLS offload Yes Yes (end-to-end supported) No (pass-through) No Yes
Caching / CDN Yes No No No Response caching policy
Private origins Private Link origins (Premium) Backends in VNet Backends in VNet Endpoints anywhere VNet integration/injection
Failover speed Fast (health probes at edge) Within region Within region DNS TTL-bound n/a

Decision path

Public HTTP app, users in many regions, or multi-region failover?   → Front Door
Public or internal HTTP app in one region, needs WAF / path routing? → Application Gateway
Non-HTTP (SQL, RDP gateway, custom TCP/UDP), or internal L4?         → Load Balancer
Non-HTTP and multi-region via DNS?                                   → Traffic Manager
Publishing APIs to partners/teams with keys, quotas, versions?       → API Management (plus one of the above)

Common layered patterns

Users ─► Front Door (WAF, global failover) ─► Private Link ─► App Service / internal LB per region
Users ─► Front Door ─► Application Gateway (regional WAF, path routing) ─► AKS / VMs
Partners ─► Front Door / App Gateway ─► API Management (internal mode) ─► backend APIs
Internal apps ─► internal Application Gateway / internal LB ─► backends (no public exposure)

Avoid stacking layers that do the same thing (e.g. two WAFs with conflicting rules) unless there's a clear reason, such as a global WAF at the edge plus regional segmentation rules owned by another team.

Design questions

  • Where does WAF inspection happen, and who owns its rules and exclusions?
  • How are origins protected from direct access (Private Link, access restrictions on Front Door ID header, NSGs)?
  • How does failover work, how long does it take, and has it been tested?
  • Where do TLS certificates live, and how do they renew (Key Vault, managed certs)?
  • What are the timeouts at each layer? A 30 s gateway timeout in front of a 120 s backend causes mystery 504s.

Traps

Trap Note
Traffic Manager for fast failover Bound by DNS TTL and client caching
Front Door with public origins left open Lock origins to Front Door traffic only
App Gateway subnet too small v2 autoscale needs room; plan a dedicated, adequately sized subnet
Health probes hitting a page that needs auth Use a dedicated health endpoint
Using APIM as the only security layer for public web apps It isn't a WAF

Tip

Draw the request path end to end with every hop's timeout, TLS termination and health probe on one page. Most entry-point incidents are hidden in that diagram.

Checklist

  • Global vs regional and HTTP vs non-HTTP decided
  • API management needs handled separately
  • WAF placement and ownership clear
  • Origins locked down to the entry point
  • Timeouts, certificates and probes documented
  • Failover tested

Related fixes