Azure Traffic Manager

Azure Traffic Manager is a DNS-based traffic load balancer that distributes incoming user traffic across multiple endpoints (such as Azure App Services, VMs, or external websites) hosted in different Azure regions or even on-premises. The primary business problem it solves is ensuring high availability and optimal performance for global applications. For example, a multinational e-commerce site needs to serve users from North America, Europe, and Asia with low latency and without downtime. Without Traffic Manager, all users would hit a single region, causing high latency for distant users and a single point of failure. Traffic Manager allows the application to be deployed in multiple regions and directs each user to the best region based on criteria like lowest latency, geographic proximity, or a weighted distribution.

Traffic Manager operates at the DNS level. Here's the step-by-step flow:

Components: - Traffic Manager profile: A logical container that holds the DNS settings, routing method, endpoint monitoring configuration, and endpoints. - Endpoints: The destinations for traffic, which can be Azure endpoints (App Service, Cloud Service, VMs, etc.), external endpoints (on-premises or other cloud), or nested endpoints (other Traffic Manager profiles). - Routing methods: The algorithm used to select which endpoint to return. There are six methods: Performance, Priority, Weighted, Geographic, Multivalue, and Subnet. - Health probes: Configuration for how often and how to check endpoint health (protocol, port, path, interval, timeout, and number of failures).

Tiers and Pricing: Traffic Manager is a single service without tiers. Pricing is based on:

On-premises, traffic distribution often uses hardware load balancers (e.g., F5, Citrix ADC) or DNS round-robin. Hardware load balancers are expensive, require maintenance, and are limited to a single data center. DNS round-robin is simple but lacks health checks and intelligent routing. Traffic Manager is a cloud-native, global DNS load balancer that provides health monitoring, multiple routing algorithms, and integration with Azure services, all without managing physical infrastructure.

Portal: Navigate to 'Traffic Manager profiles' in the Azure portal. You can create a profile, add endpoints, configure routing method, and set up health probes via a graphical interface.

CLI: Use the az network traffic-manager commands. For example:

# Create a Traffic Manager profile
az network traffic-manager profile create \
    --resource-group myResourceGroup \
    --name myTMProfile \
    --routing-method Performance \
    --unique-dns-name myapp \
    --monitor-protocol HTTPS \
    --monitor-port 443 \
    --monitor-path "/health"

# Add an endpoint
az network traffic-manager endpoint create \
    --resource-group myResourceGroup \
    --profile-name myTMProfile \
    --name endpoint1 \
    --type azureEndpoints \
    --target-resource-id /subscriptions/.../.../sites/myWebApp

PowerShell: Use the New-AzTrafficManagerProfile and Add-AzTrafficManagerEndpointConfig cmdlets.

A large e-commerce company, 'ShopGlobal', serves customers worldwide. They deploy their web application in three Azure regions: US East, West Europe, and Southeast Asia. They use Traffic Manager with Performance routing to automatically direct users to the region with the lowest latency. The team configures health probes to check the '/health' endpoint every 30 seconds. During a regional outage in US East, Traffic Manager detects the failure after three consecutive probe failures (90 seconds) and stops returning that endpoint. Users from North America are then routed to West Europe, which has the next best latency. The failover time is acceptable for the business, but they consider reducing the probe interval to 10 seconds for faster detection. Cost: approximately $50/month for 10 million DNS queries and 3 endpoints. A common mistake is not setting up health probes correctly—if the health endpoint doesn't return 200, Traffic Manager marks the endpoint as degraded even if the app is working, causing unnecessary failover.

A bank, 'SecureBank', uses Traffic Manager with Priority routing for disaster recovery. The primary site is in US East (priority 1) and the secondary is in US West (priority 2). All traffic goes to the primary unless it fails. The bank configures health probes with TCP on port 443 to check if the HTTPS service is listening. During a planned maintenance, they manually disable the primary endpoint in the portal, causing Traffic Manager to route all traffic to the secondary. This allows zero-downtime maintenance. The team also uses nested Traffic Manager profiles to combine geographic routing for the primary site and priority for failover. A common pitfall is forgetting to update the DNS TTL—if set too high (e.g., 3600 seconds), users may still be directed to the failed primary for up to an hour. The bank sets TTL to 60 seconds for faster propagation.

A media company, 'StreamFast', uses Traffic Manager with Weighted routing to gradually roll out a new CDN provider. They have two endpoints: 'existing-cdn' with weight 90 and 'new-cdn' with weight 10. Traffic Manager distributes 10% of traffic to the new provider. They monitor performance and error rates; if the new provider performs well, they increase its weight gradually. This approach allows safe migration without impacting most users. A common issue is that weighted routing is based on DNS queries, not user sessions—if a user's DNS resolver caches the response, that user will stick to one endpoint for the TTL duration, which can skew the distribution. The team mitigates by setting a low TTL (60 seconds) and ensuring the resolver respects it.