Route traffic with Traffic Manager

Your app is deployed in two regions. Traffic spikes in one region, and users in the other region suffer slow responses — but you don't want to maintain a complex load balancer infrastructure. Azure Traffic Manager solves this by routing user traffic at the DNS level, directing requests to the healthiest or closest endpoint. In this lesson, you'll learn how to configure Traffic Manager to distribute traffic across multiple endpoints, ensuring high availability and performance.

The problem this lesson solves

Imagine you run a global e-commerce site. A sudden surge in one region can overwhelm a single deployment, causing downtime and lost revenue. Manually redirecting users or managing multiple DNS records is error-prone and slow. Traffic Manager provides a DNS-based traffic routing solution that automatically directs users to the most appropriate endpoint based on routing methods like priority, weighted, performance, or geographic. This means you can fail over to a secondary region instantly if one goes down, and you can balance load across regions without complex networking setups.

The pain: without Traffic Manager, you'd need to handle failover logic in your application or rely on a single region, risking availability. With Traffic Manager, you get a resilient, globally distributed front door for your services.

Core concept / mental model

Think of Traffic Manager as a smart DNS resolver. When a user types your domain (e.g., app.contoso.com), the DNS query hits Traffic Manager's DNS server, which uses the routing method yet configured to pick the best endpoint (e.g., a regional App Service or VM). Traffic Manager does not route the actual data — it only responds with the IP address of one of your endpoints. This is different from a load balancer, which sits in the data path and distributes each request.

Analogy

Imagine a call center with multiple offices. Callers dial one number (your Traffic Manager profile). The system (routing method) decides which office to connect them to based on criteria: the closest office (performance), the primary office unless busy (priority), or a percentage of calls to each (weighted). The caller then talks directly to that office — the call center doesn't stay on the line.

Key concepts

• Traffic Manager profile: The logical container that holds your routing method, endpoints, and DNS settings.
• Endpoint: A service that can receive traffic, like an Azure App Service, VM, or external URL.
• Routing method: The rule to select which endpoint gets the response (priority, weighted, performance, geographic, etc.).
• Health checks: Traffic Manager periodically probes endpoints to ensure they're alive; unhealthy endpoints are skipped.

How it works step by step

1. Create a Traffic Manager profile — Choose a routing method (e.g., performance). The profile gets a DNS name like myprofile.trafficmanager.net.
2. Add endpoints — Point each endpoint at your deployed service (e.g., an App Service in a region).
3. Configure health checks — Traffic Manager sends HTTP/HTTPS probes to each endpoint's health path (e.g., /health).
4. Set routing method preferences — For priority, assign order; for weighted, assign weights; for performance, location is determined automatically.
5. Update your DNS — Create a CNAME record from your custom domain to the Traffic Manager profile's DNS name.
6. Monitor and adjust — Use the Azure portal or CLI to see endpoint states and adjust weights or priorities as traffic patterns change.

The cause-effect chain: DNS query → Traffic Manager receives → checks health → applies routing method → returns IP of selected endpoint → user connects directly to that endpoint. If an endpoint fails health checks, Traffic Manager routes to the next best available endpoint.

Hands-on walkthrough

Let's set up Traffic Manager with two App Service endpoints using the Azure CLI. This example assumes you have two web apps deployed in different regions (e.g., East US and West Europe).

Step 1: Create the Traffic Manager profile

# Create a resource group if you don't have one
az group create --name tm-rg --location eastus

# Create the Traffic Manager profile (performance routing)
az network traffic-manager profile create \
  --name mytmprofile \
  --resource-group tm-rg \
  --routing-method Performance \
  --unique-dns-name mytmprofile \
  --ttl 30 \
  --monitor-protocol HTTPS \
  --monitor-port 443 \
  --monitor-path /

Step 2: Add App Service endpoints

