Key Concepts
Traffic Manager uses a parent profile that can contain multiple endpoints or nested Traffic Manager profiles (child profiles). Each profile — parent or nested — defines its own routing method. This allows flexible scenarios such as region-based failover or combining multiple routing strategies (for example, a parent profile using Performance routing and a child profile using Priority routing).- A Traffic Manager profile has a globally unique DNS name (the profile’s FQDN).
- Traffic Manager is a global resource; the region selection only stores metadata.
Nested profiles can require a minimum number of healthy child endpoints (minChildEndpoints). If the nested profile’s healthy-child count is below this minimum, the parent will not direct traffic to that child profile.
Endpoint types
Use the table to quickly compare Traffic Manager endpoint types and common use cases:| Endpoint Type | Use Case | Example |
|---|---|---|
| Azure endpoint | Services running in Azure (App Services, Cloud Services, Public IPs) — typical Azure-only balancing | App Service or VM in your subscription |
| External endpoint | Services outside Azure (on-premises or other clouds) referenced by IP or FQDN — hybrid/migration | On-premises web server or third-party cloud VM |
| Nested endpoint | References to other Traffic Manager profiles — aggregation and complex routing | Parent profile delegates to region-specific child profiles |
Routing methods
Choose a routing method based on your objectives (latency, failover, traffic weighting, geo-control). Common choices:| Routing Method | Behavior | When to use |
|---|---|---|
| Performance (latency) | Routes to the endpoint with lowest latency for the client | Global performance optimization |
| Priority | Sends all traffic to highest-priority healthy endpoint; failover to next | Failover / primary-secondary setups |
| Weighted | Distributes traffic according to weights you set | Gradual migrations, canary releases |
| Geographic | Routes users based on source geography | Legal or regulatory geofencing |
| Multi-value | Returns multiple healthy IPs | Clients that can handle multiple IPs for client-side load balancing |
| Subnet | Routes by client subnet mapping | Map specific subnets to specific backends (e.g., corporate vs public) |
Creating and configuring a Traffic Manager profile (portal walkthrough)
To create a profile you must:- Provide a globally unique profile name (this becomes the Traffic Manager FQDN).
- Select a routing method.
- Choose subscription and resource group (Traffic Manager is global — location field stores metadata only).
- Create the profile and then configure monitoring and endpoints.
Health probe options
- Protocol: HTTP, HTTPS, or TCP.
- Port: TCP port to probe.
- Path: (HTTP/HTTPS) where the probe requests will be directed (e.g., /health).
- Expected HTTP status codes.
- Probe interval and timeout.
- Tolerated failures (how many failures before endpoint marked unhealthy).
- DNS TTL for the returned CNAME.
- Optionally: custom request headers for HTTP/HTTPS probes (in some configurations).
Portal example: App Services attached to Traffic Manager
In the demo, three App Services were deployed in different regions (East US, Southeast Asia, West Europe). Each app has a customized landing page so you can identify which region served the response.
Adding endpoints
When adding endpoints:- Choose endpoint type (Azure, External, or Nested).
- For Azure endpoints, select the target resource (e.g., App Service).
- Enable monitoring (recommended).
- Optionally enable “Always serve traffic” to override probe results (use with caution).
Do not enable “Always serve traffic” unless you understand the implications: it forces Traffic Manager to send traffic to an endpoint even if probes mark it unhealthy. Use it for temporary maintenance overrides only.
Host header behavior with App Service (common pitfall)
When you visit the Traffic Manager FQDN directly in a browser, the browser sends the Traffic Manager domain as the Host header. App Service validates Host headers and only serves requests for hostnames configured on the app. If the app does not have the Traffic Manager domain configured as a custom domain, you’ll get a 404.
- Use a custom domain (e.g., www.example.com) for the Traffic Manager profile.
- Map the custom domain to the Traffic Manager profile (DNS CNAME).
- Add and verify the same custom domain on each App Service or backend endpoint so the Host header is accepted.
If you cannot configure a custom domain for testing, simulate the proper Host header with curl or Postman. This confirms DNS and routing work even if the browser shows 404 due to Host header mismatch.
Testing and diagnostics
Use nslookup to see the CNAME targets Traffic Manager returns (these vary by client location when using Performance routing): Example resolving to a Southeast Asia backend:Summary
- Azure Traffic Manager provides global DNS-based traffic routing with multiple routing methods and endpoint types (Azure, External, Nested).
- Nested profiles and minChildEndpoints enable advanced topologies and failover controls.
- Configure health probes carefully (protocol, path, expected codes, intervals, tolerated failures).
- In production, use a verified custom domain mapped to the Traffic Manager profile and added to each backend so Host headers are accepted.
- For testing without a custom domain, set the Host header manually (curl/Postman) to the backend app’s azurewebsites.net hostname.
Links and references
- Azure Traffic Manager documentation
- Traffic Manager routing methods
- Azure App Service custom domains