Skip to main content
Azure offers multiple load‑balancing services, each optimized for different traffic types, scopes, and application requirements. This guide compares the core options and provides decision guidance to help you pick the right service or combination for your workload. Use these keywords when searching or optimizing content: Azure load balancing, Application Gateway, Azure Front Door, Azure Load Balancer, Traffic Manager, WAF, TLS termination, global load balancing.

​
Four core Azure load‑balancing services

  • Application Gateway
    A Layer 7 (HTTP/HTTPS) load balancer that operates at the application layer. Supports internal and public deployments, SSL/TLS offloading (termination) with optional re-encryption to backends, Web Application Firewall (WAF) protection, path-based routing, cookie affinity, and autoscaling. Application Gateway is regional and is designed for advanced application-level routing and security.
  • Front Door
    A global Layer 7 load-balancing and application acceleration service built on Microsoft’s global edge network. Features global HTTP/HTTPS load balancing, TLS termination at the edge, URL-based routing, caching and site acceleration (dynamic site acceleration), and intelligent routing (latency/proximity). Ideal for globally distributed, performance-sensitive web applications.
  • Azure Load Balancer
    A Layer 4 (TCP/UDP) load balancer offering ultra-low latency and high throughput. Supports internal and public endpoints and is best for non-HTTP workloads (SQL, RDP, gaming, custom TCP/UDP services). Available in Basic and Standard SKUs; Standard is recommended for production due to predictable performance and zone-redundant options.
  • Traffic Manager
    A DNS-based traffic routing service that responds to DNS queries and directs clients to endpoints using routing methods such as priority, performance, weighted, geographic, multi-value, and subnet. Because it is DNS-based, Traffic Manager does not proxy or terminate traffic (no TLS offload, no WAF). Commonly used for global distribution, geo-failover, and region-based routing.
A slide titled "Load Balancer" showing four Azure traffic services—Application Gateway, Front Door, Load Balancer, and Traffic Manager—each in a panel with short bullet points describing their features (layer, SSL offloading, internal/public configs, global availability). The image compares their primary use cases and capabilities.

​
Quick comparison table

ServiceOSI LayerScopeBest for / Use casesKey capabilities
Application Gateway7 (HTTP/HTTPS)RegionalInternet-facing web apps needing WAF, path-based routingWAF, TLS offload/re-encrypt, cookie affinity, autoscale
Front Door7 (HTTP/HTTPS)GlobalGlobally-distributed, latency-sensitive web appsEdge TLS termination, DSA, caching, global routing
Azure Load Balancer4 (TCP/UDP)Regional (can be deployed per region)Non-HTTP workloads and internal servicesLow latency, high throughput, public/internal endpoints
Traffic ManagerDNS-basedGlobalDNS failover, geo-routing, multi-region preferenceDNS routing methods (performance, priority, geographic) — no proxying

​
How Traffic Manager works

Traffic Manager directs clients by responding to DNS queries and selecting the most appropriate endpoint based on the chosen routing method. Because it only manipulates DNS responses, it does not proxy traffic, perform TLS termination, or provide WAF capabilities. Use Traffic Manager for DNS-level failover and geolocation routing where client-side DNS behavior is acceptable.

​
Decision checklist — map requirements to service selection

Consider these decision points when choosing a load balancing solution:
  • Traffic type: HTTP/HTTPS (web) vs non‑HTTP (TCP/UDP).
  • Scope: Regional vs global distribution.
  • Application requirements: Need for WAF, TLS offload, path-based routing, session affinity, or application-layer inspection?
  • Availability: Zone redundancy, RTO expectations, and how failover should work (DNS vs proxy).
  • Performance and acceleration: Need for edge caching, dynamic site acceleration (DSA), or global low‑latency routing?
  • Deployment model: PaaS (App Services), IaaS (VMs), or containerized (AKS).
  • Cost and operational trade‑offs: Pricing model, features required, and operational complexity.
Use the answers to these items to determine whether a single service meets your needs or whether a hybrid (Front Door + Application Gateway, etc.) is required. If your application is not web-based (non-HTTP) and is internal (not internet-facing), Azure Load Balancer is typically the right choice for regional deployments. For multi-region non-HTTP workloads, you can combine Traffic Manager (DNS routing) with regional Azure Load Balancers to distribute users across regions. If your application is web-based and internet-facing, decide between single-region and multi-region/global deployment:
  • Single-region, internet-facing web app:
    Application Gateway is appropriate when you require regional WAF, path-based routing, and granular application-layer control.
  • Multi-region / global web app:
    • Front Door as global entry point: Use Front Door when you need global HTTP/HTTPS load balancing, edge TLS termination, caching, and latency-based routing.
    • Front Door + Application Gateway: Front Door handles global routing/acceleration and routes traffic to Application Gateway instances in each region when you need regional WAF and deep application-layer processing.
    • Front Door + Load Balancer: For IaaS/VM backends, Front Door can be used in front of regional Azure Load Balancers that distribute traffic to VM pools.
    • Traffic Manager in front of regional services: Use Traffic Manager for DNS-based failover and geolocation routing (no proxying).
For PaaS workloads (platform-managed web apps), Front Door can route directly to platform-managed endpoints. For Azure Kubernetes Service (AKS), deploy an Ingress controller in each cluster for region-local routing, and use Front Door or Traffic Manager to provide global distribution across clusters. See the AKS guidance for cluster-level ingress strategies: https://learn.kodekloud.com/user/courses/azure-kubernetes-service
A flowchart titled "Choosing a Load Balancing Option" that guides you through questions (web app, internet-facing, global scope, SSL offload, performance) to pick an Azure load‑balancing solution. The possible outcomes shown include Azure Load Balancer, Traffic Manager, Application Gateway, Azure Front Door, and various combinations, each with service icons.

​
Common combination patterns

  • Front Door + Application Gateway: Front Door provides global edge routing, TLS termination at the edge, and caching. Application Gateway in each region provides regional WAF and application-layer routing.
  • Front Door + Load Balancer: Ideal for IaaS/VM backends where Front Door offers global entry and regional Azure Load Balancers distribute traffic to VM pools.
  • Traffic Manager + Load Balancer/Application Gateway: DNS-based failover and geo-routing directing clients to regional load‑balancing stacks without proxying.
Remember: Traffic Manager is DNS-based and only influences DNS resolution; it does not proxy traffic, cannot perform TLS termination, and relies on client DNS caching behavior. For edge-based TLS offload and application acceleration, use Front Door.

​
Next steps

Use the flowchart and the decision checklist above to map your application requirements to the right Azure load‑balancing service or combination. Next, we will dive deeper into Application Gateway — configuration options, WAF policies, and a regional deployment example.

Watch Video