Azure Front Door vs Application Gateway vs Traffic Manager

An AZ-305 scenario puts Azure Front Door, Application Gateway, Traffic Manager, and Load Balancer in the same answer set, and at least two of them look right. Decide from the traffic the scenario states: its scope (global across regions, regional inside one Azure region, or internal inside a virtual network), its protocol (HTTP(S) or raw TCP/UDP), and its routing layer (Layer 7, where the decision reads request attributes like URL paths, or Layer 4, where the service distributes flows).

Use Azure Front Door for global HTTP(S) applications that need edge entry, acceleration, fast failover, WAF, or path-based routing. Use Application Gateway for regional web traffic that needs Layer 7 routing, TLS termination, WAF, or private backend access inside a virtual network. Use Traffic Manager when DNS-based global routing is enough and the service does not need per-request Layer 7 processing. Use Azure Load Balancer for Layer 4 TCP/UDP flows, VM or VMSS backend pools, and internal or public network load balancing.

The Microsoft AZ-305 exam page lists Design infrastructure solutions at 30-35% of the exam, and the AZ-305 study guide puts "Recommend a load-balancing and routing solution" under the Design network solutions skill (skills measured as of April 17, 2026).

Five checks before you pick a service

Microsoft's Architecture Center frames the choice along two dimensions, global versus regional and HTTP(S) versus non-HTTP(S) (Load balancing options, last updated 2025-11-12). Its flowchart walks a web application through the same sequence. Internet-facing first (the branch that answers no lands on Load Balancer), then global or single-region (single region lands on Application Gateway), then whether the design needs performance acceleration or per-request processing. The global branch that needs per-request processing without acceleration lands on Azure Front Door and Application Gateway together. The page lists the factors to weigh when you select a solution: the traffic type, the global versus regional scope, availability, cost, and features and limits. It puts the per-service implementation details it calls other considerations, such as WebSockets support, server-sent events, HTTP/2, sticky sessions, back-end health monitoring, and client experience, in one section, and the offloading of capabilities from back-end nodes to the load balancer in another.

For AZ-305, turn that into five quick checks:

• Is the application HTTP(S), TCP, UDP, or mixed?
• Is the routing decision global across regions, regional inside one Azure region, or internal inside a virtual network?
• Does the design need Layer 7 features such as path routing, host-header routing, TLS termination, WAF, or session affinity?
• Is DNS-based redirection acceptable, including DNS caching and TTL behavior?
• Does the workload need one service or a layered design with edge, regional, and internal routing?

Real architectures stack services. Microsoft's guidance says to assess each service individually when a workload needs several kinds of load balancing, because an effective setup often uses more than one type of load balancing solution (Load balancing options). Run the five checks per component, and the answer is usually one service or a small stack.

Each service fits a specific kind of scenario, and each stops fitting in a specific case

Work the scenario's requirements in the order they are stated, and see which service each one selects. If different requirements select different services, the answer is a stack.

Azure Front Door

Front Door is the pick when the scenario describes a public, global, HTTP(S) app or API with users in multiple geographies. The service is an application delivery network for global web applications. Microsoft describes it as providing global load balancing, site acceleration, Layer 7 capabilities, SSL offload, path-based routing, fast failover, and caching (Load balancing options). The Front Door overview adds that the service uses Microsoft's global edge network to serve static and dynamic web content with higher availability, lower latency, more scalability, and improved security, no matter where your users are (Azure Front Door overview, last updated 2026-08-28). If the workload is single-region, private, or mostly Layer 4 TCP/UDP, another service fits better.

Application Gateway

Use Application Gateway when the scenario is regional web traffic and the answer needs URL-path routing, host-header routing, TLS termination, WAF, or private backend access. Microsoft describes it as a web traffic load balancer that makes routing decisions from HTTP request attributes such as URL paths and host headers. It operates at OSI Layer 7 and provides SSL/TLS termination, autoscaling, zone redundancy, and Web Application Firewall integration (Application Gateway overview, last updated 2026-09-10). Application Gateway is regional, so if the requirement is global user routing across regions, a global service does the routing between regions, and Application Gateway serves its own region. If you want DNS-based global routing without TLS termination or per-request processing, the same overview points you to Traffic Manager.

