Azure offers several traffic-distribution services, and the term “load balancer” can hide important differences. Azure Load Balancer, Application Gateway, Azure Front Door, and Traffic Manager operate at different layers, scopes, and points in the client connection.

For AZ-700, the selection process should begin with five questions: What protocol is being delivered? Does the decision need Layer 4 or Layer 7 information? Is the scope regional or global? Must the service proxy traffic or only influence endpoint selection? Does the application need WAF, TLS, or edge acceleration?

The broader concept of cloud load balancing explains why traffic is distributed across healthy endpoints. Azure architecture adds another step: choosing the service that makes the decision at the correct network layer and geographic scope.

Azure Load Balancer is the Layer 4 workhorse

Azure Load Balancer distributes TCP and UDP connections to healthy backend instances. It does not inspect URL paths, HTTP headers, cookies, or other application-layer content.

That makes it a strong fit for:

• non-HTTP TCP or UDP services
• private internal applications
• public or internal VM pools
• high-performance Layer 4 distribution
• workloads that need simple connection-level balancing without an HTTP reverse proxy

Load Balancer uses health probes to determine whether a backend can receive traffic. The probe design matters because an instance can have a functioning network stack while the actual application is unhealthy. A probe should test a condition that represents service readiness closely enough to avoid sending users to a broken backend.

Layer 4 simplicity is often an advantage. If the application does not need HTTP-aware decisions, introducing a Layer 7 proxy can add certificate, routing, timeout, and troubleshooting complexity without providing value.

Azure also supports cross-region Load Balancer patterns for certain global Layer 4 scenarios. That option is distinct from Front Door and Traffic Manager because it keeps the traffic-distribution decision at Layer 4 rather than moving it into HTTP/S proxying or DNS. The requirement should still drive the choice: a global TCP service and a global web application are different problems even if both need multi-region resilience.

Application Gateway makes regional Layer 7 decisions

Application Gateway is designed primarily for regional application delivery where routing depends on web-layer information.

It can support capabilities such as:

• host-based routing
• URL path-based routing
• TLS termination
• session affinity
• application-aware health probes
• Web Application Firewall

This makes it appropriate when /api and /images need different backend pools, when multiple hostnames share one gateway, or when regional web applications require WAF protection.

Unlike a Layer 4 load balancer, Application Gateway acts as a reverse proxy. It terminates the client-side connection and establishes a separate connection to the backend. That behavior affects TLS design, client-IP forwarding, timeout configuration, and logging.

Current Azure guidance also reflects that Application Gateway has expanded beyond the simplest historical “HTTP only” description and can support TCP/TLS proxy scenarios in relevant configurations. Even so, its architectural strength remains application-aware regional delivery, especially when TLS policy, WAF, or listener-based routing is required. Do not select it merely to replace every Layer 4 balancer.

Application Gateway can be deployed for public or private ingress, so “regional web traffic” is more useful selection criteria than “internet traffic.”

Azure Front Door provides global HTTP/S delivery at the edge

Azure Front Door operates at Microsoft’s global edge and is designed for globally distributed HTTP and HTTPS applications.

It can provide:

• global routing to healthy origins
• edge TLS termination
• WAF integration
• caching and acceleration capabilities
• health-based origin selection
• faster entry into Microsoft’s global network for distributed users

Front Door is a strong fit when users are geographically dispersed or the application runs in several regions. The service can direct requests to an appropriate healthy origin while applying global edge policy.

Because Front Door is a proxy, user traffic actually passes through the Front Door service. That is a major architectural difference from Traffic Manager, which only influences DNS resolution.

The origin architecture still matters. A global edge service does not fix an application whose regional backend is underprovisioned, stateful in the wrong way, or unable to fail over safely.

Traffic Manager makes DNS-based global decisions

Traffic Manager distributes traffic by returning DNS responses that direct clients toward selected endpoints.

It does not sit in the application data path after name resolution. The client connects directly to the chosen endpoint.

This makes Traffic Manager useful when:

• the endpoints are in multiple regions or clouds
• the protocol is not limited to HTTP/S
• the organization wants DNS-based global failover
• endpoints should receive the connection directly
• a global reverse proxy is unnecessary or undesirable

