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, then the client connects directly to that endpoint. This makes Traffic Manager useful for multi-region Azure deployments, hybrid architectures, external public services, and failover designs where the routing decision should happen at DNS resolution rather than through an HTTP reverse proxy. Buyers should plan around DNS caching, endpoint monitoring, probe reachability, and query volume because those factors directly affect failover behavior, availability, and cost.

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, edge TLS termination, or HTTP-aware request routing.

Which routing methods does Traffic Manager support?

Microsoft documents six 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 gradual traffic movement, testing, or active-active designs. Microsoft currently allows weights from 1 through 1000.

Performance routing selects the endpoint with the lowest expected network latency based on Microsoft's latency data. Geographic routing maps DNS queries to endpoints according to geographic location and can support regional experiences or data-sovereignty designs. Subnet routing maps source IP ranges to endpoints. MultiValue routing is different because it can return more than one healthy endpoint in a single DNS response.

How does MultiValue routing work?

Traffic Manager MultiValue routing can return multiple healthy external endpoints in one DNS answer so the client has additional addresses to try without repeating the DNS lookup. Microsoft currently allows administrators to set the maximum response count up to 10 healthy endpoints. This can improve resilience for clients that understand how to retry another returned address.

MultiValue supports A and AAAA endpoint records, including mixed IPv4 and IPv6 designs. Traffic Manager does not guarantee that the same set of endpoints is returned for every query because endpoint health and record type can change the response. Buyers should also remember that returning several addresses is not the same as connection-level load balancing. The application or client still decides which returned address it uses.

How do health checks and automatic failover work?

Traffic Manager continuously monitors configured endpoints and removes degraded endpoints from new DNS answers according to the routing method. Microsoft supports HTTP, HTTPS, and TCP probes. Monitoring settings are shared across endpoints in the same profile, so teams that need different probe behavior for different endpoint groups can use nested profiles.

The current normal probing interval is 30 seconds and the fast interval is 10 seconds. Fast probing is a separately billed add-on. The tolerated failure count can be configured from 0 through 9, with a default of 3. For 30-second probing, the timeout can be configured from 5 through 10 seconds. For 10-second probing, the timeout can be configured from 5 through 9 seconds.

Failover still depends on DNS caching. After Traffic Manager marks an endpoint degraded, recursive DNS resolvers and clients can keep using previously cached answers until their TTL expires. Health detection and client failover therefore need to be tested together rather than treated as the same event.

What should teams know about DNS TTL and failover?

Microsoft's current Traffic Manager FAQ states that DNS TTL can be configured from 0 seconds up to 2,147,483,647 seconds at profile level. A TTL of 0 instructs downstream resolvers not to cache the Traffic Manager answer, while higher values increase caching. Microsoft's pricing guidance still lists 300 seconds as the default TTL.

This corrects a common oversimplification that Traffic Manager has a universal 30-second minimum TTL. A shorter TTL can make health and routing changes visible to clients more quickly, but it increases the number of DNS queries that reach Traffic Manager and can increase charges. A longer TTL reduces query volume and cost but can leave users on a failed or no-longer-preferred endpoint for longer. The right value should reflect the application's recovery objectives and expected DNS volume.

What endpoints and scale limits apply?

Traffic Manager supports Azure endpoints, external public endpoints, and nested Traffic Manager profiles. External endpoints can reference public IPv4 or IPv6 addresses, public fully qualified domain names, on-premises services exposed to the internet, or services hosted by another provider. Nested endpoints let teams combine routing strategies, such as Geographic routing at the top level with Priority or Performance routing underneath.

Microsoft currently documents resource limits of 200 Traffic Manager profiles per subscription and 200 endpoints per profile. Profiles can be nested for more complex designs, but extra layers increase operational complexity and make DNS troubleshooting harder. Teams should use nesting when it represents a real routing requirement rather than only to work around an unclear architecture.

How should firewalls be configured for Traffic Manager probes?

Traffic Manager health probes must be able to reach the monitored endpoints. For Azure-hosted endpoints, Microsoft recommends allowing the AzureTrafficManager service tag in network security groups or Azure Firewall rules. The service tag stays current as Microsoft updates Traffic Manager probe ranges.

