AZ-305 Load Balancing Decision Guide: Front Door, Application Gateway, Traffic Manager, or Load Balancer?

If an AZ-305 scenario asks you to choose between Azure Front Door, Application Gateway, Traffic Manager, and Load Balancer, start with the traffic decision, not the product name. 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.

This matters for the current AZ-305 blueprint because Microsoft lists Design infrastructure solutions as 30-35% of the exam, and the current study guide includes Recommend a load-balancing and routing solution under design network solutions (Microsoft AZ-305 exam page, AZ-305 study guide).

The Decision Lens AZ-305 Expects

The official Azure Architecture Center frames load-balancer selection around two questions: whether the solution is global or regional, and whether the traffic is HTTP(S) or non-HTTP(S). It also calls out feature checks such as cost, availability, service limits, health monitoring, sticky sessions, HTTP/2, and offload capabilities (Azure load balancing options).

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

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

That last point is important. Real architectures often use more than one service, and Microsoft’s load-balancing guidance says each workload component should be assessed individually when several services require load balancing (Azure load balancing options).

Decision Cards

Use these as mobile-friendly service boundaries. They are intentionally short because the exam pressure is usually the scenario, not the service definition.

Azure Front Door

Reach for Front Door when the scenario describes a public, global, HTTP(S) app or API with users in multiple geographies.

Why it fits: Azure Front Door 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 (Azure load balancing options). The Front Door overview also emphasizes global edge delivery, high availability, lower latency, scalability, and security for static and dynamic web content (Azure Front Door overview).

Watch out for: Front Door is not the default answer for every load-balancing question. If the workload is single-region, private, or mostly Layer 4 TCP/UDP, another service may fit better.

Azure Application Gateway

Reach for 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.

Why it fits: Microsoft describes Application Gateway 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 features such as SSL/TLS termination, autoscaling, zone redundancy, and WAF integration (Application Gateway overview).

Watch out for: Application Gateway is regional. If the requirement is global user routing across regions, it often belongs behind or beside a global service rather than replacing one.

Azure Traffic Manager

Reach for Traffic Manager when the scenario needs DNS-based global routing to public endpoints and does not need Layer 7 request processing.

Why it fits: Microsoft describes Traffic Manager as a DNS-based traffic load balancer that distributes traffic across global Azure regions and provides routing methods plus endpoint monitoring (Traffic Manager overview). The Azure Architecture Center notes that Traffic Manager does not handle traffic directly; it uses DNS to direct clients to endpoints, and DNS caching or ignored TTL values can delay failover (Azure load balancing options).

Watch out for: Do not choose Traffic Manager when the scenario requires WAF, TLS offload, path-based routing, or per-request application-layer decisions.

Azure Load Balancer

Reach for Load Balancer when the scenario is Layer 4 TCP/UDP traffic, VM or VMSS backend pools, internal load balancing, or public inbound/outbound flows for virtual machines.

Why it fits: Azure Load Balancer operates at Layer 4 and distributes inbound flows to backend virtual machines or virtual machine scale sets based on configured load-balancing rules and health probes (Load Balancer overview).

Watch out for: Load Balancer is not a web application gateway. It does not inspect URLs, host headers, or HTTP payloads for routing decisions.

Worked Example: Multi-Region Retail App

Scenario:

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. Azure Front Door is the likely 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 scenario needs regional path routing and WAF/TLS handling near private backends. Application Gateway fits the regional Layer 7 tier, especially when the backends live inside a 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.

For the main web app, Front Door already addresses global HTTP(S) routing. Traffic Manager could appear in advanced resilience patterns, but it is not the first answer if the scenario requires per-request HTTP processing, WAF, or edge acceleration. Use Traffic Manager when DNS-level global routing is the actual requirement.

Step 5: Write the architecture answer.

Use Azure Front Door as the global public entry point. Use Application Gateway in each region for regional Layer 7 routing and WAF/TLS controls to private web backends. Use Azure Load Balancer for the internal TCP service. Do not replace Front Door with Traffic Manager unless the requirement is DNS-based endpoint selection rather than HTTP application delivery.

Diagnostic Walkthrough: What Your Wrong Answer Reveals

When you miss this kind of AZ-305 question, the wrong service usually points to a specific misunderstanding.

Wrong turn: you choose Traffic Manager for a WAF or path-routing scenario

What it means: You are treating global routing and Layer 7 routing as the same thing.

How to remediate: Practice asking, “Does this service inspect each HTTP request?” Traffic Manager uses DNS to direct clients; it is not a per-request web gateway.

Wrong turn: you choose Load Balancer for URL routing

What it means: You are confusing Layer 4 flow distribution with Layer 7 application routing.

How to remediate: Label every scenario as Layer 4 or Layer 7 before looking at answer choices. TCP/UDP points toward Load Balancer. URL path, host header, TLS offload, and WAF point toward Application Gateway or Front Door.

Wrong turn: you choose Application Gateway for a global edge app by itself

What it means: You are ignoring the global vs regional control-plane requirement.

How to remediate: Ask whether users are spread across regions and whether the service should route them to a healthy regional stamp. If yes, consider Front Door or DNS-based Traffic Manager before a regional-only answer.

Wrong turn: you choose Front Door for a private internal service

What it means: You are over-weighting “modern web edge” and under-weighting reachability.

How to remediate: Decide whether the service is public HTTP(S), private regional web traffic, or internal TCP/UDP. A private internal flow usually belongs closer to Application Gateway or Load Balancer, depending on the protocol and routing need.

Wrong turn: you pick one service for every tier

What it means: You are flattening a layered architecture into a single product.

How to remediate: Split the design into edge, regional ingress, and internal service tiers. AZ-305 scenarios often reward the answer that uses the simplest layered combination that satisfies all requirements.

How To Study This Topic Without Memorizing A Matrix

Do not build a giant feature table. It is hard to retain and easy to misuse. Instead, drill four prompts:

• “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?

That practice is closer to AZ-305 than memorizing service slogans.

Where CramHQ Fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this topic, CramHQ can help you turn a wrong routing or load-balancing answer into a targeted learning loop: identify whether the miss came from protocol, scope, Layer 7 features, DNS behavior, or architecture layering, then use focused remediation, practice, and readiness planning instead of rereading every networking page.

When you are ready, take the AZ-305 assessment. Use each miss to write one sentence: “I picked the wrong service because I missed ____.” Fix that decision boundary, then practice a small set of related scenarios before moving on.

Quick Recap

• Use Azure Front Door for global public HTTP(S) applications that need edge entry, acceleration, fast failover, WAF, caching, or Layer 7 routing.
• Use Application Gateway for regional web traffic that needs URL or host-header routing, TLS termination, WAF, or private backend access.
• Use Traffic Manager for DNS-based global endpoint routing when per-request Layer 7 processing is not required.
• Use Azure Load Balancer for Layer 4 TCP/UDP flows, VM or VMSS backend pools, and internal or public network load balancing.
• For AZ-305, explain the decision boundary. The right answer is usually the one that matches protocol, scope, and routing layer with the least unnecessary architecture.