Overview and What You Will Learn
In this lab, you will create both a Load Balancer and an Application Gateway pointed at the same backend VMs, and see directly why one can only route by IP and port while the other can route based on the actual URL path of an incoming request.
Why This Matters in Production
A team builds a Load Balancer expecting it to route /api requests to one set of backend servers and /images requests to another, and discovers it simply cannot do this - Load Balancer has no visibility into the request's actual content, only its destination IP and port. Application Gateway was the correct tool for this requirement from the start.
Core Principles
Load Balancer and Application Gateway operate at genuinely different layers of the network stack, and confusing them is one of the most common early networking mistakes.
+------------------------------------------+| Azure Load Balancer (Layer 4) || Routes by IP address and port only || No visibility into request content || Fast, simple |+------------------------------------------+| Application Gateway (Layer 7) || Can inspect URL path, headers, cookies || Routes based on actual request content || Includes optional Web Application Firewall |+------------------------------------------+If your traffic is plain TCP with no need for content-based routing, Load Balancer is the simpler, faster choice. If your traffic is HTTP and you need path-based routing or WAF protection, Application Gateway is the correct tool.
Detailed Step-by-Step Practical Lab
- Create a Resource Group and two backend VMs to route traffic to:
az group create --name rg-lb-lab-mumbai --location centralindia az vm create \ --resource-group rg-lb-lab-mumbai \ --name vm-backend-1 \ --image Ubuntu2204 \ --size Standard_B1s \ --admin-username azureadmin \ --generate-ssh-keys \ --no-wait az vm create \ --resource-group rg-lb-lab-mumbai \ --name vm-backend-2 \ --image Ubuntu2204 \ --size Standard_B1s \ --admin-username azureadmin \ --generate-ssh-keys \ --no-wait- Create a Load Balancer distributing traffic across both VMs purely by IP and port, with no content awareness:
az network lb create \ --resource-group rg-lb-lab-mumbai \ --name lb-lab \ --sku Standard \ --public-ip-address pip-lb-lab- Create an Application Gateway instead, capable of routing based on URL path:
az network application-gateway create \ --resource-group rg-lb-lab-mumbai \ --name appgw-lab \ --sku Standard_v2 \ --public-ip-address pip-appgw-lab \ --vnet-name vnet-lb-lab \ --subnet subnet-appgw- Configure a path-based routing rule on the Application Gateway - routing
/api/*to one backend pool and everything else to another:
az network application-gateway url-path-map create \ --resource-group rg-lb-lab-mumbai \ --gateway-name appgw-lab \ --name path-map-lab \ --paths "/api/*" \ --address-pool api-backend-pool \ --default-address-pool default-backend-poolNoteThis exact routing decision - sending traffic to a different backend based on the URL path - is something Load Balancer structurally cannot do, since it never inspects the request's content at all, only its destination IP and port.
Compare the two configurations directly - the Load Balancer distributes evenly with no content awareness, while the Application Gateway makes a routing decision based on the actual request path.
Clean up:
az group delete --name rg-lb-lab-mumbai --yes --no-waitProduction Best Practices & Common Pitfalls
Common MistakeChoosing Load Balancer for a web application that actually needs path-based routing or WAF protection, then discovering the requirement can't be met and needing to rebuild the entire traffic layer with Application Gateway instead.
TipThese two services are not mutually exclusive - a common production pattern uses Application Gateway in front for HTTP-level routing and WAF protection, with an internal Load Balancer behind it distributing traffic to backend VMs at Layer 4.
- Load Balancer is the right choice for non-HTTP traffic - a custom TCP or UDP-based service, a database listener, or any workload where content-based routing decisions are never needed.
- Application Gateway's WAF option is a meaningful additional layer of protection against common web attacks like SQL injection, worth enabling for any internet-facing web application even if path-based routing itself isn't a requirement.
Quick Reference & Troubleshooting Commands
| Command | Description |
|---|---|
az network lb create |
Create a Layer 4 Load Balancer |
az network application-gateway create |
Create a Layer 7 Application Gateway |
az network application-gateway url-path-map create |
Configure path-based routing rules |
az network lb list |
List existing Load Balancers in a Resource Group |