Azure Load Balancer and Azure Application Gateway can both distribute traffic across healthy backends, but that common outcome hides a fundamental difference. Load Balancer makes decisions at layer 4 using TCP or UDP flow information. Application Gateway operates at layer 7 for web protocols and can understand HTTP concepts such as host names, URL paths, TLS termination, cookies, and web application firewall policy. The correct choice depends on what the platform needs to know about the traffic before it can route it safely.
For AZ-104, it is tempting to reduce the comparison to “Load Balancer is layer 4; Application Gateway is layer 7.” That is accurate but incomplete. Production design also depends on protocol, security controls, backend architecture, health checks, TLS ownership, zone resilience, operational complexity, and whether traffic is regional or global.
Imagine a regional service with two requirements. A public HTTPS application needs host-based routing, path-based routing, and a WAF. A second backend exposes a custom TCP protocol on port 8443. The first workload clearly benefits from Application Gateway. The second cannot be made into an HTTP application just to fit that product; it needs a layer-4 service such as Azure Load Balancer.
The first decision is whether routing requires application awareness
Azure Load Balancer distributes TCP and UDP flows. It does not inspect URLs, HTTP headers, cookies, or host names. That is a strength when the workload is not HTTP-based or when the application does not need layer-7 routing logic. The service can balance network traffic with low protocol assumptions.
Application Gateway is designed for HTTP, HTTPS, WebSocket, and related web traffic. It can terminate TLS, route requests by host or path, maintain cookie-based session affinity, and integrate a web application firewall in the WAF_v2 SKU. These capabilities exist because the gateway understands the application protocol.
The best initial question is therefore simple: does the routing decision require knowledge above TCP/UDP? If the answer is no, layer 7 may add cost and complexity without adding value. If the answer is yes, a layer-4 load balancer cannot substitute for application-aware routing.
Protocol is a hard constraint, not a preference
Application Gateway cannot become a general TCP/UDP load balancer by configuration. If the workload uses a non-HTTP protocol, Azure Load Balancer is the natural regional primitive. Database listeners, custom TCP services, UDP workloads, and other transport-layer services need a product that supports those protocols directly.
Conversely, an HTTPS application that needs different backend pools for /api and /images would force awkward application logic if it used only a layer-4 load balancer. Application Gateway can make that decision before the request reaches the backend.
This is a useful example of why decision frameworks matter more than product popularity. Application Gateway has more web-aware features, but “more features” does not make it a superset of Load Balancer. They operate at different layers and therefore solve different classes of problems.
TLS ownership can shift responsibility between the gateway and the application
With Application Gateway, TLS can terminate at the gateway, allowing the service to inspect HTTP traffic and apply routing or WAF policy. End-to-end TLS can also protect traffic from the gateway to backends when the architecture requires encryption across that internal hop.
That moves certificate lifecycle into the gateway design. Certificates must be issued, stored, renewed, and deployed correctly. The operations team needs monitoring for expiration and configuration errors. A routing feature has therefore created a cryptographic dependency that does not exist in the same way for a pure layer-4 pass-through design.
Azure Load Balancer can pass encrypted TCP traffic to the backend without understanding the TLS session. That keeps TLS termination inside the application or another proxy. The correct location depends on whether centralized certificate handling and application-layer inspection are desirable.
WAF requirements can make Application Gateway the obvious regional choice for web traffic
A web application firewall can inspect HTTP requests for malicious patterns and enforce application-layer security policy. Application Gateway WAF_v2 integrates that control with regional layer-7 routing. If the security requirement explicitly calls for a WAF in front of the regional web application, Load Balancer alone cannot satisfy it because it does not parse HTTP requests.
WAF should not be confused with every other network-security control. It does not replace NSGs, Azure Firewall, identity, secure coding, or DDoS protection. It protects a different boundary: the web request reaching the application.
Security and routing decisions often overlap with AZ-700, while the application-security consequences can also intersect with SC-500. The useful insight is that load balancing is not only about spreading traffic; it can determine where security inspection happens.
Health probes should represent service health, not merely machine existence
Both services depend on health information to avoid sending traffic to unhealthy backends, but the meaning of “healthy” should match the workload. A TCP probe can confirm that a port accepts connections while the application behind it is returning errors. An HTTP health probe can test a specific path and response behavior, giving the gateway a richer view of application readiness.
The probe endpoint should be designed intentionally. If /health performs an expensive database query on every probe, the health system can create load. If it always returns success without checking critical dependencies, it can keep a broken instance in service. The probe needs to be cheap enough to run frequently and meaningful enough to reflect whether the backend can safely receive traffic.
Health behavior also matters during deployments. New instances should not enter rotation before they are ready, and draining or shutdown behavior should keep in-flight work from being cut off unnecessarily. Those mechanics sit inside the broader purpose of load balancing: distributing useful work across backends without sending new traffic toward instances that cannot serve it safely.
Regional load balancing is different from global traffic steering
Load Balancer and Application Gateway are regional services. If the requirement is to route users across regions, reduce global latency, or provide edge-layer failover, the design may need Azure Front Door, Traffic Manager, or another global service in addition to the regional load-balancing layer.
Azure Traffic Manager solves a different problem: DNS-based global traffic steering rather than distributing connections across backend instances inside one region.
A common architecture can therefore include more than one layer: a global service directs the user to a region, Application Gateway handles regional web routing and WAF, and internal Load Balancers distribute non-HTTP traffic. The products are complementary when the architecture has distinct traffic boundaries.
Zone design and backend capacity matter after the frontend is chosen
A highly available frontend cannot protect a backend deployed as a single instance in one failure domain. Load balancer and gateway resilience needs to be matched by redundant backend capacity, healthy probes, and enough surviving instances to carry traffic during a failure.
Zone-redundant deployment options can reduce the risk that the frontend itself becomes a zonal dependency, but teams still need to verify regional support and SKU behavior. The same failure-model thinking used for Azure availability zones applies here: every critical layer should survive the outage the business says it must survive.
Capacity planning should include failover load. If three backend instances operate at 70 percent utilization and one zone failure removes a third of capacity, the remaining instances may saturate exactly when resilience is needed most.
The wrong default usually reveals itself in operations
Using Application Gateway for a simple internal TCP service can create unnecessary configuration, cost, and operational ownership without solving a real requirement. Using only Load Balancer for a complex public web application can push path routing, TLS policy, and security filtering into application code or separate appliances.
The wrong choice can also show up in troubleshooting. An application team may look for URL-based routing behavior on a layer-4 service that never sees URLs. A network team may inspect TCP reachability while Application Gateway is rejecting a request because of hostname, certificate, WAF, or HTTP health behavior.
Operational clarity improves when each frontend has a documented job: transport distribution, regional application delivery, global routing, web security, or some intentional combination.
Reversibility depends on how much application behavior is embedded in the gateway
Moving from Load Balancer to Application Gateway is not merely replacing one IP address. URL maps, listeners, TLS certificates, probes, WAF policies, backend settings, and DNS may all become part of the migration. The more routing logic is embedded in the gateway, the more the application delivery architecture depends on it.
That dependency is not inherently bad. Centralized path routing and WAF policy can be exactly the goal. It simply means the configuration should be managed as production code, reviewed, monitored, and tested like any other critical routing layer.
Readers moving into solution design will see the same multi-layer traffic questions in AZ-305, where the regional choice has to fit availability, security, and global architecture requirements rather than stand alone.
Use Azure Load Balancer when the workload needs regional layer-4 distribution for TCP or UDP and does not require the platform to understand HTTP semantics. Use Application Gateway when a regional web application needs layer-7 routing, TLS termination, host or path decisions, session affinity, or integrated WAF behavior.
Then test the surrounding design: backend health, certificate ownership, zone resilience, scale, logging, firewall interactions, and global routing. If the requirement is actually global application delivery, consider whether another service belongs in front rather than forcing a regional product to solve a different problem.
Within the Azure Administrator Associate path, the durable distinction is that Load Balancer understands connections while Application Gateway understands web requests. Once that difference is tied to real requirements, the decision becomes much more precise than memorizing product tables.
The right choice is the one that has exactly enough awareness to enforce the routing and security policy the workload needs. Anything less pushes required behavior somewhere else; anything more creates an operational layer with no clear purpose.