For non-Azure endpoints or network devices that cannot consume Azure service tags, Microsoft publishes Traffic Manager probe IP ranges in the Azure IP ranges and service tags file. Those firewall allow lists need to be refreshed when Microsoft changes the ranges. If probes are blocked, Traffic Manager can mark a healthy endpoint as degraded and unexpectedly redirect users elsewhere.

Traffic Manager is designed to monitor publicly reachable endpoints. Endpoints that resolve only to private, non-routable, or Microsoft-internal address spaces cannot receive normal Traffic Manager health validation. Microsoft documents an Always serve traffic configuration for such endpoint situations, but that removes health-based failover for those endpoints.

How does Azure Traffic Manager pricing work?

Traffic Manager has no fixed family-wide subscription price. Microsoft currently bases billing mainly on the number of DNS queries received and the number and type of monitored endpoints. DNS query pricing uses a lower rate after the first one billion monthly queries. Azure and external endpoint health checks have separate meters.

Optional capabilities add other meters. Microsoft separately prices fast-interval health checks, HTTPS health-check add-ons, nested endpoints, Real User Measurements, and Traffic View data processing. Real User Measurements must be enabled by the customer and currently measures Azure regions. Traffic View in the public cloud can analyze DNS-query traffic patterns and representative latency, and Microsoft states that its data is updated at least once every 48 hours.

Pricing was rechecked in September 2026. Buyers should model TTL, query volume, endpoint count, fast probing, nested profiles, and optional analytics together because a low-TTL high-volume profile can have a very different cost profile from a lightly queried failover profile.

What are the main limitations and operational tradeoffs?

The biggest design constraint is still DNS caching. Traffic Manager can stop returning an unhealthy endpoint, but a client or recursive resolver can continue using an answer it already cached. Traffic Manager also does not inspect application traffic after DNS resolution, so it does not provide CDN caching, WAF, TLS offload, header routing, or connection-level load balancing.

Traffic Manager does not provide a static client-facing IP address of its own because clients connect directly to the selected endpoint. It also cannot implement sticky sessions because it does not see application requests and normally sees the recursive resolver rather than the end user's source address. Microsoft does use EDNS Client Subnet information when a resolver provides it, which can improve Geographic, Performance, and Subnet routing decisions, but support depends on the recursive DNS infrastructure.

For web applications, host-header configuration can also matter. Traffic Manager only handles DNS, so HTTP 4xx or 5xx errors generally come from the selected application endpoint rather than the Traffic Manager data path.

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

Traffic Manager makes a routing decision in DNS and then leaves the data path. Azure Front Door is a global HTTP and HTTPS reverse proxy and edge delivery platform. Front Door is usually the stronger fit when a web application needs edge acceleration, CDN caching, managed WAF, edge TLS processing, or application-layer routing.

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 most useful when the requirement is global DNS-based endpoint selection across public endpoints, including endpoints outside Azure. These services can also be combined, such as Traffic Manager routing between regional stacks that each contain Application Gateway or Load Balancer.

Who is Azure Traffic Manager best suited for?

Traffic Manager is a strong fit for organizations that need DNS-based routing across multiple public regions, clouds, datacenters, or providers and want the client to connect directly to the selected endpoint. It is particularly useful for active-passive disaster recovery, low-latency global endpoint selection, geographic routing, controlled weighted shifts, and architectures that include public endpoints outside Azure.

It is also useful when the application protocol is not HTTP or HTTPS but can still be reached through an internet-facing endpoint and DNS-based selection is sufficient. Teams should be comfortable testing DNS TTL behavior, monitoring endpoint health, allowing probe traffic, and operating the selected endpoints independently.

Who should choose something else?

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

Traffic Manager is also a poor fit for applications whose endpoints are private-only and require health-based routing inside private networks. In those cases, a private networking or load-balancing service should be evaluated instead. Teams that require connection-level persistence, request inspection, or instant failover without DNS-cache effects should also use a service that remains in the traffic path.