AZ-104 · Implement and manage virtual networking · Updated August 7, 2026
Azure Load Balancer vs Application Gateway vs Traffic Manager vs Front Door
Azure gives you four different services that all get described, loosely, as “load balancing,” and the AZ-104 exam depends on you knowing they solve different problems at different layers. Azure Load Balancer distributes raw TCP/UDP traffic within a region at Layer 4. Application Gateway makes routing decisions based on HTTP request content within a region at Layer 7, and can attach a Web Application Firewall (WAF). Traffic Manager doesn’t touch traffic at all: it’s a DNS-based service that tells clients which regional endpoint to connect to, using one of six routing methods. Front Door combines global HTTP(S) routing with an edge network, terminating connections close to the user before proxying to the best-performing backend. Picking the wrong answer on a scenario question almost always means mismatching a Layer 7 or global requirement with a Layer 4 or regional-only service.
Azure Load Balancer: Layer 4, regional, and Standard-only now
Load Balancer works below the application layer. It sees IP addresses, ports, and protocol (TCP or UDP), and distributes connections across a backend pool of virtual machines or scale set instances without inspecting anything about the payload, the URL, or the HTTP headers. That makes it fast and protocol-agnostic, but it also means it can’t make a routing decision based on a URL path or a hostname, and it can’t terminate TLS on your behalf, both of which are Application Gateway’s job.
As of today, there’s only one SKU worth learning: Standard. Basic Load Balancer was retired on September 30, 2025, and Microsoft’s guidance is that any workload still running on it needs to upgrade to Standard. If you see “Basic Load Balancer” as an answer choice on a current AZ-104 question, treat it as a distractor describing a retired option, not a valid design choice. The distinctions that used to separate Basic from Standard are still worth knowing because the exam tests Standard’s capabilities directly:
| Capability | Standard Load Balancer |
|---|---|
| Availability Zones | Zone-redundant or zonal frontend IPs, inbound and outbound |
| Backend pool membership | Any VM or VM Scale Set instance in a single virtual network (IP-based or NIC-based) |
| Health probes | TCP, HTTP, HTTPS |
| Security posture | Closed to inbound flows by default; an NSG must explicitly allow traffic |
| SLA | 99.99% |
| Outbound rules | Declarative outbound NAT configuration |
| HA Ports | Available on internal load balancers, for load-balancing all ports at once |
That “secure by default” line matters on the exam: a Standard Load Balancer needs an NSG explicitly allowing traffic before it passes anything inbound, unlike the old Basic SKU, which was open unless locked down. There’s also a Gateway SKU, a narrower option for chaining third-party network virtual appliances inline with traffic, worth recognizing by name if it shows up as a distractor.
Application Gateway: Layer 7, regional, with WAF built in
Application Gateway operates at Layer 7. Instead of routing on IP and port alone, it reads the HTTP request itself, which unlocks path-based routing (send /images/* to one backend pool and /api/* to another), host-based routing across multiple domains on one gateway, SSL/TLS termination so backend servers don’t have to manage certificates, and session affinity via cookies. It also autoscales and can be deployed zone-redundantly within a region.
The detail the exam leans on hardest is the Web Application Firewall (WAF) option. Attaching a WAF SKU to Application Gateway gives you centralized protection against common web exploits, OWASP-defined attack patterns like SQL injection and cross-site scripting, sitting in front of your web apps. If a scenario asks for a regional service that inspects HTTP traffic and blocks OWASP-style attacks, Application Gateway with WAF is the answer; Load Balancer has no visibility into HTTP content at all and can’t do this job no matter how it’s configured.
Traffic Manager: DNS-based, global, six routing methods
Traffic Manager doesn’t proxy or inspect traffic in any form. It’s a DNS-level service: when a client resolves your Traffic Manager domain name, the DNS response points the client directly at one of your actual endpoints, and from then on the client talks to that endpoint directly. Because it operates purely at the DNS layer, it’s protocol-agnostic and can span regions, clouds, or on-premises endpoints alike.
Traffic Manager supports six traffic-routing methods, and matching a scenario’s description to the right one is a recurring exam pattern:
| Method | What it does |
|---|---|
| Priority | Sends all traffic to a primary endpoint, failing over to backups in order if the primary is unavailable |
| Weighted | Distributes traffic across endpoints according to assigned weights, useful for staged rollouts |
| Performance | Routes each user to whichever endpoint has the lowest measured network latency for their location |
| Geographic | Routes users to a specific endpoint based on the geographic origin of their DNS query, for data-residency or localization requirements |
| Multivalue | Returns all healthy IPv4/IPv6 endpoints in a single DNS response, letting the client retry another endpoint if the first is unresponsive |
| Subnet | Maps specific source IP address ranges to specific endpoints |
A scenario emphasizing “lowest latency for global users” wants Performance. One emphasizing “data must not leave a specific country” wants Geographic. One emphasizing “gradually shift traffic to a new deployment” wants Weighted. And critically: because DNS responses get cached by resolvers, Traffic Manager’s failover isn’t instant. It depends on the DNS Time to Live (TTL) expiring, which is why it’s usually paired with Application Gateway or another regional service, not used as a substitute for one.
Front Door: global, edge-terminated, Layer 7
Front Door is the odd one out: it’s global like Traffic Manager, but it operates at Layer 7 like Application Gateway, because it’s built on an actual content-delivery edge network rather than plain DNS. A client’s TLS connection terminates at the nearest Microsoft edge location (well over a hundred exist worldwide), and Front Door proxies the request over Microsoft’s own backbone to whichever backend origin is healthiest and fastest, using anycast routing and split-TCP to cut latency. Because it proxies the connection instead of just resolving a DNS name, failover is immediate, with no dependency on DNS caching. Front Door also bundles WAF, caching, and SSL offload with autorotated certificates, which is why Microsoft frames it as the choice for workloads needing both fast global failover and application-layer processing, while Traffic Manager suits scenarios that don’t need TLS termination or per-request processing at all.
Putting the four together
| Service | Layer | Scope | Routes based on |
|---|---|---|---|
| Load Balancer | 4 (TCP/UDP) | Regional | IP address and port |
| Application Gateway | 7 (HTTP/HTTPS) | Regional | URL path, host header, with optional WAF |
| Traffic Manager | DNS | Global | Priority, Weighted, Performance, Geographic, Multivalue, or Subnet |
| Front Door | 7 (HTTP/HTTPS) | Global, edge-terminated | Same idea as Application Gateway, but across regions with instant failover |
These services also compose: it’s common to put Application Gateway behind Traffic Manager or Front Door in each region, so global routing picks the right region while regional Layer 7 routing handles the traffic once it arrives. Recognizing that layering is itself a tested pattern.
How the AZ-104 exam tests this
- Traffic split by URL path (
/imagesvs/video) within one region: Application Gateway, not Load Balancer, which can’t read HTTP request content. - Protection against SQL injection and cross-site scripting: Application Gateway (or Front Door) with WAF enabled, not an NSG or Load Balancer.
- Users routed to the closest region by latency, with non-HTTP protocols in play: Traffic Manager’s Performance method, not Front Door, which only handles HTTP(S).
- Instant failover with no dependency on DNS caching, for a global HTTP application: Front Door, since it proxies the connection instead of relying on a DNS TTL expiring.
- Any answer naming Basic Load Balancer as a current option describes a retired SKU (September 30, 2025) and should be treated as incorrect.
- A data-sovereignty requirement routing EU users only to EU endpoints: Traffic Manager’s Geographic method, not Weighted or Priority.
Once you can match “Layer 4 vs Layer 7,” “regional vs global,” and “DNS-based vs proxy-based” to each service, most exam questions here reduce to spotting which distinction the scenario is testing. For related networking controls, see NSG vs Azure Firewall vs Bastion and Azure VNet Peering Explained, or the AZ-104 study guide for how this domain fits the rest of the exam.