# Azure Global Load Balancing Comparison Global load-balancing services distribute traffic across applications and endpoints hosted across different regions/geographies. These services route end-user traffic to the available backend based on configurable routing rules. They also feature endpoint monitoring in order to improve high availability and reliability of backend services. Azure offers two global load-balancing services: Azure Traffic Manager and Azure Front Door. [Traffic Manager](https://docs.microsoft.com/en-us/azure/traffic-manager/) is a DNS-based traffic load balancer that distributes traffic to services across global Azure regions. Being a DNS-based load-balancing service, it load balances only at the domain level. As such, it supports any communication protocol and has no performance impact. [Front Door](https://docs.microsoft.com/en-us/azure/frontdoor/) is global load balancing service specifically designed for web applications. Therefore, it works at Layer 7 and offers many capabilities useful for web-based application (e.g SSL offloading, path-based routing, fast fail-over, caching, WAF, etc.) I thought it would be useful to compile a list of features offered by the two services so that they can be easily and quickly compared and contrasted. Azure documentation offers a very practical [decision tree](https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview#decision-tree-for-load-balancing-in-azure) that's great for determining the right load-balancing solution for various scenarios. I hope the table below is helpful!

Feature	Traffic Manager	Front Door
Protocol	Protocol Agnostic (DNS based)	HTTP(S)
Protocol Support: HTTP/2	✔️	✔️
Protocol Suppport: IPv6	✔️	✔️
Supported Backends¹	Any public IP or a publicly resolvable DNS hostname Nested endpoints (used to combine Traffic Manager profiles)	Any public IP or a publicly resolvable DNS hostname
Non-Azure Backends	✔️	✔️
Backend must be public	✔️	✔️
Nesting	✔️	❌
Endpoint Monitoring	✔️	✔️
Fast Fail-over	❌²	✔️
Routing Methods	Performance routing Priority routing Weighted round-robin routing Geographic routing Multivalue Subnet routing	Latency Routing Priority Routing Weighted Routing Geographic Routing (vai WAF policy)
HTTP Property Routing	❌	✔️
Session Affinity	❌	✔️
TLS Termination	❌	✔️
Custom Domain	✔️³	✔️
Wildcard domains	✔️	✔️
Certificate Management	❌	✔️
self-signed certificates	✔️	❌
HTTPS Redirection	❌	✔️
Re-encryption	❌⁴	✔️⁵
WAF	❌	✔️
DDoS	❌	✔️
Caching	❌	✔️
Content Compression	❌	✔️
Session Affinity	❌	✔️
URL Rewrite	❌	✔️
URL redirect	❌	✔️
Traffic View Dashboard	✔️⁶	❌
No Performance Impact	✔️⁷	❌
Pricing Considerations	DNS queries received Monitored endpoints User Measurements Traffic View Data points	Outbound data transfer Inbound data transfer Routing Rules Custom Domains WAF Service Fee WAF Rulesets WAF Custom Rules

* * * * * 1. - Azure Endpoints (PaaS Cloud Services, Storage, Web Apps) - Public IP Address Resources (e.g. VM's with public IPs or Azure Load Balancer) - External Backends (Public IPv4/IPv6 addresses, FQDNs) [↩︎](#fnref:1) 2. Traffic Manager fail over limited by DNS caching/TTL [↩︎](#fnref:2) 3. Traffic Manager supports Custom Domain via CNAME or Alias Records. [↩︎](#fnref:3) 4. Traffic Manager doesn't support TLS Termination, so re-encryption isn't necessary. [↩︎](#fnref:4) 5. Front Door connections to the backend happen over public IP, so it is recommended that Front Door is configured to use HTTPS as the forwarding protocol. [↩︎](#fnref:5) 6. Traffic Manager Traffic View provides a dashboard of user base regions and their traffic patterns. [↩︎](#fnref:6) 7. Traffic Manager works at the DNS level. Client connections are direct to service endpoints, and so there is no performance impact incurred when using Traffic Manager. [↩︎](#fnref:7)