Module: Design Business Continuity Solutions

Lesson: Azure Traffic Manager Routing Methods

Introduction

In the world of cloud architecture, high availability is not just a luxury—it is a requirement. Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness.

Unlike a traditional load balancer that operates at the transport layer (OSI layer 4), Traffic Manager operates at the DNS layer. It uses DNS queries to direct client requests to the most appropriate service endpoint based on the routing method you select. Understanding these routing methods is critical for designing systems that can withstand regional outages and provide low-latency experiences for a global user base.

---

Understanding Traffic Manager Routing Methods

Traffic Manager offers six distinct routing methods. Choosing the right one depends on your business goals—whether you prioritize geographic proximity, system health, or even distribution.

1. Priority Routing

Use this method when you have a primary service endpoint and want to designate "failover" endpoints.

• How it works: Each endpoint is assigned a priority number (1 is the highest). Traffic is always sent to the highest-priority endpoint that is healthy.
• Use Case: Active-Passive disaster recovery setups.

2. Weighted Routing

Use this method to distribute traffic across a set of endpoints based on their assigned weight.

• How it works: You assign a weight (1–1000) to each endpoint. Traffic is distributed proportionally. If Endpoint A has a weight of 10 and Endpoint B has a weight of 90, 90% of traffic goes to B.
• Use Case: Canary deployments or A/B testing where you want to gradually shift traffic to a new version.

3. Performance Routing

This is the "go-to" for global applications.

• How it works: Traffic Manager directs the user to the endpoint with the lowest network latency. It constantly monitors the latency between the user's DNS resolver and Azure regions.
• Use Case: Global web applications where performance is the primary KPI.

4. Geographic Routing

This method maps requests based on the physical location of the user.

• How it works: Users are routed to specific endpoints based on their geographic origin (Country, Region, or Continent).
• Use Case: Content localization or complying with data sovereignty laws (e.g., ensuring EU user data stays in EU regions).

5. Multivalue Routing

This method returns multiple healthy endpoints to the DNS query.

• How it works: It provides a list of all healthy endpoints to the client. The client (or the browser) then decides which one to connect to.
• Use Case: High-scale applications that require multiple healthy endpoints for load balancing at the client level.

6. Subnet Routing

This method maps sets of end-user IP address ranges to specific endpoints.

• How it works: If a request comes from an IP range defined in your configuration, it is routed to the specific endpoint mapped to that range.
• Use Case: Internal enterprise applications where specific office locations need to hit specific regional endpoints.

---

Practical Example: Configuring Priority Routing

In an Azure Bicep or ARM template, you define the routing method within the Traffic Manager profile. Below is a simplified Bicep snippet for a Priority-based profile:

resource trafficManagerProfile 'Microsoft.Network/trafficManagerProfiles@2022-04-01' = {
  name: 'my-traffic-manager'
  location: 'global'
  properties: {
    profileStatus: 'Enabled'
    trafficRoutingMethod: 'Priority' // Routing Method defined here
    dnsConfig: {
      relativeName: 'myapp-dns'
      ttl: 30
    }
    monitorConfig: {
      protocol: 'HTTPS'
      port: 443
      path: '/health'
    }
  }
}

---

Best Practices

1. Configure Meaningful TTLs: The Time-to-Live (TTL) setting in your DNS configuration dictates how long a client will cache the result. A low TTL (e.g., 30 seconds) ensures faster failover but increases the load on your DNS servers.
2. Health Checks are Crucial: Traffic Manager only works if your endpoints are reporting health correctly. Ensure your /health endpoint is lightweight and verifies the health of the application's dependencies (like databases).
3. Use Nested Profiles: For complex global architectures, you can nest Traffic Manager profiles. For example, use a "Performance" profile to route users to a region, and a "Priority" profile within that region to handle local failover.
4. Monitor the Traffic Manager: Use Azure Monitor to track metrics like Query Requests and Endpoint Status. Set up alerts for when an endpoint changes to a "Degraded" state.

Common Pitfalls

• Caching Issues: Remember that DNS is cached by ISPs and browsers. Even after you update your Traffic Manager configuration, users might continue to be routed to the old endpoint until their local DNS cache expires.
• Ignoring Endpoint Health: If your endpoint health check is too simplistic (e.g., just returning 200 OK without checking DB connectivity), Traffic Manager might send traffic to a "zombie" server that is technically up but functionally broken.
• Over-complication: Do not use complex routing methods if simple ones suffice. Every layer of logic increases the potential for misconfiguration.

💡 Pro-Tip: The "Failover" Trap

Many architects assume Traffic Manager will instantly route users away during a regional outage. While it is fast, remember that DNS propagation takes time. Always combine Traffic Manager with Azure Front Door or Application Gateway for sub-second failover capabilities if your SLA requires near-zero downtime.

---

Key Takeaways

• DNS-Based: Traffic Manager directs traffic at the DNS level, not the packet level.
• Method Selection: Choose the method based on business logic: Priority for DR, Performance for user experience, and Geographic for compliance.
• Health Probes: The accuracy of your routing is only as good as your health probes; ensure they are robust and represent true application health.
• TTL Balance: Find the "sweet spot" for TTL—too high and failover is slow; too low and you increase DNS overhead.