{"id":11721,"date":"2026-10-07T00:21:31","date_gmt":"2026-10-07T00:21:31","guid":{"rendered":"https:\/\/www.prepaway.com\/certification\/microsoft-az-104-azure-load-balancer-or-application-gateway\/"},"modified":"2026-10-07T18:04:35","modified_gmt":"2026-10-07T18:04:35","slug":"microsoft-az-104-azure-load-balancer-or-application-gateway","status":"publish","type":"post","link":"https:\/\/www.prepaway.com\/certification\/microsoft-az-104-azure-load-balancer-or-application-gateway\/","title":{"rendered":"Microsoft AZ-104: Azure Load Balancer or Application Gateway?"},"content":{"rendered":"

Azure Load Balancer and Azure Application Gateway both distribute traffic, but they operate at different layers and solve different problems. Azure Load Balancer is a regional Layer 4 service for TCP and UDP. Application Gateway is a regional Layer 7 service for web traffic and can make routing decisions based on HTTP properties, terminate TLS, host multiple sites, route by URL path, and provide Web Application Firewall functionality through the WAF_v2 SKU.<\/p>\n

Microsoft’s current networking guidance is explicit: choose Load Balancer when you need regional TCP\/UDP distribution without application awareness; choose Application Gateway when a regional HTTP\/HTTPS workload needs Layer 7 routing, TLS offload, session affinity, or WAF. Azure Front Door is the separate global Layer 7 option for edge routing and multi-region web delivery. Also note that Application Gateway v1 retired on April 28, 2026; current architecture should use v2 SKUs.<\/p>\n

The choice belongs inside Azure Architecture in Practice<\/a>.<\/p>\n

Start with the protocol layer<\/h3>\n

If the requirement is TCP or UDP distribution regardless of application content, Azure Load Balancer is the natural starting point.<\/p>\n

If the requirement is HTTP\/HTTPS routing based on path, host, cookies, headers, or TLS behavior, Application Gateway belongs at the application layer.<\/p>\n

Azure load balancing<\/a> is easiest to design when the layer is chosen before the product.<\/p>\n

Use Load Balancer for Layer 4 services<\/h3>\n

Load Balancer can distribute inbound TCP\/UDP flows across backend instances and supports health probes, HA ports, and zone-redundant configurations depending on design.<\/p>\n

It does not inspect HTTP URLs, cookies, or application headers.<\/p>\n

This makes it appropriate for databases, custom TCP services, non-HTTP protocols, and simple web traffic where no Layer 7 features are needed.<\/p>\n

Use Application Gateway for web routing<\/h3>\n

Application Gateway understands HTTP\/HTTPS and WebSocket traffic and supports host-based and path-based routing.<\/p>\n

It can route \/api<\/code> to one backend and \/images<\/code> to another or host several sites behind one gateway.<\/p>\n

That application awareness is the main reason to choose it over a Layer 4 balancer.<\/p>\n

Use WAF when application-layer protection matters<\/h3>\n

Application Gateway WAF_v2 integrates Web Application Firewall policy for common web attacks.<\/p>\n

WAF can inspect HTTP requests in ways Load Balancer cannot because Load Balancer never terminates or parses the application protocol.<\/p>\n

WAF should complement secure application design, identity, patching, and monitoring rather than become the only web-security control.<\/p>\n

Choose TLS termination intentionally<\/h3>\n

Application Gateway can terminate client TLS and can also use end-to-end TLS toward backends.<\/p>\n

This enables certificate centralization, HTTP routing, and WAF inspection while preserving encryption on the backend hop where required.<\/p>\n

Load Balancer passes TCP\/TLS through and leaves termination to the backend application or another proxy layer.<\/p>\n

Consider internal versus public entry points<\/h3>\n

Both services can be used for internal or public scenarios according to supported configuration.<\/p>\n

The real question is whether internal traffic still requires Layer 7 features such as path routing or WAF.<\/p>\n

An internal API platform can need Application Gateway even though no internet-facing address exists.<\/p>\n

Use health probes that reflect service readiness<\/h3>\n

Layer 4 health can confirm a port responds, while Layer 7 health can check an HTTP path and status.<\/p>\n

Application Gateway can therefore make routing decisions using application-aware health checks.<\/p>\n

Health probes should target an endpoint that accurately represents whether the instance can serve user traffic, not one that stays green while dependencies are broken.<\/p>\n

Plan zone resilience and scale<\/h3>\n

Current production architectures should use supported zone-redundant and autoscaling capabilities according to the service and SKU.<\/p>\n

Availability-zone design<\/a> should review the gateway\/load balancer plus every backend and dependency.<\/p>\n

A zone-redundant entry point does not make a single-zone backend resilient.<\/p>\n

Use multiple services when layers differ<\/h3>\n

Complex architectures can use more than one load-balancing service.<\/p>\n

For example, Front Door can provide global HTTP routing, Application Gateway can provide regional WAF and Layer 7 routing, and Load Balancer can distribute internal TCP services.<\/p>\n

For AZ-305<\/a>, the durable decision is protocol \u2192 scope \u2192 application awareness \u2192 security features \u2192 resilience, not \u201cwhich Azure load balancer is best?\u201d<\/p>\n

Cost and operational complexity should also be considered. Application Gateway provides richer web features but requires its own subnet, certificates, WAF policy where used, listener\/routing configuration, and application-layer troubleshooting. Load Balancer can be simpler when the requirement is only transport-level distribution.<\/p>\n

Client IP and proxy behavior differ because Application Gateway terminates the HTTP connection while Load Balancer preserves a more direct transport model. Applications that depend on source-address information should be designed to use the appropriate forwarded headers or network behavior.<\/p>\n

Application Gateway v2 is the current family to plan around. Legacy v1 architecture should be treated as migration work, not as a new-design option after its 2026 retirement.<\/p>\n

The best architecture chooses the smallest service that provides the required layer and security behavior, then validates the complete request path under backend failure, zone failure, certificate rotation, and scale.<\/p>

Backend protocol requirements can decide the architecture immediately. SQL, RDP, custom binary protocols, DNS, and many infrastructure services are not HTTP applications and should not be forced through a Layer 7 web gateway. Azure Load Balancer can distribute those TCP\/UDP flows without interpreting application data.<\/p>\n

Application Gateway is valuable when the routing decision needs application context. Multiple websites can share one frontend with host-based listeners, or URL paths can route API and static content to different backend pools. This can reduce the number of public endpoints while keeping application routing explicit.<\/p>\n

WAF deployment should be tied to application risk and tuning. WAF_v2 can block or detect common web attacks, but managed rules can create false positives for unusual applications. Use detection or staged enforcement where necessary, review exclusions carefully, and treat WAF logs as input to application-security improvement rather than a permanent list of bypasses.<\/p>\n

TLS architecture should include certificate ownership and rotation. Application Gateway can centralize public certificates and optionally re-encrypt to the backend. Teams should define who owns the certificate, how renewal is automated, how backend trust is validated, and what alerts occur before expiration. A Layer 7 gateway becomes an availability dependency when certificate lifecycle is unmanaged.<\/p>\n

Private applications can also use Application Gateway for internal Layer 7 routing. This is useful for intranet portals, internal APIs, or regional service platforms that need path routing or WAF without internet exposure. Internal deployment does not eliminate the need for identity, network segmentation, or backend authorization.<\/p>\n

Load Balancer health probes should test the readiness signal the backend can expose at Layer 4 or HTTP where supported. Application Gateway probes can check an application path and expected host. Avoid a health endpoint that returns success even when the database or critical downstream dependency is unavailable, because traffic will continue to be routed to an unhealthy instance.<\/p>\n

Source network address translation and outbound design should be reviewed separately from inbound load balancing. Azure Load Balancer can participate in outbound connectivity patterns, while NAT Gateway is often a clearer dedicated outbound design for many workloads. Do not select an inbound service merely because the workload also needs egress.<\/p>\n

Regional versus global scope matters. Application Gateway does not replace Front Door for global edge routing, and Load Balancer does not provide global traffic management. Multi-region applications may combine global and regional services, with each layer having its own health and failover logic.<\/p>\n

Observability should show frontend health, backend health, probe results, connection or request failures, WAF actions, TLS errors, and backend latency. When a user sees a 502, operators should be able to tell whether the gateway had no healthy backend, could not negotiate TLS, or received an application error.<\/p>\n

The decision can be summarized as \u201cwhat must the traffic layer understand?\u201d If only IP, port, and connection matter, use Layer 4. If HTTP semantics, WAF, TLS termination, or content-based routing matter, use Layer 7. Add global services only when geographic routing or edge delivery is another requirement.<\/p>\n

Session affinity is another Layer 7 consideration. Application Gateway can use cookie-based affinity where an application requires a client to remain on one backend instance. New architectures should avoid affinity where possible by externalizing session state, but when legacy applications need it, the gateway can provide that behavior more naturally than a Layer 4 service.<\/p>\n

Autoscaling behavior should be tested against sudden demand and backend scale-out. Application Gateway v2 can scale automatically, while backend pools may also scale. The entry layer and application layer need compatible scale timing so the gateway does not become the bottleneck while instances are being added.<\/p>\n

Private Link, NSGs, route tables, and backend firewalls can all affect gateway-to-backend connectivity. A healthy listener does not prove the gateway can reach every backend. Troubleshooting should separate frontend acceptance, listener\/rule selection, probe health, and backend network reachability.<\/p>\n

Use one architectural diagram that shows global routing if any, regional gateway\/load balancer, backend pools, health probes, TLS boundaries, and zone placement. The service choice becomes much easier to validate when each layer’s responsibility is visible.<\/p>\n

Keep the load-balancing choice under review as the application evolves. A simple TCP service can later gain HTTP routing or WAF requirements, while an internal web app can simplify enough that Layer 7 features are no longer justified.<\/p>","protected":false},"excerpt":{"rendered":"

Azure Load Balancer and Azure Application Gateway both distribute traffic, but they operate at different layers and solve different problems. Azure Load Balancer is a regional Layer 4 service for TCP and UDP. Application Gateway is a regional Layer 7 service for web traffic and can make routing decisions based on HTTP properties, terminate TLS, host multiple sites, route by URL path, and provide Web Application Firewall functionality through the WAF_v2 SKU. Microsoft’s current networking guidance is explicit: choose Load Balancer when you need regional TCP\/UDP distribution without application awareness;…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2175,2182],"tags":[],"class_list":["post-11721","post","type-post","status-publish","format-standard","hentry","category-cloud","category-microsoft"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t