Azure Traffic Manager Routing Methods

Azure Traffic Manager is a DNS-based traffic load balancer. It operates at the DNS layer (OSI Layer 7) to distribute incoming DNS requests across multiple endpoints (Azure VMs, cloud services, web apps, or external endpoints) based on a chosen routing method. Unlike Azure Load Balancer (Layer 4) or Application Gateway (Layer 7 with HTTP awareness), Traffic Manager does not terminate traffic or inspect packets. It simply responds to DNS queries with the IP address of the most appropriate endpoint based on the routing method, health of endpoints, and client's DNS resolver location.

Traffic Manager solves several problems: - Global load balancing: Distribute traffic across Azure regions or on-premises data centers. - High availability: Automatically fail over from unhealthy endpoints to healthy ones. - Performance optimization: Route users to the endpoint with the lowest latency. - Geographic compliance: Route users to specific regions based on their location (e.g., EU users to EU data centers for GDPR).

When a client makes a DNS query for a domain name (e.g., myapp.trafficmanager.net), the client's DNS resolver sends the query to Azure's authoritative DNS servers. Traffic Manager intercepts this query and, based on the routing method and the health of endpoints, returns a CNAME record pointing to the chosen endpoint's domain name (or directly an IP for external endpoints). The client's browser then resolves that endpoint's IP and connects directly. Traffic Manager does not proxy traffic; it only influences the initial DNS resolution.

Key components: - Traffic Manager profile: Contains the DNS name (e.g., myapp.trafficmanager.net), routing method, endpoints, and health check configuration. - Endpoints: Can be Azure endpoints (cloud services, web apps, VMs), external endpoints (on-premises servers), or nested endpoints (child Traffic Manager profiles). - Health checks: Traffic Manager periodically probes each endpoint using HTTP/HTTPS/TCP on a configurable port and path. Endpoints that fail a configurable number of consecutive probes are marked as degraded and are not returned in DNS responses (unless the routing method has no healthy endpoints, in which case all endpoints are considered).

#### Priority Routing - How it works: Assign a numeric priority to each endpoint (1 = highest priority). Traffic Manager returns the highest-priority healthy endpoint. If that endpoint becomes unhealthy, it returns the next priority, and so on. - Use case: Active-passive failover. For example, primary region (priority 1), secondary region (priority 2), tertiary (priority 3). - Default values: Priority must be unique among endpoints. No default priority; you must assign it. If no endpoints are healthy, Traffic Manager returns all endpoints (the client may experience failure). - Exam trap: Candidates often confuse priority with weighted routing. Remember: priority is for failover, not load distribution.

#### Weighted Routing - How it works: Assign a weight (integer from 1 to 1000) to each endpoint. Traffic Manager distributes DNS responses proportionally to the weights. For example, two endpoints with weights 80 and 20 receive 80% and 20% of DNS responses, respectively. The distribution is statistical; real traffic may vary due to DNS caching. - Use case: Load balancing across endpoints with different capacities, or gradual rollout (e.g., 10% traffic to new version). - Default values: If no weight is specified, the default weight is 1. All endpoints with weight 1 get equal traffic. - Exam trap: Weighted routing does NOT guarantee exact traffic split per request; it's probabilistic. Also, weights apply only to healthy endpoints. If an endpoint is unhealthy, its weight is ignored, and remaining healthy endpoints share traffic proportionally.

#### Performance Routing - How it works: Traffic Manager maintains a latency table mapping client DNS resolver IP ranges to Azure regions. When a query arrives, it looks up the client's DNS resolver IP, finds the region with the lowest latency (based on historical measurements), and returns the endpoint in that region (or the endpoint with the lowest measured latency). If multiple endpoints are in the same region, Traffic Manager returns one based on a round-robin or weighted method (if weights are configured). - Use case: Global applications where users should connect to the nearest data center for lowest latency. - Default values: No configuration needed beyond adding endpoints and enabling performance routing. Traffic Manager automatically measures latency between Azure regions and the internet. - Exam trap: Performance routing is based on the DNS resolver's IP, not the end user's IP. Corporate DNS resolvers may be in a different region than the user. Also, latency measurements are between Azure regions and the DNS resolver, not the end user. This can lead to suboptimal routing.

#### Geographic Routing - How it works: Map geographic regions (countries, states, or continents) to specific endpoints. Traffic Manager examines the DNS resolver's IP address to determine the geographic region and returns the endpoint mapped to that region. If no mapping exists, Traffic Manager returns the endpoint configured as the default (if any). - Use case: Compliance with data sovereignty laws (e.g., EU data must stay in EU), or content localization. - Configuration: You must map regions to endpoints explicitly. Regions are defined by ISO country codes or predefined groupings (e.g., North America, Europe). - Exam trap: Geographic routing does NOT consider latency or health beyond basic health checks. If the mapped endpoint is unhealthy, Traffic Manager does NOT fail over to another region; it returns the unhealthy endpoint (or returns nothing if no default is configured). You must use nested profiles to implement failover within a region.

