Azure Load Balancer and Azure Application Gateway both distribute traffic, but they solve different networking problems. The fastest way to choose between them is to stop thinking in terms of \u201cwhich load balancer is better\u201d and ask which layer of the connection needs to make the decision. Azure Load Balancer works at Layer 4 with TCP and UDP flows. Application Gateway works at Layer 7 and understands HTTP and HTTPS application traffic. That architectural difference determines nearly every feature that follows.<\/p>\n
This distinction matters for AZ-104<\/a> because Azure administrators are expected to implement and manage virtual networking, but it also matters well beyond exam objectives. A wrong choice can force an application to terminate TLS in the wrong place, lose path-based routing, create unnecessary proxy overhead, or make a simple transport-level service far more complicated than it needs to be.<\/p>\n Azure Load Balancer makes forwarding decisions from transport-level information such as source and destination IP addresses, ports, and protocol. It does not need to understand the HTTP request path, host header, cookie, or application session. That makes it suitable for TCP and UDP services, internal application tiers, virtual appliances, and workloads where the transport connection itself is the unit being distributed.<\/p>\n Application Gateway is an HTTP-aware reverse proxy. Because it terminates or processes Layer 7 web traffic, it can route requests according to URL paths, host names, headers, and other application characteristics. It can also integrate with Web Application Firewall, perform TLS termination, redirect traffic, rewrite headers and URLs, and support web-specific behavior such as cookie-based session affinity.<\/p>\n A general explanation of cloud load balancing<\/a> helps frame the shared goal: both services spread traffic so a workload can scale and survive backend failures. The implementation layer is what separates them. When the requirement is \u201csend TCP 443 to a healthy VM,\u201d Load Balancer may be enough. When it is \u201csend \/api to one pool, \/images to another, enforce WAF rules, and terminate TLS,\u201d Application Gateway is designed for that job.<\/p>\n The difference also affects observability. A Layer 4 service can expose connection and health information but does not inherently know that one URL path is returning HTTP 500 while another is healthy. A Layer 7 gateway can reason about web requests and backend HTTP behavior. When operations teams define service-level monitoring, they should align the probe and telemetry layer with the failure they actually need to detect.<\/p>\n Standard Load Balancer exposes a frontend IP configuration, a backend pool, health probes, and load-balancing rules. Incoming flows that match a rule are distributed to healthy backend instances. The service is pass-through at Layer 4, which keeps latency low and preserves a model that is familiar to network engineers working with non-HTTP protocols.<\/p>\n Public Load Balancer is used when the frontend must be internet reachable. Internal Load Balancer uses a private frontend address inside a virtual network. Both can distribute traffic to virtual machines or virtual machine scale sets, and Standard Load Balancer supports availability-zone scenarios. Health probes decide which instances should receive new flows, so probe design is part of availability rather than a small configuration detail.<\/p>\n Microsoft retired Basic Load Balancer in September 2025, so current designs should use Standard Load Balancer. That is a useful reminder that architecture should be based on the service generation that exists now, not screenshots from an old tutorial. Administrators following Microsoft certification<\/a> material should also watch for retired SKUs and update older lab patterns accordingly.<\/p>\n High-availability ports are another Load Balancer capability for scenarios where a network virtual appliance must receive traffic across many ports. That pattern is very different from a web listener on Application Gateway. It reinforces the idea that Load Balancer is often infrastructure plumbing: it distributes flows without requiring the administrator to model application URLs, certificates, or HTTP routing rules.<\/p>\n Application Gateway v2 is the current generation of the service. The older v1 SKUs retired on April 28, 2026. A v2 gateway is deployed into a dedicated subnet and acts as an application-layer traffic manager for web workloads. It supports host-based and path-based routing, TLS termination, autoscaling, zone redundancy, HTTP\/2, WebSocket traffic, and integration with Azure Web Application Firewall.<\/p>\n Those features matter when the backend architecture has meaning above the port number. A single HTTPS listener might serve multiple sites by host name. Requests to The closest on-premises analogy is an application delivery controller. An article on the role of an F5 load balancer<\/a> illustrates why enterprise teams often separate application-aware traffic management from basic network flow distribution. Azure Application Gateway provides that application-aware function as a managed Azure service rather than as a self-managed appliance.<\/p>\n Because the gateway is a proxy rather than pure pass-through, capacity and connection behavior must be planned at the gateway itself. Autoscaling reduces manual instance management, but subnet size, backend timeouts, connection draining, listener limits, and health configuration still matter. A team moving from a hardware ADC should translate those operational assumptions into managed-service settings instead of assuming Azure removes every sizing or lifecycle concern.<\/p>\n Both services depend on health information, but the probe should reflect what \u201chealthy\u201d means for the layer being balanced. Load Balancer supports TCP, HTTP, and HTTPS probes depending on configuration. Its job is to decide whether a backend instance should receive new transport flows. If the probe fails, new connections stop being directed to the unhealthy instance.<\/p>\n Application Gateway health probes can evaluate the HTTP behavior of a backend application. That makes it possible to check a specific path and expected web response rather than simply confirming that a port accepts a connection. For an application where the process is listening but a dependency is broken, an application-level probe can detect a failure that a basic TCP check would miss.<\/p>\n The best probe endpoint is deliberately lightweight and meaningful. It should confirm the minimum dependencies necessary to serve traffic without creating heavy database work or calling every downstream service. A probe that is too shallow produces false health; a probe that is too deep can mark every frontend unhealthy because one optional dependency is slow. Probe design is part of application resilience.<\/p>\n Probe dependencies should also be isolated from the user path. If the health endpoint calls a third-party API, a brief external outage can remove every backend from rotation even though the application could still serve most requests. Design the probe to answer whether the instance is safe to receive traffic, not whether every optional dependency in the business process is perfect at that moment.<\/p>\n If the requirement includes Web Application Firewall, Application Gateway is the natural choice because WAF inspects HTTP(S) traffic and applies managed or custom rules at the application layer. The gateway can terminate TLS, inspect the request, make a routing decision, and then forward to the selected backend. That is fundamentally different from a Layer 4 service that forwards a transport flow.<\/p>\n TLS termination also changes certificate management. Certificates and listener configuration become gateway dependencies, and teams must decide whether traffic to the backend remains encrypted. End-to-end TLS can preserve encryption beyond the gateway, while offloading can simplify backend servers. The correct decision depends on compliance, threat model, and operational responsibility.<\/p>\n Application-aware filtering should still be part of a larger security model. WAF reduces web-layer risk but does not replace secure application code, identity controls, network segmentation, or patching. General application security practices<\/a> remain relevant behind the gateway. A routing component cannot compensate for an application that trusts unsafe input or exposes excessive privileges.<\/p>\n Standard Load Balancer integrates directly with backend pools of supported Azure compute resources and can be public or internal. Application Gateway is a dedicated resource inside a virtual network and requires its own subnet. That dedicated-subnet requirement should be planned early because subnet sizing, network security, routing, DNS, and future scale all depend on the network topology.<\/p>\n For a hub-and-spoke design, the choice of service placement should follow traffic flow. An internal Load Balancer can distribute east-west traffic to a private application tier. An Application Gateway can front HTTP workloads that require centralized Layer 7 policy. The two services can also appear in the same architecture because they are not mutually exclusive; one may handle application ingress while another balances a lower-level internal tier.<\/p>\nLayer 4 and Layer 7 describe different decision points<\/h3>\n
Azure Load Balancer is the simpler choice for TCP and UDP flows<\/h3>\n
Application Gateway is built for HTTP-aware routing<\/h3>\n
\/orders<\/code> could be routed to one backend pool while \/static<\/code> goes elsewhere. TLS can terminate at the gateway, or end-to-end TLS can be maintained to the backend when the security model requires it. These are decisions a Layer 4 balancer cannot make because it does not parse the HTTP request.<\/p>\nHealth probes mean different things at each layer<\/h3>\n
TLS, WAF, and request routing push the design toward Application Gateway<\/h3>\n
Network architecture and subnet requirements affect placement<\/h3>\n