6.2 Azure Traffic Manager & DNS Load Balancing

Azure Traffic Manager & DNS Load Balancing

While Azure Front Door operates as an active Layer 7 reverse proxy, Azure Traffic Manager (ATM) operates at the DNS layer. Traffic Manager uses the global Domain Name System to direct client requests to the most appropriate service endpoint based on sophisticated traffic-routing algorithms and continuous health monitoring.

Because Traffic Manager works strictly at the DNS level, it is completely protocol-agnostic. It can direct traffic for non-HTTP applications, such as multiplayer gaming (UDP), legacy enterprise protocols (TCP), database replication streams, and VPN endpoints, in addition to standard web traffic.

1. How DNS-Based Load Balancing Works

To understand Traffic Manager, you must master the step-by-step DNS resolution lifecycle. Traffic Manager is never in the data path between the client and the application server. Once DNS resolution completes, the client communicates directly with the target endpoint's IP address.

+-----------------------------------------------------------------------------+
|                   AZURE TRAFFIC MANAGER DNS RESOLUTION FLOW                 |
|                                                                             |
|   1. Client queries local DNS resolver for 'app.contoso.com'                |
|   2. Local DNS resolver queries Azure DNS Name Servers for Traffic Manager  |
|   3. Traffic Manager evaluates routing method + endpoint health status      |
|   4. Traffic Manager returns IP address (e.g., 20.40.60.80) to DNS resolver |
|   5. Local DNS resolver caches IP according to TTL and returns IP to client |
|   6. Client connects DIRECTLY to 20.40.60.80 over TCP/UDP/HTTP/HTTPS        |
|                                                                             |
|   [Client] ===================== Direct Data Flow ====================> [Origin]
|      ^                                                                     |
|      |---- DNS Query/Response (Traffic Manager in Control Plane Only) -----|   |
+-----------------------------------------------------------------------------+

Key Characteristics of DNS Load Balancing:

• No Bandwidth Bottleneck: Because application data packets do not flow through Traffic Manager, there is no throughput limitation, gateway processing overhead, or per-gigabyte data processing fee.
• Protocol Independence: Supports any protocol over TCP or UDP (e.g., SSH, RDP, custom socket protocols, RTP audio/video).
• Client & Resolver Caching Dependency: Failover speed is governed by the configured DNS TTL and whether intermediate recursive DNS resolvers respect the TTL header.

2. Deep Dive: The Six Traffic Routing Methods

Azure Traffic Manager provides six distinct routing methods to satisfy diverse availability, performance, geographic compliance, and client-steering requirements.

+-----------------------------------------------------------------------------+
|                  TRAFFIC MANAGER ROUTING METHODS SUMMARY                    |
|                                                                             |
|   Method         Primary Objective           Selection Mechanism            |
|   ------------   -------------------------   ----------------------------   |
|   Priority       Active / Passive Failover   Lowest priority integer (1..N) |
|   Weighted       Traffic Distribution        Proportional weight (1..1000)  |
|   Performance    Lowest Network Latency      Internet Latency Table Map     |
|   Geographic     Data Sovereignty & Geo-Lock DNS query source IP geographic |
|   Multivalue     Client-Side Failover        Returns up to 8 healthy IPs    |
|   Subnet         Deterministic IP Mapping    Client IP subnet CIDR ranges   |
+-----------------------------------------------------------------------------+

1. Priority Routing (Active / Standby Failover)

• Mechanics: Each endpoint is assigned a unique priority integer from 1 to 1000 (1 being highest priority). Traffic Manager always returns the healthy endpoint with the lowest priority number.
• Failover Behavior: If Priority 1 fails health checks, Traffic Manager automatically starts returning Priority 2. When Priority 1 recovers, Traffic Manager immediately fails back to Priority 1.
• Use Case: Primary datacenter with a warm disaster recovery (DR) site.

2. Weighted Routing (Traffic Splitting & Canary Testing)

• Mechanics: Endpoints are assigned an integer weight from 1 to 1000. Traffic Manager distributes DNS responses proportionally based on total weight.
• Formula: $\text{Percentage} = \frac{\text{Endpoint Weight}}{\sum \text{All Healthy Endpoint Weights}} \times 100%$
• Use Case: Blue-green deployments, canary testing new software versions (e.g., 90% traffic to stable version, 10% to new release), and gradual cloud migrations.

3. Performance Routing (Lowest Latency)

• Mechanics: Microsoft continuously maintains and updates a global Internet Latency Table tracking round-trip times between global IP address ranges and all Azure datacenters. When a DNS request arrives, Traffic Manager looks up the source IP of the recursive DNS resolver in this table and returns the endpoint offering the lowest network latency.
• Use Case: Multi-region deployments where users should always connect to the geographically closest and fastest datacenter.

4. Geographic Routing (Data Sovereignty & Regional Content)

