The AZ-700 exam asks you to decide which load-balancing service belongs at which layer. Azure Load Balancer works at L4, routing traffic based solely on IP and port. Application Gateway works at L7, reading HTTP headers, URL paths, and cookies before making routing decisions. The two services serve different purposes and are often deployed together.
Azure Load Balancer: The Postal Sorting Conveyor
Picture the sorting conveyor at a postal facility. A camera reads the zip code on each parcel and pushes it into the correct regional chute — no one opens the box to see what is inside. Azure Load Balancer works the same way. It hashes five values — source IP, source port, destination IP, destination port, and protocol (5-tuple hash) — and routes each connection to one of the VMs in the Backend Pool.
The four key components are , , , and . The Frontend IP is the entry point: a public IP for a Public Load Balancer, or a private VNet IP for an Internal Load Balancer. Load Balancing Rules map a frontend port to a backend port. Health Probes periodically check each VM and automatically remove unhealthy ones.
SKU choice is Basic or Standard. Basic does not support Availability Zones. Standard supports Zone-redundant deployment, HTTPS Health Probes, and HA Ports — the default for production. When a scenario mentions high availability or Availability Zones, Standard is the answer. HA Ports is exclusive to the Standard Internal Load Balancer: setting port to 0 makes a single rule cover all ports 0–65535, eliminating per-port rules for NVA deployments.
Application Gateway: The Department Store Concierge Desk
Imagine the information desk on the ground floor of a department store. A visitor says 'I am looking for electronics' and the concierge directs them to the fifth floor; someone else asks for the food hall and is sent to the basement. The concierge listens to what you say. Application Gateway operates the same way. It reads the HTTP Host header, URL path, query string, and cookies before deciding which Backend Pool receives the request.
The core flow is . A Basic Listener handles one domain; a Multi-site Listener distinguishes multiple domains on the same IP and routes each to a different Backend Pool. Routing Rules are either Basic (all requests to one pool) or Path-based ( to Pool A, to Pool B).
SKU options are Standard_v2 and WAF_v2. Standard_v2 supports Autoscale and Zone-redundancy. WAF_v2 adds Web Application Firewall capability, applying OWASP rule sets to block SQL injection and XSS. When the scenario requires defending against web attacks, WAF_v2 is the answer.
Health Probe: The Hotel Doorman
A hotel doorman stands at the entrance and periodically checks whether each room is ready to receive guests. If a room is unavailable, he redirects clients elsewhere. Application Gateway Health Probes send periodic HTTP or HTTPS requests to each backend server and watch for a response code in the expected range (2xx or 3xx). If a server stops responding, it is automatically removed from the pool until it recovers.
Azure Load Balancer Health Probes support TCP, HTTP, and HTTPS with a default interval of 15 seconds and an unhealthy threshold of 2 failures. Application Gateway Health Probes let you specify the exact request path and expected response codes. In both services, unhealthy instances are excluded from traffic and re-added automatically once they recover.
SSL Termination and End-to-End TLS
Think of a courier company that receives sealed packages, re-packs them for internal distribution, and delivers them in new packaging. Application Gateway SSL Termination works this way. HTTPS is encrypted between the client and the gateway; the gateway decrypts the traffic and forwards plain HTTP to the backend VMs, reducing their TLS processing load.
End-to-End TLS goes further. After decrypting the client-facing HTTPS, Application Gateway re-encrypts the traffic and forwards it to backend servers over HTTPS as well. This is required when regulations mandate full-path encryption. Whenever a scenario mentions 'encryption across the entire path,' End-to-End TLS is the answer. Azure Load Balancer cannot terminate TLS — it passes port 443 traffic straight through.
AGIC and AKS Integration
Think of an automated warehouse robot that reads an order slip and carries items to the correct shelf zone without manual instruction. AGIC (Application Gateway Ingress Controller) does the same for AKS (Azure Kubernetes Service). When you annotate a Kubernetes Ingress object with AGIC annotations, the controller automatically creates and updates Listeners, Routing Rules, and Backend Pools in Application Gateway.
Application Gateway's WAF and SSL Termination extend directly to AKS Ingress, removing the need for a separate NGINX Ingress Controller. Application Gateway Autoscale responds automatically to AKS traffic growth. If an AZ-700 question bundles AKS, WAF, and Ingress, the answer is AGIC with WAF_v2. Cookie-based affinity issues a session cookie so the same client always reaches the same backend server — useful for legacy apps with local session state.
L4 vs L7: Choosing the Right Service
Consider the difference between a highway toll booth and an airport immigration desk. The toll booth reads your license plate and waves you through in seconds. The immigration desk opens your passport, checks your purpose of visit, and directs you to a specific gate. Azure Load Balancer is the toll booth; Application Gateway is the immigration desk.
Choose L4 (Load Balancer): any TCP/UDP protocol, no HTTP content inspection, NVA front-end, internal VM distribution Choose L7 (Application Gateway): URL path-based routing, multi-site hosting, WAF, SSL Termination, AKS Ingress
Outbound Rules on a Standard Public Load Balancer control how VMs use SNAT for internet-bound traffic. If the default SNAT port allocation is exhausted, Outbound Rules let you increase the count — Standard SKU only. NAT Rules map a specific frontend port directly to a specific VM's port, useful for SSH access.
!L4 versus L7: Load Balancer versus App Gateway
Deployment Patterns and Common Pitfalls
Picture a regional distribution center (Application Gateway) receiving nationwide orders, sorting by category, and sending them to store stockrooms (Internal Load Balancer). Two layers of distribution together. In Azure, Application Gateway (with WAF) handles HTTP traffic from the internet while an Internal Load Balancer distributes traffic between VMs inside the VNet.
The most common exam mistake: choosing Azure Load Balancer for all external traffic scenarios. If the scenario requires URL path-based routing or a WAF, Application Gateway is the correct answer. Remember: HA Ports is exclusive to Standard Internal Load Balancer and does not exist on Public Load Balancer.
Exam Key Takeaways
'All TCP/UDP ports, NVA front-end' -- Azure Load Balancer Standard + HA Ports 'Route by URL path to different pools' -- Application Gateway Path-based Routing 'Multiple domains on a single IP' -- Application Gateway Multi-site Listener 'Block SQL injection and XSS' -- Application Gateway WAF_v2 'AKS + Ingress + WAF' -- AGIC + WAF_v2 'Encrypt traffic across the entire path' -- Application Gateway End-to-End TLS 'Reduce backend TLS processing load' -- Application Gateway SSL Termination 'Sticky sessions, same client to same server' -- Cookie-based affinity 'Zone-redundant Load Balancer' -- Standard SKU 'SNAT port exhaustion, outbound control' -- Standard Load Balancer Outbound Rules 'Direct port mapping to a single VM' -- Load Balancer NAT Rules 'Single rule for all ports, internal NVA' -- HA Ports (Standard Internal LB only)
Azure Load Balancer = L4 distribution by IP and port, Application Gateway = L7 policy routing by HTTP content + WAF