Introduction

• Common scenarios where Traffic Manager improves availability and performance (global failover, performance optimization, compliance-based routing).
• How DNS resolution and health probes determine where traffic goes.
• The routing methods Traffic Manager supports and when to use each.
• Types of endpoints Traffic Manager manages.
• Key configuration steps and operational controls, including probe tuning and DNS considerations.
• When to choose Traffic Manager vs. application-layer load balancers (e.g., Azure Front Door or Application Gateway).

​

How Traffic Manager Works (high level)

• Client resolves your application’s Traffic Manager profile DNS name (e.g., myapp.trafficmanager.net).
• Traffic Manager evaluates endpoint health via configured probes (HTTP/HTTPS/TCP).
• Based on routing method and probe results, Traffic Manager returns the DNS record that points the client to an endpoint (or a nested profile).
• Because Traffic Manager operates at the DNS layer, the client then connects directly to the endpoint returned by DNS.

• Failover and routing decisions are fast in DNS responses but subject to client DNS caching and TTL.
• Traffic Manager does not terminate or proxy traffic; it only guides clients to endpoints.

​

When to Use Traffic Manager

• Global failover / disaster recovery (priority routing).
• Performance optimization for globally distributed users (latency/performance routing).
• Gradual rollouts and traffic distribution (weighted routing).
• Data sovereignty or localization (geographic routing).
• Combining multiple Traffic Manager profiles for hierarchical routing (nested profiles).

​

Routing Methods

• Create a profile (Priority):

az network traffic-manager profile create \
  --name my-tm-profile \
  --resource-group my-rg \
  --routing-method Priority \
  --unique-dns-name myapp

• Add an endpoint:

az network traffic-manager endpoint create \
  --name my-endpoint \
  --profile-name my-tm-profile \
  --resource-group my-rg \
  --type azureEndpoints \
  --target-resource-id "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-rg/providers/Microsoft.Web/sites/myapp" \
  --priority 1

​

Endpoint Types

​

Health Checks and Probe Configuration

• Protocol: HTTP, HTTPS, or TCP.
• Path: For HTTP/HTTPS, the probe path (e.g., /health).
• Interval: Time between probes (seconds).
• Timeout: How long to wait for probe response (seconds).
• Tolerated failures: Number of consecutive failures before marking an endpoint unhealthy.

• Point probes at a lightweight, stable health endpoint (e.g., /healthz).
• For global failover, prefer shorter intervals and conservative tolerated failures to fail over quickly but avoid transient flaps.
• For performance-based routing, ensure probes truly reflect end-user experience (latency vs application readiness).

az network traffic-manager profile update \
  --name my-tm-profile \
  --resource-group my-rg \
  --status Enabled \
  --interval 30 \
  --timeout 10 \
  --max-failures 3 \
  --protocol HTTP \
  --path /healthz

​

DNS Considerations

• TTL (time-to-live) controls how long clients cache DNS answers. Shorter TTLs make failover faster but increase DNS query volume.
• DNS caching by resolvers and clients can delay failover beyond Traffic Manager decisions.
• Use an appropriate TTL for your SLA and expected failover speed; common values are 30–300 seconds depending on trade-offs.

• Balance TTL and TTL-driven costs: very low TTLs increase DNS traffic.
• Consider nested profiles to create complex routing with clearer DNS names and TTL strategies.
• Monitor DNS resolution times from representative regions to validate behavior.

​

Configuration Checklist (Portal and CLI)

1. Create a Traffic Manager profile.
   • Choose a unique DNS name (e.g., myapp.trafficmanager.net).
   • Select a routing method.
2. Add endpoints (Azure, External, or Nested).
3. Configure probes to validate endpoint health.
4. Set TTL and DNS retry strategies that meet your failover SLAs.
5. Test failover scenarios by simulating endpoint failures and verifying DNS resolution behavior.
6. Monitor — use Azure Monitor and Traffic Manager metrics to track endpoint health and DNS query patterns.

• Navigate to Traffic Manager profiles > + Create.
• Provide subscription, resource group, profile name, and routing method.
• After creation, select Endpoints > + Add to register endpoints.
• Configure Monitoring settings (protocol, path, interval, timeout).

​

Limitations and When to Choose Other Services

• Traffic Manager only operates at DNS level (no TLS termination, no application-layer routing).
• Client DNS caching can delay failover; application-layer services provide faster, proxy-based failover.
• For SSL offload, path-based routing, WAF, or edge caching, use Azure Front Door or Application Gateway.

• You need simple, scalable DNS-based routing across regions.
• Your endpoints can be publicly resolved and handled by clients directly.

• You need advanced HTTP features (SSL termination, path-based routing, WAF).
• You require edge caching, rewrite, or full proxy behavior.

​

Examples and Scenarios

• Global active/passive: Use Priority routing with primary endpoint priority=1 and backups priority=2,3…
• Blue/green or canary releases: Use Weighted routing and adjust weights to shift traffic gradually.
• Low-latency region selection: Use Performance routing to direct users to the lowest-latency endpoint.
• Regulatory compliance by region: Use Geographic routing to bind users to local endpoints.

​

Links and References

• Azure Traffic Manager documentation
• Azure CLI Traffic Manager commands
• Azure Front Door vs. Traffic Manager