Azure Traffic Manager

About Azure Traffic Manager

Azure Traffic Manager is Microsoft's DNS-based global traffic routing service for public applications and services. It does not proxy application traffic. Instead, it answers DNS queries with the address of an appropriate healthy endpoint based on the routing method configured for a Traffic Manager profile. Endpoints can be Azure resources, external public endpoints, or nested Traffic Manager profiles, which makes the service useful for multi-region Azure deployments, hybrid architectures, and failover designs that include non-Azure infrastructure.

What is Azure Traffic Manager used for?

Traffic Manager is used when an application needs to direct users across multiple public endpoints without placing a Layer 7 proxy in the request path. Common uses include active-passive regional failover, active-active distribution, directing users toward lower-latency endpoints, geographic routing, controlled traffic shifting, and hybrid failover between Azure and externally hosted services.

Because Traffic Manager works through DNS, the client ultimately connects directly to the selected endpoint. This differs from Azure Front Door, which receives and proxies HTTP and HTTPS traffic at Microsoft's edge. Traffic Manager can therefore be useful for public services that need global DNS-based routing but do not need CDN caching, web application firewall inspection, or edge TLS termination.

Which routing methods does Traffic Manager support?

Microsoft documents six Traffic Manager routing methods: Priority, Weighted, Performance, Geographic, Multivalue, and Subnet. Priority is suited to active-passive failover because the highest-priority healthy endpoint is returned. Weighted routing distributes DNS responses according to configured endpoint weights and can support staged traffic movement or active-active designs.

Performance routing sends users toward the endpoint with the lowest expected network latency based on Traffic Manager's latency data. Geographic routing maps users to endpoints according to geographic location and can support scenarios such as regional experiences or data-sovereignty routing. Multivalue can return multiple healthy external IP endpoints in a DNS response. Subnet routing lets administrators map source IP ranges to specific endpoints.

How do health checks and automatic failover work?

Traffic Manager continuously monitors configured endpoints and removes degraded endpoints from DNS answers according to the routing method. Microsoft supports HTTP, HTTPS, and TCP health probes. Administrators configure probe protocol, port, path where relevant, interval, timeout, and the tolerated number of failures before an endpoint is considered unhealthy.

This health monitoring supports automated DNS failover, but failover is not instantaneous for every user. DNS responses are cached by recursive resolvers and clients according to the profile's time-to-live value. Microsoft's pricing guidance notes a default TTL of 300 seconds and a minimum of 30 seconds. A shorter TTL can make endpoint changes visible more quickly, but it also increases DNS query volume and can raise Traffic Manager charges.

What endpoints can Traffic Manager route to?

Traffic Manager supports Azure endpoints, external endpoints, and nested Traffic Manager profiles. Azure endpoints cover supported public Azure resources. External endpoints can reference public IPv4 or IPv6 addresses, fully qualified domain names, on-premises systems, or services hosted by another provider. Nested endpoints let one Traffic Manager profile reference another profile, enabling more complex combinations of routing methods.

Microsoft states that profiles can be nested up to 10 levels deep. This can support architectures such as geographic routing at the top level with performance or priority routing beneath it. Nested designs should be kept understandable because DNS behavior, health status, and failover paths become harder to troubleshoot as more layers are added.

How does Azure Traffic Manager pricing work?

Traffic Manager does not use one fixed monthly subscription price. Microsoft currently bases billing mainly on DNS query volume and monitored endpoints. DNS queries are metered per million queries, with different pricing after the first one billion monthly queries. Endpoint health checks are charged per monitored endpoint, and Azure endpoints and external endpoints can have different rates.

Optional capabilities can add cost. Microsoft's pricing page separately meters fast-interval health checks, HTTPS health-check add-ons, nested endpoints, Real User Measurements, and Traffic View data processing. The exact rate can vary by billing context, so buyers should use the current Azure pricing page or calculator rather than hard-code a single price into an architecture estimate.

Traffic Manager vs Front Door, Application Gateway, and Load Balancer

Traffic Manager makes a routing decision in DNS and then gets out of the data path. Azure Front Door is a global HTTP and HTTPS reverse proxy and edge delivery platform. Front Door is generally the better fit when a web application needs edge acceleration, CDN caching, managed WAF, edge TLS processing, or application-layer routing at Microsoft's global edge.

Azure Application Gateway is a regional Layer 7 load balancer for HTTP and HTTPS applications and can provide WAF inside an Azure region or virtual-network design. Azure Load Balancer operates at Layer 4 for TCP and UDP traffic. Traffic Manager is therefore most useful when the requirement is global DNS-based endpoint selection across public endpoints, including endpoints outside Azure.

What are the main limitations and design tradeoffs?

The biggest design constraint is DNS caching. Traffic Manager can stop returning an unhealthy endpoint, but clients or recursive resolvers may continue using an address they already cached until the DNS TTL expires. This means application failover behavior depends on DNS caching as well as Traffic Manager health detection.

Traffic Manager also does not inspect application traffic after DNS resolution. It does not provide CDN caching, WAF protection, request-header routing, TLS offload, or connection-level load balancing. Geographic routing is based on the source of the DNS query, commonly a recursive DNS resolver, rather than guaranteed precise end-user device location. Performance routing also uses network-latency mapping and cannot account for every real-time application or network condition.

Who should choose something else?

Choose Azure Front Door instead when a global web application needs reverse proxying, CDN acceleration, WAF, edge TLS, or HTTP-aware routing. Choose Application Gateway when Layer 7 routing and WAF are needed regionally. Choose Azure Load Balancer for Layer 4 TCP or UDP distribution inside regional network designs.

Traffic Manager can still complement those services. For example, an organization can route DNS across multiple regional application stacks that each use Application Gateway or Load Balancer internally. The deciding question is whether the global routing decision should happen at DNS resolution or whether traffic must pass through an Azure proxy or load-balancing service.