# Replace with your actual web app resource IDs
az network traffic-manager endpoint create \
  --name app-east \
  --profile-name mytmprofile \
  --resource-group tm-rg \
  --type azureEndpoints \
  --target-resource-id /subscriptions/SUBSCRIPTION_ID/resourceGroups/myapp-rg/providers/Microsoft.Web/sites/app-east \
  --endpoint-status Enabled

az network traffic-manager endpoint create \
  --name app-west \
  --profile-name mytmprofile \
  --resource-group tm-rg \
  --type azureEndpoints \
  --target-resource-id /subscriptions/SUBSCRIPTION_ID/resourceGroups/myapp-rg/providers/Microsoft.Web/sites/app-west \
  --endpoint-status Enabled

Step 3: Test the routing

# Resolve the Traffic Manager DNS name
nslookup mytmprofile.trafficmanager.net

Expected output: a list of IP addresses depending on your location — you should see the endpoint IP closest to you. If you stop one endpoint (az network traffic-manager endpoint update --endpoint-status Disabled), the next query should return the other endpoint's IP after the TTL expires.

Step 4: Point your custom domain

In your DNS provider, create a CNAME record pointing app.contoso.com to mytmprofile.trafficmanager.net.

Pro tip: Use a TTL of 30–60 seconds during migrations to expedite failover, but increase to 300+ for production to reduce DNS lookup overhead.

Compare options / when to choose what

Traffic Manager is not the only routing tool in Azure. Here's how it compares to others:

When to choose what: - Use Traffic Manager for DNS-level failover across regions with minimal overhead — ideal for VMs, App Services, or external endpoints. - Use Front Door when you need HTTP-level routing (e.g., path-based), caching, and DDoS protection. - Use Load Balancer for distribution to a single region's VMs, especially for non-HTTP protocols. - Use Application Gateway for web apps with complex routing rules and SSL offloading.

Troubleshooting & edge cases

Here are common issues you might face and how to resolve them.

Problem: Traffic Manager always returns one endpoint even if unhealthy

• Cause: Health probe is misconfigured (wrong path, port, or protocol).
• Fix: Check the monitor-path and monitor-port in the profile. Ensure your endpoint responds with a 200 status on that path. For App Services, the default path / usually works, but if your app requires authentication, use a health endpoint like /health that returns 200 without auth.

Problem: DNS changes don't take effect quickly

• Cause: TTL is too long or local DNS resolvers cache the old record.
• Fix: Reduce TTL in profile, but remember this increases query volume. If you're testing, flush your local DNS or use nslookup against Azure DNS.

Problem: Endpoint shows as "Degraded" or "Offline"

• Cause: The endpoint is not accessible from Azure's probe IPs, or the health probe is blocked by a firewall or access restrictions.
• Fix: Ensure your app's firewall allows requests from Azure health probes (you can find probe IP ranges in the docs). Also check that the app isn't returning 4xx/5xx status codes.

Edge case: Weighted routing with zero weight

• If you set a weight to 0, that endpoint will not receive any traffic. This is useful for draining during maintenance. But make sure at least one endpoint has a positive weight, or you'll get a ServiceUnavailable error.

Edge case: Geographic routing and unknown location

• Geographic routing requires mapping IP ranges to regions. If a user's IP is not mapped (e.g., from a new ISP), Traffic Manager may fail. You can set a fallback endpoint or use a different routing method.

What you learned & what's next

You now understand how to route traffic with Traffic Manager: you learned the core concept of DNS-level routing, how to configure a profile with multiple endpoints, and how different routing methods (priority, weighted, performance, geographic) serve different needs. You also practiced creating a profile and adding App Service endpoints using the CLI, and you learned troubleshooting techniques for common probe and DNS issues.

In the next lesson, you'll expand on this by integrating Traffic Manager with Azure Front Door to build a more comprehensive global web access layer with caching and WAF protection. This will prepare you to design robust, globally distributed architectures. Continue with the next lesson in this Azure Tutorial track.