• Mechanics: Administrators explicitly map geographic regions (World, Regional Groups, Countries, or US States/Provinces) to specific endpoints. When a DNS query originates from an IP within that geographic territory, Traffic Manager directs it strictly to the assigned endpoint.
• Key Behavior: Geographic routing does not fail over across geographic boundaries by default unless configured with a catch-all endpoint (All (World)). If an endpoint assigned to Western Europe fails and no fallback is defined, European users receive an unresolvable DNS response (NXDOMAIN / SERVFAIL) to prevent accidental violation of data sovereignty laws (e.g., GDPR).

5. Multivalue Routing (Client-Side Load Balancing & Resilience)

• Mechanics: Returns up to 8 healthy IPv4 and IPv6 endpoint IP addresses in a single DNS query response.
• Client Behavior: The client browser or application receives multiple A/AAAA records and can perform round-robin load balancing or automatically retry alternative IPs if the primary connection fails, without waiting for a new DNS query.
• Constraint: Requires endpoints to be configured with static public IP addresses (not FQDNs).

6. Subnet Routing (Deterministic IP Range Mapping)

• Mechanics: Administrators map specific client IPv4/IPv6 CIDR prefixes (e.g., corporate headquarters 198.51.100.0/24, branch offices 203.0.113.0/24) to designated endpoints.
• Use Case: Directing internal corporate users to dedicated test environments, steering business partners to customized tenant clusters, or enforcing compliance boundaries based on known IP blocks.

3. Nested Traffic Manager Profiles

Complex enterprise architectures frequently require combining multiple routing methods. Azure supports Nested Profiles, where a child Traffic Manager profile is added as an endpoint to a parent Traffic Manager profile.

+-----------------------------------------------------------------------------+
|                   NESTED TRAFFIC MANAGER PROFILE TOPOLOGY                   |
|                                                                             |
|                       [Parent Profile: Geographic Routing]                  |
|                       - Europe Queries  -> Child Profile EU                 |
|                       - Americas Queries -> Child Profile US                |
|                                    |                                        |
|                  +-----------------+-----------------+                      |
|                  |                                   |                      |
|                  v                                   v                      |
|   [Child Profile EU: Priority]         [Child Profile US: Weighted]         |
|   - Primary: West Europe (P1)          - Production App: 80%                |
|   - Standby: North Europe (P2)         - Canary App: 20%                    |
+-----------------------------------------------------------------------------+

Nested Profile Architecture Guidelines:

• Parent Evaluation: The parent profile routes the incoming DNS query based on its top-level routing method (e.g., Geographic or Subnet).
• Child Evaluation: The child profile receives the request and applies its own routing method (e.g., Priority failover between regional clusters, or Weighted canary splitting).
• Health Aggregation: A child profile is considered healthy by the parent profile only if the minimum configured number of healthy endpoints within that child profile are online.

4. Endpoint Types, Health Monitoring & Probing Architecture

Traffic Manager supports three types of endpoints:

1. Azure Endpoints: Public IPs, App Services, or Cloud Services hosted within Microsoft Azure.
2. External Endpoints: On-premises servers, third-party cloud VMs (AWS, GCP), or external IP/FQDNs.
3. Nested Endpoints: Other Traffic Manager child profiles.

Endpoint Health Probing Mechanics

Traffic Manager monitors endpoint health via distributed probing agents running worldwide.

Endpoint Status States:

• Online: Endpoint is responding successfully to health probes and receiving DNS traffic.
• Degraded: Endpoint failed consecutive health probes exceeding the failure threshold; removed from DNS response rotation.
• Inactive / Disabled: Administratively disabled by the administrator; no health probes sent and no DNS traffic routed.

5. DNS TTL Tuning & Caching Implications

The DNS Time-to-Live (TTL) setting in Traffic Manager dictates how many seconds a client device or recursive DNS resolver can cache the DNS record before making a fresh query.

+-----------------------------------------------------------------------------+
|                        DNS TTL TRADE-OFF MATRIX                             |
|                                                                             |
|   Setting      Failover Speed       DNS Query Volume      Resolver Load     |
|   ----------   ------------------   -------------------   ---------------   |
|   Low TTL      Fast Failover        High Query Volume     Higher Cost &     |
|   (10s - 30s)  (10 - 60 seconds)    (Frequent Lookups)    DNS Overhead      |
|                                                                             |
|   High TTL     Slow Failover        Low Query Volume      Optimized Cache & |
|   (300s+)      (5 - 15+ minutes)    (Infrequent Lookups)  Lower Cost        |
+-----------------------------------------------------------------------------+

[!CAUTION] The Recursive DNS Caching Problem: Even if Traffic Manager TTL is set to 10 seconds, some public ISP DNS resolvers enforce minimum TTL floors (e.g., caching records for 60 to 300 seconds regardless of authority headers). Applications requiring guaranteed, instantaneous sub-second failover should use Azure Front Door (Anycast BGP) rather than DNS-based Traffic Manager.