#### Subnet Routing (formerly Multivalue Routing) - How it works: Map IP address ranges (CIDR blocks) to specific endpoints. When a DNS query comes from an IP within a mapped range, Traffic Manager returns the corresponding endpoint. This allows fine-grained control based on client IP. - Use case: Restrict access to certain endpoints for specific IP ranges (e.g., internal corporate network to internal endpoint). - Configuration: Add subnet-to-endpoint mappings. You can also specify a default endpoint for unmapped IPs. - Exam trap: Subnet routing is rarely tested but may appear in scenarios where you need to route specific clients to specific endpoints.

Nested profiles allow combining routing methods. For example, use geographic routing at the top level to send EU users to a child profile that uses performance routing within Europe. The child profile can have multiple endpoints in different European regions. This enables complex, multi-layered routing policies.

Traffic Manager monitors endpoint health using probes. You configure: - Protocol: HTTP, HTTPS, or TCP. - Port: Default 80 for HTTP/HTTPS, 443 for HTTPS. - Path: For HTTP/HTTPS, the path to probe (e.g., /health). Default is "/". - Interval: How often probes are sent (default 30 seconds). - Timeout: How long to wait for a response (default 10 seconds). - Tolerated number of failures: Number of consecutive failures before marking endpoint as degraded (default 3).

An endpoint is considered healthy only if it responds within the timeout for the tolerated number of probes. If an endpoint is degraded, Traffic Manager stops returning it in DNS responses (unless all endpoints are degraded, in which case all are returned).

Traffic Manager sets the TTL on DNS responses (default 300 seconds). Clients and DNS resolvers cache the response for the TTL duration. This means routing changes (e.g., failover) are not immediate; they take effect only after the TTL expires and the client re-queries. For faster failover, you can reduce the TTL to as low as 30 seconds, but this increases DNS query load.

Create a Traffic Manager profile:

az network traffic-manager profile create \
  --name MyProfile \
  --resource-group MyRG \
  --routing-method Priority \
  --unique-dns-name myapp \
  --monitor-protocol HTTP \
  --monitor-port 80 \
  --monitor-path /health

Add endpoints:

az network traffic-manager endpoint create \
  --name Endpoint1 \
  --type azureEndpoints \
  --profile-name MyProfile \
  --resource-group MyRG \
  --target-resource-id /subscriptions/.../microsoft.web/sites/myapp1 \
  --priority 1

Update routing method:

az network traffic-manager profile update \
  --name MyProfile \
  --resource-group MyRG \
  --routing-method Weighted

Use nslookup or dig to see which endpoint is returned:

nslookup myapp.trafficmanager.net

Check health status via Azure Portal or CLI:

az network traffic-manager endpoint show \
  --name Endpoint1 \
  --profile-name MyProfile \
  --resource-group MyRG \
  --query 'endpointMonitorStatus'

A multinational e-commerce company uses Priority routing to implement active-passive failover between two Azure regions: West US (primary) and East US (secondary). The primary region hosts the production web app. If the primary region becomes unavailable (e.g., due to a regional outage), Traffic Manager automatically routes traffic to the secondary region. The health check probes the /health endpoint on the web app every 30 seconds. If three consecutive probes fail (90 seconds), the endpoint is marked degraded. The TTL is set to 60 seconds for faster failover. In production, this setup provides a recovery time objective (RTO) of about 2 minutes. A common mistake is setting the TTL too low (e.g., 30 seconds), which increases DNS query load and may cause DNS resolver throttling. Another mistake is not configuring the secondary region to handle full production load, leading to performance degradation during failover.

A SaaS provider serves users worldwide. They deploy the application in three Azure regions: West Europe, Southeast Asia, and West US. They configure Performance routing to direct users to the region with the lowest latency. The latency table is automatically maintained by Azure. However, the company notices that users in Australia are sometimes routed to Southeast Asia instead of the closer Australia East region. This happens because the DNS resolver in Australia may have lower measured latency to Southeast Asia due to network paths. To fix this, they add an endpoint in Australia East and use a nested profile: Geographic routing at the top level to send Australian users to a child profile that uses Performance routing within Australia. This ensures Australian users are always directed to the Australian region.

A company deploys a new version of their web app. They have two endpoints: production (version 1) and staging (version 2). They configure Weighted routing with weights 90 and 10, respectively. This sends 10% of DNS queries to the new version. After monitoring for errors, they gradually increase the weight of the new version to 50, then 100. A common pitfall is forgetting that DNS caching can cause some users to still see the old version for up to the TTL duration. To mitigate, they set a low TTL (60 seconds) during the rollout. Also, if the staging endpoint becomes unhealthy, Traffic Manager automatically sends all traffic to the production endpoint, preventing impact on users.