The tradeoff is that failover is influenced by DNS TTL and client-side caching. A Traffic Manager endpoint can be declared unhealthy, but clients that already cached an earlier answer might continue using it until that cached record expires.

That behavior should be reflected in availability claims. DNS-based failover is not identical to proxy-based per-request origin selection.

Front Door and Traffic Manager are both global but solve different problems

The comparison can be simplified to proxy versus DNS steering.

Use Front Door when you need a global HTTP/S platform with WAF, edge routing, TLS handling, and acceleration features.

Use Traffic Manager when you need global endpoint selection through DNS and want the client to connect directly after resolution.

Traffic Manager can support endpoint types beyond a conventional Azure web application, including external endpoints. Front Door is more specialized around modern HTTP/S application delivery.

The services can also be layered in advanced resilience architectures, but adding both should have a clear reason. Microsoft documents mission-critical patterns in which Traffic Manager can provide an alternate path if Front Door itself is unavailable, but such designs add operational complexity and are not the default for ordinary applications.

Application Gateway and Front Door can form two delivery layers

A globally distributed web application may use Front Door at the edge and Application Gateway in each region.

Front Door can select a healthy region, provide global WAF and acceleration, and keep users on Microsoft’s edge network. Application Gateway can then apply regional host/path routing, regional WAF policy, or backend-specific controls.

This layered pattern is useful when the global and regional layers have genuinely different responsibilities.

It also creates more components to monitor:

• two health-probe systems
• two routing configurations
• more TLS certificates or trust relationships
• additional logging and diagnostics
• additional failure modes

If regional routing is simple, Front Door may be able to reach origins directly without Application Gateway. Architecture should favor the minimum number of layers that satisfies security, routing, and resilience requirements.

Internal versus public traffic does not decide the service by itself

Azure Load Balancer and Application Gateway can both support private internal scenarios.

An internal Load Balancer can distribute TCP/UDP connections among private backend instances. A private Application Gateway can provide HTTP/S reverse-proxy behavior inside a virtual network.

Therefore “public or private?” is only one selection question. A better sequence is:

1. What protocol is the application using?
2. Does routing depend on Layer 7 information?
3. Is the decision regional or global?
4. Is a reverse proxy acceptable or required?
5. Is WAF protection required?
6. Does the application need edge caching or acceleration?
7. Can DNS-based failover meet the recovery objective?

Those questions lead to a more defensible design than choosing from product names.

Health probes and failover semantics deserve design attention

Every traffic-distribution layer needs a reliable view of backend health.

A weak health probe can cause two opposite problems: sending users to an unhealthy backend or removing a healthy backend because the probe tests the wrong dependency.

For multi-tier applications, decide whether the front-end health endpoint should fail when a downstream database is unavailable. In some systems that is correct because the instance cannot serve requests. In others, taking every front end out of rotation at once can make recovery harder.

Global services add another layer. Front Door and Traffic Manager may consider regional endpoints healthy or unhealthy based on their own probes, while Application Gateway or Load Balancer independently evaluates instances inside the region.

The architecture should document what each probe means and how failures propagate through those layers.

Client source-address behavior matters too. Proxy-based services create a new backend connection, so applications commonly rely on forwarded headers to recover client context. Layer 4 services preserve different connection semantics. If security rules, rate limits, or application logging depend on the original client address, validate that behavior before choosing the delivery layer and before placing another proxy in front of an existing one.

Choose the service from layer and scope

A compact mapping is useful:

• Azure Load Balancer: regional or cross-region Layer 4 TCP/UDP distribution when application-aware routing is unnecessary.
• Application Gateway: regional Layer 7 application delivery when host/path routing, TLS termination, or WAF is required.
• Azure Front Door: global HTTP/S application delivery when edge routing, acceleration, WAF, or multi-region origin selection is required.
• Traffic Manager: global DNS-based endpoint selection when clients should connect directly after resolution or the protocol is not tied to an HTTP reverse proxy.

Then validate the choice against health-probe behavior, recovery objectives, certificate ownership, client-IP requirements, backend protocol, and cost. A simple Layer 4 requirement should stay simple, while a global web application should use a service that understands global web delivery rather than forcing DNS or regional tools to imitate it.