Azure Load Balancer vs Application Gateway vs Front Door — Which One?
Your application needs to handle traffic from users around the world, distribute requests across multiple backends, and survive server failures without dropping a single connection. Azure gives you four load balancing services, and picking the wrong one means either paying for features you do not need or missing capabilities you cannot live without. This guide breaks down each option so you can make the right call.
Azure Load Balancing Options at a Glance
| Service | OSI Layer | Scope | Protocol | Best For |
|---|---|---|---|---|
| Azure Load Balancer | Layer 4 (Transport) | Regional | TCP / UDP | VM traffic, non-HTTP workloads |
| Application Gateway | Layer 7 (Application) | Regional | HTTP / HTTPS / WebSocket | Web apps, WAF, URL routing |
| Azure Front Door | Layer 7 (Application) | Global | HTTP / HTTPS | Multi-region apps, global caching |
| Traffic Manager | DNS-based | Global | Any (DNS only) | DNS failover, geographic routing |
The key question is: do you need Layer 4 or Layer 7, and is your traffic regional or global?
Azure Load Balancer — Layer 4
Azure Load Balancer operates at the transport layer. It sees IP addresses and ports but knows nothing about HTTP headers, URLs, or cookies. It is fast, cheap, and simple.
# Create a public Standard Load Balancer
az network lb create \
--resource-group rg-networking \
--name lb-web-prod \
--sku Standard \
--frontend-ip-name frontend-ip \
--backend-pool-name backend-pool \
--public-ip-address pip-lb-prod
# Create a health probe
az network lb probe create \
--resource-group rg-networking \
--lb-name lb-web-prod \
--name health-probe-http \
--protocol Http \
--port 80 \
--path /health \
--interval 15 \
--threshold 2
# Create a load balancing rule
az network lb rule create \
--resource-group rg-networking \
--lb-name lb-web-prod \
--name rule-http \
--protocol Tcp \
--frontend-port 80 \
--backend-port 80 \
--frontend-ip-name frontend-ip \
--backend-pool-name backend-pool \
--probe-name health-probe-http \
--idle-timeout 15 \
--enable-tcp-reset true
Standard vs Basic SKU
| Feature | Basic (Legacy) | Standard |
|---|---|---|
| Backend pool size | Up to 300 VMs | Up to 1000 VMs |
| Health probes | TCP, HTTP | TCP, HTTP, HTTPS |
| Availability Zones | Not supported | Zone-redundant |
| SLA | No SLA | 99.99% |
| Security | Open by default | Closed by default (requires NSG) |
| HA Ports | Not supported | Supported |
Always use Standard SKU. Basic is being retired and offers no SLA.
NAT Rules and HA Ports
Inbound NAT rules let you forward traffic on specific ports to individual VMs — useful for SSH or RDP access to backend VMs through the load balancer.
# Create an inbound NAT rule for SSH to a specific VM
az network lb inbound-nat-rule create \
--resource-group rg-networking \
--lb-name lb-web-prod \
--name nat-ssh-vm01 \
--protocol Tcp \
--frontend-port 50001 \
--backend-port 22 \
--frontend-ip-name frontend-ip
# Enable HA Ports (load balance ALL ports, ALL protocols)
az network lb rule create \
--resource-group rg-networking \
--lb-name lb-internal-prod \
--name rule-ha-ports \
--protocol All \
--frontend-port 0 \
--backend-port 0 \
--frontend-ip-name frontend-internal \
--backend-pool-name backend-pool \
--probe-name health-probe-http
HA Ports rules (port 0, protocol All) load balance every port and protocol simultaneously. This is essential for network virtual appliances (NVAs) like firewalls that need to inspect all traffic.
Application Gateway — Layer 7
Application Gateway understands HTTP. It can route requests based on URL paths, host headers, and query strings. It terminates SSL, rewrites headers, and includes a Web Application Firewall.
# Create a public IP for Application Gateway
az network public-ip create \
--resource-group rg-networking \
--name pip-appgw-prod \
--sku Standard \
--allocation-method Static
# Create an Application Gateway with WAF v2
az network application-gateway create \
--resource-group rg-networking \
--name appgw-prod \
--sku WAF_v2 \
--capacity 2 \
--vnet-name vnet-prod \
--subnet snet-appgw \
--public-ip-address pip-appgw-prod \
--http-settings-port 80 \
--http-settings-protocol Http \
--frontend-port 443 \
--routing-rule-type Basic \
--servers 10.0.1.4 10.0.1.5 10.0.1.6 \
--priority 100
URL Path-Based Routing
Route different URL paths to different backend pools — your API servers handle /api/* while your static servers handle everything else.
# Create backend pools for different services
az network application-gateway address-pool create \
--resource-group rg-networking \
--gateway-name appgw-prod \
--name pool-api \
--servers 10.0.2.4 10.0.2.5
az network application-gateway address-pool create \
--resource-group rg-networking \
--gateway-name appgw-prod \
--name pool-static \
--servers 10.0.3.4 10.0.3.5
# Create a URL path map
az network application-gateway url-path-map create \
--resource-group rg-networking \
--gateway-name appgw-prod \
--name url-path-map \
--paths /api/* \
--address-pool pool-api \
--http-settings appGatewayBackendHttpSettings \
--default-address-pool pool-static \
--default-http-settings appGatewayBackendHttpSettings
# Create a path-based routing rule
az network application-gateway rule create \
--resource-group rg-networking \
--gateway-name appgw-prod \
--name rule-path-based \
--rule-type PathBasedRouting \
--http-listener appGatewayHttpListener \
--url-path-map url-path-map \
--priority 200
WAF v2 Configuration
The Web Application Firewall protects against OWASP Top 10 vulnerabilities — SQL injection, XSS, and other common web attacks.
# Enable WAF in Prevention mode
az network application-gateway waf-config set \
--resource-group rg-networking \
--gateway-name appgw-prod \
--enabled true \
--firewall-mode Prevention \
--rule-set-type OWASP \
--rule-set-version 3.2
# Create a custom WAF rule to block specific IPs
az network application-gateway waf-policy custom-rule create \
--resource-group rg-networking \
--policy-name waf-policy-prod \
--name BlockBadIPs \
--priority 10 \
--rule-type MatchRule \
--action Block \
--match-conditions '[{"matchVariables": [{"variableName": "RemoteAddr"}], "operator": "IPMatch", "matchValues": ["203.0.113.0/24", "198.51.100.50"]}]'
Start with Detection mode to see what would be blocked, then switch to Prevention mode once you have tuned out false positives.
SSL Termination and Autoscaling
Application Gateway handles TLS termination so your backend servers do not need to manage certificates.
# Upload a PFX certificate
az network application-gateway ssl-cert create \
--resource-group rg-networking \
--gateway-name appgw-prod \
--name api-cert \
--cert-file ./certs/api.pfx \
--cert-password "CertP@ss123"
# Enable autoscaling (0-10 instances)
az network application-gateway update \
--resource-group rg-networking \
--name appgw-prod \
--min-capacity 0 \
--max-capacity 10
Setting min-capacity to 0 means the gateway scales to zero during periods of no traffic — ideal for dev/test environments to save costs.
Azure Front Door — Global Layer 7
Front Door is Azure's global load balancer. It operates from Microsoft's edge network (200+ points of presence worldwide) and routes users to the closest healthy backend.
# Create a Front Door profile
az afd profile create \
--resource-group rg-networking \
--profile-name fd-global-prod \
--sku Premium_AzureFrontDoor
# Add an endpoint
az afd endpoint create \
--resource-group rg-networking \
--profile-name fd-global-prod \
--endpoint-name myapp-global \
--enabled-state Enabled
# Add origin groups (backend pools)
az afd origin-group create \
--resource-group rg-networking \
--profile-name fd-global-prod \
--origin-group-name og-webapp \
--probe-request-type GET \
--probe-protocol Https \
--probe-path /health \
--probe-interval-in-seconds 30 \
--sample-size 4 \
--successful-samples-required 3
# Add origins (backends in different regions)
az afd origin create \
--resource-group rg-networking \
--profile-name fd-global-prod \
--origin-group-name og-webapp \
--origin-name origin-eastus \
--host-name myapp-eastus.azurewebsites.net \
--origin-host-header myapp-eastus.azurewebsites.net \
--http-port 80 \
--https-port 443 \
--priority 1 \
--weight 1000
az afd origin create \
--resource-group rg-networking \
--profile-name fd-global-prod \
--origin-group-name og-webapp \
--origin-name origin-westeurope \
--host-name myapp-westeurope.azurewebsites.net \
--origin-host-header myapp-westeurope.azurewebsites.net \
--http-port 80 \
--https-port 443 \
--priority 1 \
--weight 1000
Front Door provides built-in caching, SSL offloading, WAF, and DDoS protection at the edge. For multi-region applications, it is the go-to choice.
Traffic Manager — DNS-Based Routing
Traffic Manager works at the DNS layer. It returns the IP address of the best endpoint based on routing method — it does not proxy traffic.
| Routing Method | How It Works | Use Case |
|---|---|---|
| Priority | Route to primary, failover to secondary | Active-passive disaster recovery |
| Weighted | Distribute by weight percentage | Canary deployments, A/B testing |
| Performance | Route to lowest latency endpoint | Multi-region with latency optimization |
| Geographic | Route by user location | Data sovereignty, regional compliance |
# Create a Traffic Manager profile with performance routing
az network traffic-manager profile create \
--resource-group rg-networking \
--name tm-myapp-global \
--routing-method Performance \
--unique-dns-name myapp-global \
--ttl 60 \
--protocol HTTPS \
--port 443 \
--path /health
# Add endpoints in different regions
az network traffic-manager endpoint create \
--resource-group rg-networking \
--profile-name tm-myapp-global \
--name ep-eastus \
--type azureEndpoints \
--target-resource-id /subscriptions/<sub-id>/resourceGroups/rg-prod/providers/Microsoft.Web/sites/myapp-eastus \
--endpoint-status Enabled
az network traffic-manager endpoint create \
--resource-group rg-networking \
--profile-name tm-myapp-global \
--name ep-westeurope \
--type azureEndpoints \
--target-resource-id /subscriptions/<sub-id>/resourceGroups/rg-prod/providers/Microsoft.Web/sites/myapp-westeurope \
--endpoint-status Enabled
Traffic Manager is often combined with other load balancers. Use Traffic Manager for DNS-level routing across regions, then Application Gateway or Load Balancer within each region.
Decision Tree — Which One Should You Use?
| Scenario | Use This |
|---|---|
| TCP/UDP traffic (non-HTTP) | Azure Load Balancer |
| Single-region web app with WAF | Application Gateway |
| Multi-region web app with global users | Azure Front Door |
| DNS failover between regions | Traffic Manager |
| Internal microservices behind NVAs | Load Balancer (internal, HA Ports) |
| API with URL path routing, no global need | Application Gateway |
| Static content acceleration worldwide | Azure Front Door (with caching) |
| Combination: global + regional | Front Door + Application Gateway |
Many production architectures combine multiple services. A common pattern is Front Door for global routing and caching at the edge, with Application Gateway in each region for WAF and URL-based routing, and an internal Load Balancer in front of backend VMs.
Wrapping Up
Azure gives you the right tool for every load balancing scenario, but using the wrong one is a common and expensive mistake. Start with the traffic type — if it is not HTTP, you need Azure Load Balancer. If it is HTTP and regional, Application Gateway with WAF v2 is the answer. If your users are global and you need edge caching with sub-second failover, Front Door is worth the premium. And Traffic Manager fills the gap when you need DNS-level routing without proxying traffic. Know the layers, know the scope, and the choice becomes obvious.
Next up: We will explore Azure Container Apps — running containerized workloads without the operational overhead of managing Kubernetes clusters.