Skip to main content
In this lesson you’ll learn what Azure Traffic Manager is, when to use it, and the core features that enable global application delivery. Traffic Manager is a DNS-based traffic load balancer that directs client requests to the most appropriate service endpoint. By combining DNS redirection with built-in health probes, Traffic Manager improves application availability and performance for multi-region and global deployments. What you’ll learn in this lesson:
  • Real-world scenarios where Traffic Manager improves availability, performance, and compliance.
  • How Traffic Manager performs DNS-based redirection and relies on health probes to route traffic to healthy endpoints.
  • The available routing methods and when to use each (Priority, Weighted, Performance, Geographic).
  • Endpoint types Traffic Manager supports (Azure, external, nested).
  • How to create and configure a Traffic Manager profile in the Azure portal and via CLI.
  • How to configure and tune health probes to maintain high availability.
Key considerations:
  • Traffic Manager acts at the DNS layer — client behavior is influenced by DNS TTLs and client-side DNS caching.
  • Use routing method and probe settings together to balance failover speed, stability, and control.
Traffic Manager operates at the DNS layer—routing decisions are made by resolving the Traffic Manager DNS name to different endpoint IPs. This means changes (like DNS TTLs) affect how quickly client behavior shifts after configuration updates.

What Traffic Manager does (quick overview)

  • Routes users to the “best” endpoint based on your chosen routing method (latency, priority, weight, or geography).
  • Monitors endpoint health using configurable probes (HTTP/HTTPS/TCP).
  • Redirects traffic away from unhealthy endpoints automatically.
  • Supports Azure and non-Azure endpoints, plus nested profiles for complex topologies and hybrid scenarios.

Common scenarios (when to use Traffic Manager)

ScenarioWhy Traffic Manager helpsExample
Multi-region appsDirects users to the lowest-latency or nearest region to reduce response timesGlobal web application serving users from multiple continents
Disaster recovery / failoverProvides automatic DNS-level failover to healthy endpointsPrimary site outage: failover to secondary region
Gradual rollouts / A/B testingDistribute traffic across endpoints using weightsIncrementally route 10% of traffic to a new deployment
Data sovereignty / complianceRoute users by geography to meet legal requirementsDirect EU users to EU-hosted endpoints
Hybrid cloud / multi-cloudCombine Azure and external endpoints under a single DNS nameMix of Azure App Service and on-premise app endpoints

Traffic Manager routing methods

Routing methodBest use caseBehavior / Notes
PriorityFailover and disaster recoveryTraffic is sent to the highest-priority healthy endpoint. Use for active/passive setups.
WeightedGradual rollout and traffic distributionDistributes traffic across endpoints based on weight values. Good for canary releases.
PerformanceReduce latency for usersRoutes users to the endpoint with the lowest network latency. Relies on Azure latency measurements.
GeographicRegulatory / compliance routingRoutes users by geographic location (country/region) to enforce data residency or localization.

Endpoint types supported

Endpoint typeWhat it representsTypical use case
Azure endpointsApp Service, Virtual Machines, Cloud Services, Public IPsUse for services hosted in Azure regions
External endpointsNon-Azure public endpoints (HTTP/HTTPS/TCP)Integrate on-prem or other cloud providers
Nested profilesAnother Traffic Manager profileBuild hierarchical routing (e.g., region-level then global-level routing)

How Traffic Manager works (technical flow)

  1. Client resolves your Traffic Manager DNS name (e.g., myapp.trafficmanager.net).
  2. Traffic Manager applies the selected routing method and returns the IP address of the chosen endpoint.
  3. The client connects directly to that endpoint (Traffic Manager does not proxy application traffic).
  4. Traffic Manager continuously probes endpoints (HTTP/HTTPS/TCP) and updates DNS responses when endpoint health changes.
  5. DNS TTL values determine how quickly clients update cached responses after endpoint changes.

Creating and configuring a Traffic Manager profile

You can create and configure Traffic Manager in the Azure Portal, Azure CLI, or ARM templates. Below is a typical flow and an example CLI command. Steps in the Azure Portal:
  • Create a new Traffic Manager profile: choose a name and select the routing method.
  • Set the TTL (default is 30 seconds but choose based on desired failover speed vs DNS churn).
  • Add endpoints: select endpoint type, provide target (App Service, IP, FQDN) and set endpoint priority/weight/geolocation as required.
  • Configure health probes: protocol (HTTP/HTTPS/TCP), path (for HTTP/HTTPS), interval, timeout, and tolerated failures.
  • (Optional) Add nested profiles for multi-level routing.
Azure CLI example: create a simple Priority profile and add two endpoints
# Create Traffic Manager profile (Priority)
az network traffic-manager profile create \
  --name mytmprofile \
  --resource-group myResourceGroup \
  --routing-method Priority \
  --unique-dns-name mytmprofile-demo \
  --ttl 30

# Add primary Azure endpoint (App Service)
az network traffic-manager endpoint create \
  --name primary-endpoint \
  --profile-name mytmprofile \
  --resource-group myResourceGroup \
  --type azureEndpoints \
  --target-resource-id /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Web/sites/myapp-primary \
  --priority 1

# Add secondary (failover) endpoint
az network traffic-manager endpoint create \
  --name secondary-endpoint \
  --profile-name mytmprofile \
  --resource-group myResourceGroup \
  --type azureEndpoints \
  --target-resource-id /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Web/sites/myapp-secondary \
  --priority 2

Configuring and tuning health probes

Health probes determine endpoint health and directly affect failover behavior. Important probe settings:
  • Protocol: HTTP, HTTPS, or TCP (choose HTTP/HTTPS to validate application responses).
  • Path: For HTTP(S) probes, specify a lightweight path (e.g., /health or /status).
  • Interval: Frequency of probes (default often 30 seconds). Lower intervals detect failures faster but increase probe traffic.
  • Timeout: Time waited for probe response.
  • Tolerated failures / Unhealthy threshold: Number of consecutive probe failures before declaring an endpoint unhealthy.
Tuning recommendations:
  • Use an authenticated, minimal response health endpoint that returns consistent success codes.
  • If your app has short transient issues, increase tolerated failures to prevent flapping.
  • For rapid failover (strict SLA), lower TTL and probe interval—but balance against DNS and network costs.

Best practices

  • Ensure your health probe endpoint is lightweight and reliable (avoid heavy database operations).
  • Set an appropriate DNS TTL: short for fast failover, longer to reduce DNS queries.
  • Use Weighted routing for staged rollouts and Performance routing for global latency optimization.
  • Combine nested profiles and geographic routing for complex regulatory and resilience requirements.
  • Document and automate Traffic Manager configuration in IaC (ARM/Bicep/Terraform) for reproducibility.