Azure Traffic Manager Routes Globally. The Routing Authority Is Centrally Defined.
by Nick Clark | Published March 28, 2026
Azure Traffic Manager distributes traffic globally across Azure regions and external endpoints using DNS-based routing with methods including priority, weighted, geographic, performance, and multivalue. It is a mature, reliable service for global load distribution. But Traffic Manager's routing authority is centrally defined: profiles, endpoints, and routing methods are configured in Azure's management plane and propagated through DNS. The endpoints do not govern their own resolution. They are governed by a centrally defined profile. The structural gap is between global traffic routing and scope-local namespace governance.
Traffic Manager's reliability across Azure's global infrastructure is well established. Nested profiles, endpoint monitoring, and automatic failover represent solid engineering. The gap described here is about routing authority, not routing reliability.
Profiles define routing centrally
A Traffic Manager profile defines the routing method and the set of endpoints. When a DNS query arrives, Traffic Manager evaluates the profile's routing method against the available endpoints and returns the appropriate DNS response. The profile is the authority.
If routing needs to change, the profile is updated centrally. If a new endpoint joins, it is added to the profile. If a region needs different routing logic, a nested profile is configured. Every routing decision traces back to a profile defined in Azure's control plane. The endpoints participate in health monitoring but not in routing governance.
DNS propagation delays governance changes
Traffic Manager operates through DNS, which means routing changes are subject to TTL-based propagation delays. A profile update does not take effect until DNS caches expire. During the propagation window, different clients may receive different routing decisions depending on their DNS resolver cache state.
The namespace resolution is eventually consistent by necessity of the DNS protocol. There is no mechanism for a routing change to take effect atomically across all clients. The authority model depends on propagation from a central source, not on governed resolution at the point of query.
What scope-governed resolution provides
In a scope-governed model, each region or endpoint group is a scope with its own anchor nodes governing resolution policy. A query resolves by traversing the namespace hierarchy, with each scope governing its segment. Routing changes take effect when the governing anchors approve them through scoped consensus, not when DNS caches expire.
The endpoints participate in governance rather than just health monitoring. A region under regulatory pressure can adjust its own routing policy through its anchors without requiring a central profile update. The authority distributes to where the resolution decisions are made.
The remaining gap
Azure Traffic Manager made global DNS-based routing a managed service. The remaining gap is in routing governance: whether resolution authority can live at the scope where traffic is handled rather than in centrally defined profiles propagated through DNS.