Azure Traffic Manager

Traffic Manager is the answer when the scenario needs DNS-based global routing to public endpoints and does not need Layer 7 request processing. Microsoft describes it as a DNS-based traffic load balancer that distributes traffic to public-facing applications across global Azure regions, with a range of traffic-routing methods and endpoint monitoring options (Traffic Manager overview, last updated 2026-06-01). Traffic Manager does not handle traffic directly. It uses DNS to direct clients to the appropriate endpoints, and DNS caching or systems that ignore TTL values delay failover (Load balancing options). Do not choose it when the scenario requires WAF, TLS offload, path-based routing, or per-request application-layer decisions.

Azure Load Balancer

Layer 4 TCP/UDP traffic, VM or VMSS backend pools, internal load balancing, or public inbound and outbound flows for virtual machines point to Load Balancer. The service operates at Layer 4 of the OSI model and distributes inbound flows to backend virtual machines or virtual machine scale sets according to configured load-balancing rules and health probes. A public load balancer handles internet-facing traffic, and an internal load balancer handles private traffic inside a virtual network (Azure Load Balancer overview, last updated 2026-07-07). Load Balancer is not a web application gateway. It does not inspect URLs, host headers, or HTTP payloads for routing decisions.

The comparison settles which service the scenario points to

Traffic Manager and Load Balancer can distribute any traffic type, including HTTP(S), but they do not provide Layer-7 capabilities (Load balancing options).

When the scenario wants a stack

Three combinations are documented in Microsoft's own guidance, and each maps to a distinct requirement cluster.

Front Door in front of Application Gateway. The official Front Door FAQ lists four situations where Application Gateway belongs behind Front Door. Front Door does path-based load balancing only at the global level, so Application Gateway takes path routing inside the virtual network. Application Gateway supports connection draining, which Front Door does not. With Front Door in front, the virtual network can run plain HTTP after Application Gateway offloads all TLS. And the pair covers session affinity at both the regional and the server level (Azure Front Door FAQ, last updated 2026-08-21). If a scenario asks for global delivery plus in-virtual-network routing or draining, the answer is the stack, and a single-service answer loses the point.

Front Door in front of Load Balancer. The same FAQ calls deploying an Azure Load Balancer behind Front Door a common scenario, and Front Door Premium adds Private Link to an internal load balancer. In the Architecture Center's classification, Front Door is a Layer-7 load balancer that accepts only HTTP(S) traffic, so the Load Balancer behind it distributes web traffic to VM or VMSS backends at Layer 4.

Traffic Manager as the global layer. Traffic Manager fits the global layer when the routing decision is DNS-based. The Architecture Center's high-availability and disaster recovery pattern uses it to fail over to a secondary region when the primary is unavailable, and the Application Gateway overview points to it for DNS-based global routing without TLS termination or per-request processing. If the scenario needs per-request Layer 7 handling at the edge, the global routing layer belongs to Front Door.

Worked example: a multi-region retail app

A retailer is moving a customer web app to Azure. The architecture has these requirements:

• Customers in North America and Europe should hit the closest healthy region.
• The public web app needs WAF protection and TLS termination.
• /images/* and /checkout/* should route differently.
• Each region has private VM scale set backends.
• A legacy TCP service must be balanced inside the virtual network.
• If the primary region fails, users should be routed to another healthy region with minimal manual intervention.

Step 1: Identify the public edge. The app is public, HTTP(S), and global, and it needs WAF and TLS termination. Azure Front Door is the edge service because it is designed for global HTTP(S) delivery, acceleration, fast failover, and Layer 7 routing.

Step 2: Identify the regional web tier. The backends are private VM scale sets inside each region's virtual network, and the paths must route differently. Application Gateway handles that regional Layer 7 tier, behind Front Door, taking path routing inside the virtual network.

Step 3: Identify the internal Layer 4 tier. The legacy TCP service is not asking for URL or header routing. Use Azure Load Balancer for Layer 4 distribution to the internal backend pool.

Step 4: Decide whether Traffic Manager is needed. Requirement 6, routing users to another healthy region with minimal manual intervention when the primary region fails, is region-level failover, and Front Door already covers it. The Front Door FAQ describes the service as offering near real-time failover to ensure high availability. For a multi-region active/passive deployment it says to make one origin group with an origin for each region's application, and to set the main application's priority higher than the backup's (Azure Front Door FAQ). Traffic Manager takes region failover only when the global layer is DNS-based and the design skips per-request Layer 7 processing. This edge needs WAF protection and TLS termination, so the global routing layer stays with Front Door, and the answer has no Traffic Manager.

Step 5: Write the architecture answer. Use Azure Front Door as the global public entry point with the WAF, TLS termination, and the region failover, Application Gateway in each region for regional Layer 7 routing to the private web backends, and Azure Load Balancer for the internal TCP service. For AZ-305, explain how you picked each service, and defend the smallest architecture that still meets every stated requirement.

Read a wrong answer as a diagnostic

Choosing Traffic Manager for a WAF or path-routing scenario treats global routing and Layer 7 routing as the same thing. Ask whether the service inspects each HTTP request. Traffic Manager uses DNS to direct clients, so it does not process requests at all.

Load Balancer is the wrong answer when the scenario asks for URL routing. The error confuses Layer 4 flow distribution with Layer 7 application routing. Label every scenario as Layer 4 or Layer 7 before looking at answer choices. Raw TCP/UDP distribution points to Load Balancer. Application Gateway handles TCP and TLS only as a terminating load balancer, and its routing decisions come from HTTP request attributes. URL path, host header, TLS offload, and WAF point to Application Gateway or Front Door.

Picking Application Gateway by itself for a global edge app skips the global versus regional scope check. Ask whether users are spread across regions and whether the service should route them to a healthy regional stamp. If the answer is yes, Front Door or DNS-based Traffic Manager takes the global layer, with the regional gateway behind it.

Choosing Front Door for a private internal service ignores the reachability and protocol that decide it. Ask first whether the service is public HTTP(S), private regional web traffic, or internal TCP/UDP. A private internal flow belongs closer to Application Gateway or Load Balancer, depending on the protocol and the routing need.

One service for every tier flattens a layered architecture into a single product. Split the design into edge, regional ingress, and internal service tiers, and let each tier's protocol and scope pick its service.

Ask the four questions, then rework scenarios one requirement at a time

Work the four questions on every scenario you study, with the comparison table at hand:

• "Is this HTTP(S), TCP, UDP, or mixed?"
• "Is the routing decision global, regional, or internal?"
• "Does this requirement mention WAF, TLS offload, path routing, host headers, or session affinity?"
• "Would DNS-based failover be acceptable, or does the design need an active application proxy?"

Then test yourself by rewriting scenarios. Change one requirement at a time:

• Make the app single-region. Does Front Door still matter?
• Add /api/* path routing. Does Load Balancer still fit?
• Replace HTTP with raw TCP. Does Application Gateway still make sense?
• Add global public endpoints but no WAF or HTTP routing. Could Traffic Manager be enough?

Check your service choice with the free assessment

Take the free AZ-305 assessment. It returns a Readiness Report and your top gaps. For each load-balancing question you get wrong, write one sentence that names the distinction you missed. "I picked the wrong service because the scenario was ____." Fix that one, then redo a small set of related scenarios before moving on. The full AZ-305 path is $34.99 for 12 months of access (AZ-305 course page). The heart of the path is the Pass Plan, a list of targeted repair tasks aimed at the service-choice distinctions you miss. CramHQ tracks the gaps your work on CramHQ turns up over time, ranks the tasks by the exam points each gap costs, and keeps the costliest gap at the top of the plan. The free assessment is only the starting point for that list. The practice tests and the timed final simulation check your readiness as you work the repair tasks.