Apple Podcasts 
Spotify 
Youtube Music 
Spreaker 
Podchaser 
Amazon Music Azure Traffic Manager - Simply Explained
Azure Traffic Manager is Microsoft's DNS-based global traffic routing service that directs users to the best available application endpoint based on performance, geography, priority, or other routing rules. Instead of routing traffic itself, Traffic Manager uses intelligent DNS responses to improve application availability, reduce latency, and automatically fail over to healthy endpoints when outages occur.
In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Azure Traffic Manager in simple terms and shows how it helps organizations build highly available, globally distributed applications. You'll learn how DNS-based routing works, why Traffic Manager is different from traditional load balancers, and when it's the right solution for multi-region deployments.
The episode covers key concepts including Traffic Manager profiles, endpoints, health checks, DNS routing, failover, and the different routing methods such as Priority, Performance, Geographic, Weighted, Subnet, and MultiValue. It also explains how Traffic Manager integrates with Azure App Service, Virtual Machines, Azure Load Balancer, Azure Front Door, and hybrid environments that include both Azure and on-premises applications.
You'll also discover the differences between Azure Traffic Manager and services like Azure Front Door and Azure Load Balancer. While Load Balancer distributes traffic within a region and Front Door acts as a global application delivery network, Traffic Manager operates at the DNS layer to route users to the most appropriate endpoint across regions. Understanding these differences is essential for designing resilient and high-performing cloud architectures.
Quick answer: Azure Traffic Manager is covered in this M365 FM episode with a practical focus on what it is, how it works, and the decisions that matter for architecture, adoption, security, governance, or day-to-day operations.
Imagine you’re trying to access an application from halfway around the world. You want that experience to be smooth and fast, right? That’s where Azure Traffic Manager steps in. This service optimizes application performance and enhances business continuity by managing user traffic effectively. With Azure Traffic Manager, you can ensure seamless connectivity to your applications, no matter where your users are located. It intelligently routes traffic across the network, helping you deliver the best possible experience to your customers.
Key Takeaways
- Azure Traffic Manager optimizes application performance by routing user traffic to the best endpoints based on latency and health.
- It ensures high availability by automatically rerouting traffic to healthy endpoints during outages, minimizing downtime.
- The service supports various routing methods, including Performance and Geographic routing, to enhance user experience.
- Azure Traffic Manager can manage traffic for both Azure and non-Azure endpoints, providing flexibility in cloud services.
- Setting up Azure Traffic Manager is straightforward and can be done in just a few minutes through the Azure Portal.
- Regular health monitoring of endpoints ensures that users are always directed to the most reliable servers.
- Implementing best practices, like manual failover and careful health check settings, can improve the effectiveness of Azure Traffic Manager.
- Using Azure Traffic Manager can significantly enhance global reach, allowing businesses to serve users efficiently from multiple regions.
What Is Azure Traffic Manager?
Azure Traffic Manager is a powerful DNS-based traffic load balancer that distributes traffic to public-facing applications across global Azure regions. Its primary purpose is to ensure high availability and quick responsiveness for your applications. By intelligently routing user traffic, Azure Traffic Manager optimizes application performance, making it an essential tool for businesses operating in today's digital landscape.
Key Features
Azure Traffic Manager comes packed with features that set it apart from other traffic management solutions. Here’s a quick look at some of its standout capabilities:
| Feature | Azure Traffic Manager | Azure Front Door | Azure Load Balancer |
|---|---|---|---|
| DNS-based traffic load balancing | Yes | Yes | No |
| Endpoint monitoring | Yes | Yes | No |
| Automatic failover | Yes | Yes | No |
| Low latency routing | Yes | Yes | Yes |
| Support for non-Azure endpoints | Yes | No | No |
| Traffic routing methods | Yes | Yes | Limited |
| SSL termination | No | Yes | No |
| Caching | No | Yes | No |
| Optimized for TCP/UDP traffic | No | No | Yes |
| Global routing | Yes | Yes | No |
With features like continuous monitoring of endpoints, Azure Traffic Manager ensures that your applications remain available even during outages. It automatically reroutes traffic to healthy endpoints, minimizing downtime and enhancing user experience.
How It Works
So, how does Azure Traffic Manager actually route user traffic? It uses various routing methods to direct users to the best application endpoint based on specific criteria. For instance, the Performance routing method prioritizes routing based on network latency rather than just geographic proximity. This means it assesses the round-trip time between different IP address ranges and Azure datacenters, directing users to the endpoint with the lowest latency. By regularly updating its Internet Latency Table, Azure Traffic Manager adapts to changes in network conditions, ensuring optimal routing for your users.
The architecture of Azure Traffic Manager includes several key components:
- Traffic Manager profile: This is the main resource that defines your routing method, DNS name, and monitoring settings.
- DNS name: This is the domain through which users access your applications, typically formatted as
yourprofile.trafficmanager.net. - Endpoints: These are the destinations that Traffic Manager can return in DNS responses.
- Monitoring configuration: This includes settings like protocol, port, path, probe interval, timeout, and tolerated failures.
- Routing method configuration: This allows you to set weights, priorities, geographic mappings, and subnet mappings.
By leveraging these components, Azure Traffic Manager provides a robust solution for managing connectivity across your cloud services, ensuring that your applications perform optimally no matter where your users are located.
Azure Networking Services Overview
When you think about Azure, you might picture cloud storage or virtual machines. But Azure offers a whole suite of networking services that enhance your applications' performance and connectivity. These services work together to create a robust network environment, ensuring that your applications run smoothly and efficiently.
Here’s a quick overview of some key Azure networking services:
- Virtual networks
- Dedicated connections
- Gateways
- Traffic management services
- Load balancing
- DNS hosting
- Network protection services
These services provide the backbone for your applications, allowing them to communicate effectively and securely. For instance, the Azure Virtual Network lets you create isolated networks in the cloud, giving you control over your IP address range and subnets. This flexibility is crucial for managing resources and ensuring secure connectivity.
Now, let’s talk about how Azure Traffic Manager fits into this ecosystem. Think of it as the traffic cop for your applications. It directs user requests to the most appropriate endpoints based on various factors like performance and availability. This means that when users access your application, they get routed to the nearest and healthiest server, ensuring a fast and reliable experience.
Here’s how Azure Traffic Manager integrates with other Azure services:
| Azure Service Type | Description |
|---|---|
| PaaS cloud services | Azure Traffic Manager can route traffic to Platform as a Service (PaaS) cloud services. |
| Web Apps | It supports Azure Web Apps, allowing for optimized traffic distribution to web applications. |
| Web App Slots | Traffic Manager can also manage traffic to different slots of a web app for testing purposes. |
| Public IP Address resources | These can be linked to VMs and must have a DNS name assigned to be utilized in Traffic Manager. |
With features like priority routing and performance routing, Azure Traffic Manager enhances your networking capabilities. It ensures that your applications remain available and responsive, even during peak traffic times or outages. By leveraging these networking services, you can build a resilient architecture that meets your business needs.
Benefits of Azure Traffic Manager
When you choose Azure Traffic Manager, you unlock a range of benefits that can significantly enhance your applications. Let’s explore how this service can improve performance, availability, and global reach.
Improved Performance
Azure Traffic Manager boosts your application's performance by ensuring that users connect to the fastest and most reliable endpoints. By utilizing various routing methods, it directs traffic based on real-time conditions. For example, a global e-commerce platform used geographic routing to send users to the nearest data center. This approach minimized latency and ensured fast response times, especially during peak events like Black Friday.
Here are some key ways Azure Traffic Manager enhances performance:
- Performance Routing: This method connects users to the server with the lowest latency, crucial for global applications.
- Optimized Load Balancing: It distributes traffic evenly, preventing server overload and maintaining optimal performance.
- Enhanced Reliability: By routing users to healthy servers, Azure Traffic Manager ensures that applications remain accessible even if one server fails.
| Evidence Type | Description |
|---|---|
| Enhanced Reliability and Availability | Ensures applications remain accessible by routing users to healthy servers, even if one server fails. |
| Improved Performance and Responsiveness | Directs users to the closest and fastest server, minimizing latency for a better user experience. |
| Optimized Load Balancing | Distributes traffic evenly to prevent server overload, maintaining optimal performance. |
| Performance Routing | Uses DNS to connect users to the server with the lowest latency, crucial for global applications. |
Enhanced Availability
Availability is critical for any application, and Azure Traffic Manager excels in this area. It operates across multiple availability zones and regions, ensuring resilience during outages. When an endpoint becomes unhealthy, Traffic Manager automatically reroutes traffic to healthy ones, minimizing downtime.
Here’s how Azure Traffic Manager enhances availability:
- Health Monitoring: It continuously checks the status of endpoints. If it detects an issue, it quickly redirects traffic to a backup endpoint.
- Failover Scenarios: For instance, a company can set up a Traffic Manager profile with a primary endpoint and a failover endpoint. If the primary fails, Traffic Manager seamlessly switches to the backup, ensuring business continuity.
- Regular Testing: By regularly testing failover behavior, you can ensure that routing works as expected during outages.
| Evidence Description | Source Link |
|---|---|
| Azure Traffic Manager operates across multiple availability zones and regions, ensuring resilience during outages. | Reliability in Azure Traffic Manager |
| It monitors the health of endpoints and routes traffic to healthy ones, avoiding unhealthy endpoints. | Reliability in Azure Traffic Manager |
| Configuring multiple endpoints across regions allows automatic routing to healthy regions during outages. | Secure your Azure Traffic Manager deployment |
| Regular testing of failover behavior ensures that the routing works as expected during outages. | Secure your Azure Traffic Manager deployment |
Global Reach
In today’s interconnected world, having a global reach is essential for businesses. Azure Traffic Manager allows you to distribute network traffic across multiple regions, ensuring that users from different parts of the world experience optimal performance.
Here’s how Azure Traffic Manager supports global reach:
- Geographic Routing: This feature directs users to the nearest data center, reducing latency and improving response times.
- Multi-Regional Applications: You can deploy applications in various regions and use Traffic Manager to manage traffic effectively, ensuring users always connect to the best endpoint.
- Support for Non-Azure Endpoints: Azure Traffic Manager can route traffic to endpoints outside of Azure, giving you flexibility in your cloud services.
By leveraging Azure Traffic Manager, you can build a robust network that enhances connectivity and performance for users worldwide.
Use Cases for Azure Traffic Manager
Azure Traffic Manager is a versatile tool that fits various scenarios in today's cloud-driven world. Let’s explore some common use cases where this service shines.
Multi-Region Applications
If your business operates globally, you need to ensure that users access your applications quickly and reliably. Azure Traffic Manager excels in managing multi-region applications. Here’s how it helps:
- It directs global traffic to ensure users are routed to the nearest and most responsive region.
- When a region goes down, it handles failover by rerouting traffic to operational regions.
- Performance routing sends users to the region with the lowest latency, enhancing user experience.
By combining Azure Traffic Manager with other Azure services like Azure Firewall and Azure Application Gateway, you can create a robust multi-region application architecture. This setup ensures high availability and security for your global applications. Plus, DNS-based global load balancing allows you to reach users across different geographical locations.
Disaster Recovery Solutions
Disaster recovery is crucial for maintaining business continuity. Azure Traffic Manager provides several strategies to ensure your applications remain available during outages. Here are some effective methods:
- Performance-based routing directs traffic to the region with the lowest network latency.
- Weighted routing splits traffic between endpoints based on assigned weights, allowing for controlled rollouts.
- Priority routing sets a primary and backup region, making it ideal for failover scenarios.
- Geographic routing ensures traffic stays within specific countries or regions, which can be vital for compliance.
- Multivalue routing returns multiple healthy endpoints for redundancy.
With features like these, you can minimize downtime and ensure that your applications remain accessible, even during unexpected events.
Load Balancing Strategies
When it comes to load balancing, Azure Traffic Manager offers unique advantages compared to traditional load balancers. Here’s a quick comparison:
| Load Balancer Type | Description | Key Characteristics |
|---|---|---|
| Azure Traffic Manager | A DNS-based load balancer that distributes traffic globally. | Operates at the domain level; slower failover due to DNS caching and TTL issues. |
| Traditional Load Balancers | Can operate at various layers and handle traffic directly. | Typically faster failover and can manage traffic at different network layers. |
By utilizing Azure Traffic Manager, you can optimize your load balancing and content delivery services. This ensures that your applications perform well under varying traffic conditions, providing a seamless experience for users.
With Azure Traffic Manager, you can enhance your connectivity, improve application performance, and ensure high availability across your network. Whether you’re managing multi-region applications, planning disaster recovery, or implementing load balancing strategies, this service is a powerful ally in your cloud journey.
Implementing Azure Traffic Manager
Setting up Azure Traffic Manager is straightforward, and following the right steps will help you get it running smoothly. Here’s how you can configure it:
Configuration Steps
- Log in to Azure Portal: Make sure you have an active subscription.
- Create a Traffic Manager profile: Select Create a resource > Networking > Traffic Manager profile.
- Enter the required settings:
- Name: Choose a unique name for your profile.
- Routing method: Select your preferred method, like Priority.
- Subscription: Pick the relevant subscription.
- Resource group: Select an existing one or create a new one.
- Location: This is for the resource group and doesn’t affect the Traffic Manager profile.
- Finalize the profile: Click Create to complete the setup.
By following these steps, you’ll have Azure Traffic Manager configured and ready to optimize your application’s performance.
Best Practices
To make the most of Azure Traffic Manager, consider these best practices:
| Best Practice | Description |
|---|---|
| Manual Failover | For global workloads, use manual failover with weighted routing for better control over health validation across geographies. |
| Avoid Automatic Failover | Don’t configure the primary Traffic Manager instance for automatic failover. This ensures accurate health checks. |
| Use BYO Certificates | Migrate to bring-your-own (BYO) certificates for consistent TLS certificate management across different ingress paths. |
Additionally, be mindful of common mistakes when configuring Azure Traffic Manager. For instance, misunderstanding DNS Time-to-Live (TTL) values can lead to prolonged traffic to failed endpoints. Clients cache DNS responses based on TTL settings, so high values can slow down failover response times during outages. Also, be cautious with health check settings; configuring them too aggressively may cause healthy endpoints to be marked as degraded.
For monitoring your Traffic Manager performance, consider using tools like Applications Manager, which provides insights into performance and availability. Other options include WebSitePulse and Pingdom, which measure DNS resolution time and other performance statistics.
Lastly, keep security in mind. Enable logging for security investigations, as the service produces resource logs that can provide enhanced metrics. You can configure these logs to send them to your own data sink, like a storage account or log analytics workspace.
By following these configuration steps and best practices, you can ensure that Azure Traffic Manager enhances your applications' connectivity and performance effectively.
In summary, Azure Traffic Manager plays a crucial role in enhancing your application's performance and availability. By intelligently routing traffic, it ensures users connect to the best endpoints, minimizing latency and downtime. Here are some key takeaways:
- Azure Traffic Manager and Front Door work together to balance traffic globally, ensuring high availability.
- It supports failover strategies, keeping your applications running smoothly even during outages.
- Priority-based routing directs traffic to the healthiest regions, boosting reliability.
Consider implementing Azure Traffic Manager in your applications to enjoy these benefits and create a seamless experience for your users! 🌍
FAQ
What is Azure Traffic Manager used for?
Azure Traffic Manager helps you manage user traffic across multiple application endpoints. It optimizes performance and ensures high availability by routing users to the best endpoint based on latency, health, and geographic location.
How does Azure Traffic Manager improve application performance?
It routes users to the closest and healthiest endpoints, reducing latency. By using various routing methods, it ensures that users experience fast response times, even during peak traffic.
Can I use Azure Traffic Manager with non-Azure services?
Yes! Azure Traffic Manager can route traffic to both Azure and non-Azure endpoints. This flexibility allows you to manage traffic across different cloud services seamlessly.
How do I monitor the health of my endpoints?
Azure Traffic Manager continuously monitors your endpoints using health probes. You can configure these probes to check the status of your applications and ensure traffic is only routed to healthy endpoints.
What routing methods does Azure Traffic Manager offer?
Azure Traffic Manager provides six routing methods: Priority, Performance, Weighted, Geographic, Multi-value, and Subnet Routing. Each method serves different needs, allowing you to tailor traffic management to your requirements.
Is there a cost associated with using Azure Traffic Manager?
Yes, Azure Traffic Manager has a pricing model based on the number of DNS queries and the number of endpoints monitored. You can check the Azure pricing page for detailed information.
How quickly can I set up Azure Traffic Manager?
You can set up Azure Traffic Manager in just a few minutes through the Azure Portal. Follow the configuration steps, and you'll be ready to optimize your application traffic in no time!
Can I use Azure Traffic Manager for disaster recovery?
Absolutely! Azure Traffic Manager supports disaster recovery by allowing you to set up failover endpoints. If your primary endpoint fails, it automatically redirects traffic to a backup, ensuring business continuity.
🎧 Listen to this episode
Want a practical explanation of Azure Traffic Manager? This episode breaks down the topic in clear language and shows why it matters for Microsoft 365, Azure, Power Platform, security, AI, and modern work.
Listen to this episode if you want to:
- Understand the key concepts behind Azure Traffic Manager
- See how it fits into the wider Microsoft technology ecosystem
- Learn where it can create practical value for your organization
You may also enjoy these related M365 FM episodes:
Discover more practical Microsoft conversations on M365 FM.
Last reviewed: July 2026.
Who Should Listen
This episode is for Microsoft 365 administrators, architects, IT leaders, and practitioners who need a practical understanding of Azure Traffic Manager before planning, implementing, or supporting it.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:02,640
Welcome to another episode of Microsoft Knowledge Nuggets,
2
00:00:02,640 --> 00:00:04,320
I'm your host, Mirko Peters.
3
00:00:04,320 --> 00:00:06,680
Today's topic, Azure Traffic Manager.
4
00:00:06,680 --> 00:00:08,040
Imagine you've built a web app
5
00:00:08,040 --> 00:00:10,240
that people all over the world want to use.
6
00:00:10,240 --> 00:00:11,960
Users in Tokyo, London, São Paulo,
7
00:00:11,960 --> 00:00:14,520
they're all trying to reach your app at the same time.
8
00:00:14,520 --> 00:00:15,640
But here's the problem.
9
00:00:15,640 --> 00:00:17,920
Every single one of those users is hitting a server
10
00:00:17,920 --> 00:00:19,680
in one region, let's say Virginia.
11
00:00:19,680 --> 00:00:22,960
The user in Tokyo waits over 200 milliseconds per request
12
00:00:22,960 --> 00:00:25,640
and the user in São Paulo gets an even worse experience.
13
00:00:25,640 --> 00:00:27,800
And if that Virginia data center goes down,
14
00:00:27,800 --> 00:00:30,560
a power failure, a network cut, something unexpected,
15
00:00:30,560 --> 00:00:32,160
your entire app goes offline.
16
00:00:32,160 --> 00:00:34,240
Every user everywhere, that's a single point of failure
17
00:00:34,240 --> 00:00:35,360
and it's a big problem.
18
00:00:35,360 --> 00:00:36,840
So what if you could route each user
19
00:00:36,840 --> 00:00:39,840
to their closest, fastest, healthier server automatically?
20
00:00:39,840 --> 00:00:41,560
What if a user in Tokyo got served
21
00:00:41,560 --> 00:00:43,240
from a data center in Japan?
22
00:00:43,240 --> 00:00:44,600
A user in London from Ireland,
23
00:00:44,600 --> 00:00:45,920
and if one region went down,
24
00:00:45,920 --> 00:00:47,920
the traffic just shifted somewhere else
25
00:00:47,920 --> 00:00:49,120
without you doing anything?
26
00:00:49,120 --> 00:00:51,160
That's exactly what Azure Traffic Manager does
27
00:00:51,160 --> 00:00:52,840
and it does it at the DNS level,
28
00:00:52,840 --> 00:00:54,800
which means it's simpler than you think.
29
00:00:54,800 --> 00:00:55,800
By the end of this episode,
30
00:00:55,800 --> 00:00:58,560
you'll understand what Traffic Manager actually is,
31
00:00:58,560 --> 00:01:00,160
how its six routing methods work
32
00:01:00,160 --> 00:01:01,480
and when you'd use each one.
33
00:01:01,480 --> 00:01:03,480
Grab your coffee and let's dive in.
34
00:01:03,480 --> 00:01:05,160
Why global traffic routing matters?
35
00:01:05,160 --> 00:01:06,360
Let's break it down.
36
00:01:06,360 --> 00:01:07,800
Most people hear load balancing
37
00:01:07,800 --> 00:01:09,920
and think of a single server distributing traffic
38
00:01:09,920 --> 00:01:12,200
across a few machines inside one data center.
39
00:01:12,200 --> 00:01:13,480
That's Azure Load Balancer
40
00:01:13,480 --> 00:01:15,120
and it works great for a single region.
41
00:01:15,120 --> 00:01:18,000
But what happens when your users are spread across continents?
42
00:01:18,000 --> 00:01:20,480
A user in Japan hitting a server in Virginia
43
00:01:20,480 --> 00:01:22,800
is never going to get a fast response.
44
00:01:22,800 --> 00:01:25,320
The physics of the internet just won't let it happen.
45
00:01:25,320 --> 00:01:27,560
Light travels at a fixed speed
46
00:01:27,560 --> 00:01:29,920
and every network hop adds delay.
47
00:01:29,920 --> 00:01:32,360
You can't fix that with better code or faster servers.
48
00:01:32,360 --> 00:01:34,440
Here's the thing, slow apps lose users.
49
00:01:34,440 --> 00:01:37,000
A one second delay cuts conversions by 7%
50
00:01:37,000 --> 00:01:39,880
and a regional outage that doesn't just slow things down,
51
00:01:39,880 --> 00:01:41,440
it takes your entire app offline.
52
00:01:41,440 --> 00:01:43,760
Your users can't reach you, your revenue stops
53
00:01:43,760 --> 00:01:45,520
and your reputation takes a hit.
54
00:01:45,520 --> 00:01:48,040
20 years ago, the old approach was to build servers
55
00:01:48,040 --> 00:01:51,560
in every region and manually direct users to the right one.
56
00:01:51,560 --> 00:01:53,560
You'd update DNS records by hand,
57
00:01:53,560 --> 00:01:55,680
maintain spreadsheets of which users went where
58
00:01:55,680 --> 00:01:58,000
and pray you didn't make a mistake during a failover.
59
00:01:58,000 --> 00:02:00,280
That approach is impractical and brittle
60
00:02:00,280 --> 00:02:02,600
because it doesn't scale and breaks under pressure.
61
00:02:02,600 --> 00:02:05,400
The new approach is a single DNS-based traffic director
62
00:02:05,400 --> 00:02:08,520
that picks the best endpoint per user per request.
63
00:02:08,520 --> 00:02:11,320
It requires no manual updates or fragile spreadsheets.
64
00:02:11,320 --> 00:02:13,160
Instead, it looks at where the user is,
65
00:02:13,160 --> 00:02:16,360
checks which endpoints are healthy and returns the best one.
66
00:02:16,360 --> 00:02:18,880
Think of it like a global air traffic control system
67
00:02:18,880 --> 00:02:20,800
where each data center is an airport
68
00:02:20,800 --> 00:02:23,600
and traffic manager is the control tower directing each user
69
00:02:23,600 --> 00:02:25,040
to the nearest available server.
70
00:02:25,040 --> 00:02:26,440
That's where traffic manager comes in.
71
00:02:26,440 --> 00:02:28,480
So let's talk about what it actually is.
72
00:02:28,480 --> 00:02:30,120
What traffic manager actually is.
73
00:02:30,120 --> 00:02:31,560
Here's the simplest definition.
74
00:02:31,560 --> 00:02:33,800
Traffic manager is a DNS-based load balancer
75
00:02:33,800 --> 00:02:35,360
that runs at global scale.
76
00:02:35,360 --> 00:02:37,440
Think of it like a smart reception desk
77
00:02:37,440 --> 00:02:39,680
at the entrance of a worldwide office building.
78
00:02:39,680 --> 00:02:41,640
When you walk in, the receptionist doesn't handle
79
00:02:41,640 --> 00:02:43,760
your phone calls or process your paperwork.
80
00:02:43,760 --> 00:02:45,120
They just point you to the right floor.
81
00:02:45,120 --> 00:02:46,760
That's all traffic manager does.
82
00:02:46,760 --> 00:02:48,480
It points users to the right server.
83
00:02:48,480 --> 00:02:49,880
Here's the key distinction.
84
00:02:49,880 --> 00:02:53,040
Traffic manager never sees your actual traffic.
85
00:02:53,040 --> 00:02:56,400
It doesn't proxy requests, inspect packets or cache content.
86
00:02:56,400 --> 00:02:58,840
When a user types your domain name into their browser,
87
00:02:58,840 --> 00:03:00,360
a DNS query goes out.
88
00:03:00,360 --> 00:03:01,920
Traffic manager answers that query
89
00:03:01,920 --> 00:03:04,120
with the IP address of the best endpoint,
90
00:03:04,120 --> 00:03:06,000
the closest one, the healthiest one,
91
00:03:06,000 --> 00:03:08,080
the one you've configured as the priority.
92
00:03:08,080 --> 00:03:10,440
Then the user connects directly to that endpoint
93
00:03:10,440 --> 00:03:12,640
and traffic manager steps out of the way completely.
94
00:03:12,640 --> 00:03:15,520
That means it adds zero latency to your traffic path.
95
00:03:15,520 --> 00:03:17,080
Because it's not in the middle of the data flow,
96
00:03:17,080 --> 00:03:18,560
it can't slow things down.
97
00:03:18,560 --> 00:03:20,920
It also works with any internet facing endpoint,
98
00:03:20,920 --> 00:03:23,200
Azure services, servers in another cloud,
99
00:03:23,200 --> 00:03:25,440
even your own on-premises data center.
100
00:03:25,440 --> 00:03:27,640
As long as the endpoint has a public IP address
101
00:03:27,640 --> 00:03:30,360
or a domain name, traffic manager can root to it.
102
00:03:30,360 --> 00:03:31,960
And because it's a global service,
103
00:03:31,960 --> 00:03:33,920
it's resilient to regional failures.
104
00:03:33,920 --> 00:03:36,160
If an entire Azure region goes down,
105
00:03:36,160 --> 00:03:38,520
traffic manager keeps running and roots users
106
00:03:38,520 --> 00:03:40,240
to healthy endpoints elsewhere.
107
00:03:40,240 --> 00:03:42,640
So how does traffic manager know which endpoints are healthy?
108
00:03:42,640 --> 00:03:45,120
It probes them every 30 seconds by default,
109
00:03:45,120 --> 00:03:49,440
sending an HTTP or HTTPS request to a specific path on each endpoint.
110
00:03:49,440 --> 00:03:52,000
If the endpoint responds with a 200-level status code
111
00:03:52,000 --> 00:03:53,720
within a timeout, it's healthy.
112
00:03:53,720 --> 00:03:56,160
If it fails to respond multiple times in a row,
113
00:03:56,160 --> 00:03:58,000
traffic manager marks it as degraded
114
00:03:58,000 --> 00:03:59,360
and stops sending users there.
115
00:03:59,360 --> 00:04:00,520
When the endpoint recovers,
116
00:04:00,520 --> 00:04:02,280
traffic manager detects that too
117
00:04:02,280 --> 00:04:04,080
and brings it back into rotation.
118
00:04:04,080 --> 00:04:07,360
This health monitoring is what makes automatic fail over possible.
119
00:04:07,360 --> 00:04:08,960
Now, let's look at the different ways
120
00:04:08,960 --> 00:04:12,440
traffic manager decides which endpoint to send users to.
121
00:04:12,440 --> 00:04:14,080
That's where the routing methods come in.
122
00:04:15,080 --> 00:04:16,480
Priority routing?
123
00:04:16,480 --> 00:04:18,240
Disaster recovery made simple.
124
00:04:18,240 --> 00:04:20,600
Priority routing is the simplest method to understand.
125
00:04:20,600 --> 00:04:23,080
You rank your endpoints from one to however many you have.
126
00:04:23,080 --> 00:04:23,760
That's it.
127
00:04:23,760 --> 00:04:25,240
All traffic goes to priority one.
128
00:04:25,240 --> 00:04:27,840
If that endpoint fails, traffic shifts to priority two,
129
00:04:27,840 --> 00:04:29,760
then three and so on down the list.
130
00:04:29,760 --> 00:04:31,480
It's an active passive setup.
131
00:04:31,480 --> 00:04:33,360
One endpoint handles everything.
132
00:04:33,360 --> 00:04:34,760
The others wait in the wings.
133
00:04:34,760 --> 00:04:36,200
Here's a real world example.
134
00:04:36,200 --> 00:04:38,960
Say your primary servers run in East US
135
00:04:38,960 --> 00:04:40,680
and you have a backup in West Europe.
136
00:04:40,680 --> 00:04:43,880
You set East US as priority one, West Europe is priority two.
137
00:04:43,880 --> 00:04:46,720
Normal operation, every user goes to East US.
138
00:04:46,720 --> 00:04:49,280
But when East US has an outage, maybe a power failure,
139
00:04:49,280 --> 00:04:52,680
maybe a network issue, traffic manager detects it within seconds.
140
00:04:52,680 --> 00:04:54,600
It stops sending new users to East US
141
00:04:54,600 --> 00:04:56,840
and starts redirecting them to West Europe instead.
142
00:04:56,840 --> 00:05:00,200
Your app stays online, your users might not even notice anything happened.
143
00:05:00,200 --> 00:05:01,840
Now, there's an important detail here.
144
00:05:01,840 --> 00:05:04,000
Existing users keep their current connection.
145
00:05:04,000 --> 00:05:06,320
DNS based routing only affects new DNS lookups.
146
00:05:06,320 --> 00:05:08,840
So if someone already loaded your app and has an active session,
147
00:05:08,840 --> 00:05:11,680
that session keeps going to the original endpoint until it ends
148
00:05:11,680 --> 00:05:13,320
or the DNS cache expires.
149
00:05:13,320 --> 00:05:17,920
That's why you want to set your DNS TTL low 30 to 60 seconds is the sweet spot.
150
00:05:17,920 --> 00:05:21,520
A low TTL means DNS resolvers check for updates more frequently.
151
00:05:21,520 --> 00:05:24,800
So when traffic manager switches endpoints, the change propagates faster.
152
00:05:24,800 --> 00:05:27,920
One common mistake people make is for getting to test the failover.
153
00:05:27,920 --> 00:05:30,560
You set a priority routing, you deploy your backup region
154
00:05:30,560 --> 00:05:31,960
and then you just assume it works.
155
00:05:31,960 --> 00:05:35,800
But here's the thing, your backup region needs to handle the full load.
156
00:05:35,800 --> 00:05:37,960
If your primary handles are million users a day
157
00:05:37,960 --> 00:05:41,400
and your backup only handles 100,000 during normal operations,
158
00:05:41,400 --> 00:05:45,480
that backup might fall over when all that traffic suddenly shifts to it.
159
00:05:45,480 --> 00:05:49,000
Test your failover, actually simulate an outage and watch what happens.
160
00:05:49,000 --> 00:05:50,440
That's the only way to know it works.
161
00:05:50,440 --> 00:05:53,600
Priority is about keeping your app alive during failures.
162
00:05:53,600 --> 00:05:56,040
But what about making it fast for everyone?
163
00:05:56,040 --> 00:05:58,240
Performance routing, speed over everything.
164
00:05:58,240 --> 00:06:00,920
Performance routing works differently than priority routing.
165
00:06:00,920 --> 00:06:03,240
Instead of saying always use this endpoint first,
166
00:06:03,240 --> 00:06:07,000
it says send each user to whatever endpoint gives them the fastest connection.
167
00:06:07,000 --> 00:06:09,480
So a user in Tokyo gets routed to a server in Japan.
168
00:06:09,480 --> 00:06:11,120
A user in London gets routed to Ireland.
169
00:06:11,120 --> 00:06:13,520
A user in Sao Paulo gets routed to Brazil.
170
00:06:13,520 --> 00:06:16,680
Every user gets the fastest possible experience, no matter where they are.
171
00:06:16,680 --> 00:06:19,800
How does traffic manager know which endpoint is fastest?
172
00:06:19,800 --> 00:06:22,120
It uses something called an internet latency table.
173
00:06:22,120 --> 00:06:24,480
Think of it as a map that Azure keeps up to date.
174
00:06:24,480 --> 00:06:27,840
It tracks the actual network latency between different parts of the world
175
00:06:27,840 --> 00:06:29,280
and each Azure region.
176
00:06:29,280 --> 00:06:31,000
When a DNS query comes in,
177
00:06:31,000 --> 00:06:34,400
traffic manager checks where the user's DNS resolver is located,
178
00:06:34,400 --> 00:06:36,920
looks up the latency table and returns the endpoint
179
00:06:36,920 --> 00:06:39,600
that gives that user the lowest latency.
180
00:06:39,600 --> 00:06:41,280
Now here's something that might surprise you.
181
00:06:41,280 --> 00:06:43,000
It's not based on physical distance.
182
00:06:43,000 --> 00:06:47,440
A user in India might actually get lower latency to East US than to Southeast Asia,
183
00:06:47,440 --> 00:06:51,600
depending on how the undersea cables and internet exchanges are routing traffic at that moment.
184
00:06:51,600 --> 00:06:53,920
The latency table captures real network conditions,
185
00:06:53,920 --> 00:06:55,960
not just straight line distance.
186
00:06:55,960 --> 00:06:59,560
So the closest endpoint isn't always the one that's geographically nearest.
187
00:06:59,560 --> 00:07:02,680
Performance routing is a great fit for globally distributed apps
188
00:07:02,680 --> 00:07:04,800
where user experience depends on speed.
189
00:07:04,800 --> 00:07:07,960
Ecommerce sites, video streaming, real-time collaboration tools,
190
00:07:07,960 --> 00:07:10,320
anything where a slow response means a lost user.
191
00:07:10,320 --> 00:07:11,200
But there's a catch.
192
00:07:11,200 --> 00:07:14,480
It doesn't consider how much load each endpoint is already handling.
193
00:07:14,480 --> 00:07:19,000
If your East US region is running at 95% capacity in your West Europe region is at 20%,
194
00:07:19,000 --> 00:07:21,600
performance routing might still send new users to East US
195
00:07:21,600 --> 00:07:23,400
because that's the lowest latency for them.
196
00:07:23,400 --> 00:07:24,920
It doesn't know about your server load.
197
00:07:24,920 --> 00:07:28,800
So you typically combine performance routing with other load balances inside each region.
198
00:07:28,800 --> 00:07:31,320
Azure load balancer or application gateway
199
00:07:31,320 --> 00:07:34,000
to handle the actual distribution of traffic across your servers
200
00:07:34,000 --> 00:07:36,480
once the user arrives at the right region.
201
00:07:36,480 --> 00:07:38,600
Performance routing optimizes for speed,
202
00:07:38,600 --> 00:07:42,800
but what if you need to control how much traffic each endpoint gets?
203
00:07:42,800 --> 00:07:46,080
Weighted and geographic routing, control and compliance.
204
00:07:46,080 --> 00:07:47,840
So performance routing is about speed.
205
00:07:47,840 --> 00:07:51,480
But what if you want to control exactly how much traffic each endpoint gets?
206
00:07:51,480 --> 00:07:54,360
Or, root users based on where they're located in the world?
207
00:07:54,360 --> 00:07:56,560
That's where weighted and geographic routing come in.
208
00:07:56,560 --> 00:07:58,080
Let's start with weighted routing.
209
00:07:58,080 --> 00:08:00,480
This one is exactly what it sounds like.
210
00:08:00,480 --> 00:08:04,400
You assign a weight to each endpoint, a number between 1 and 1000.
211
00:08:04,400 --> 00:08:07,960
Traffic manager then distributes traffic proportionally based on those weights.
212
00:08:07,960 --> 00:08:12,240
So if you have endpoint A with a weight of 80 and endpoint B with a weight of 20,
213
00:08:12,240 --> 00:08:17,480
roughly 80% of your users get sent to A and 20% go to B, simple math.
214
00:08:17,480 --> 00:08:18,800
Now, why would you want to do that?
215
00:08:18,800 --> 00:08:20,160
Think about a canary release.
216
00:08:20,160 --> 00:08:23,400
You've built a new version of your app and you want to test it with real users
217
00:08:23,400 --> 00:08:25,120
before rolling it out to everyone.
218
00:08:25,120 --> 00:08:27,600
You set up a second endpoint running the new version,
219
00:08:27,600 --> 00:08:31,680
give it a weight of five and give your current production endpoint a weight of 95.
220
00:08:31,680 --> 00:08:33,880
Five percent of your users hit the new version.
221
00:08:33,880 --> 00:08:37,120
You watch for errors, monitor performance, and if everything looks good,
222
00:08:37,120 --> 00:08:41,920
you slowly increase the weight on the new version, maybe 20% next week, then 50, then 100.
223
00:08:41,920 --> 00:08:45,200
If something goes wrong, you drop the weight back to zero and the problem is contained.
224
00:08:45,200 --> 00:08:49,160
No big bang deployment, no rolling back a broken release in front of all your users.
225
00:08:49,160 --> 00:08:51,160
Same idea applies to A, B testing.
226
00:08:51,160 --> 00:08:53,520
You want to see if a new feature improves engagement.
227
00:08:53,520 --> 00:08:57,240
Send half your users to version A and half to version B using equal weights
228
00:08:57,240 --> 00:09:00,800
compare the results or your migrating users from one region to another.
229
00:09:00,800 --> 00:09:04,960
Gradually shift the weight from the old region to the new one over a few weeks.
230
00:09:04,960 --> 00:09:06,800
Here's something important to understand though.
231
00:09:06,800 --> 00:09:08,360
Weighted routing is not round robin.
232
00:09:08,360 --> 00:09:10,920
It doesn't alternate between endpoints one request at a time.
233
00:09:10,920 --> 00:09:13,880
It's a statistical distribution over a large number of requests.
234
00:09:13,880 --> 00:09:15,960
The traffic splits according to your weights.
235
00:09:15,960 --> 00:09:20,520
But a single user making multiple requests might keep hitting the same endpoint
236
00:09:20,520 --> 00:09:22,800
because their DNS resolver caches the result.
237
00:09:22,800 --> 00:09:24,640
So don't think of it as perfect load balancing.
238
00:09:24,640 --> 00:09:28,240
Think of it as controlling the overall proportion of traffic over time.
239
00:09:28,240 --> 00:09:29,840
Now let's talk about geographic routing.
240
00:09:29,840 --> 00:09:33,400
This one roots users based on where their DNS query originates.
241
00:09:33,400 --> 00:09:35,840
Country, continent or a specific region.
242
00:09:35,840 --> 00:09:38,960
So a user in Germany gets sent to your endpoint in Frankfurt.
243
00:09:38,960 --> 00:09:42,240
A user in Brazil gets sent to your endpoint in Sao Paulo.
244
00:09:42,240 --> 00:09:43,480
That level of granularity.
245
00:09:43,480 --> 00:09:44,560
Why would you use this?
246
00:09:44,560 --> 00:09:46,040
Data sovereignty is a big one.
247
00:09:46,040 --> 00:09:49,280
European Union regulations might require that user data stays within Europe.
248
00:09:49,280 --> 00:09:52,040
Geographic routing lets you enforce that at the DNS level.
249
00:09:52,040 --> 00:09:56,080
A user from France resolves your domain and traffic manager returns the IP address
250
00:09:56,080 --> 00:09:57,600
of your European endpoint.
251
00:09:57,600 --> 00:09:59,280
Their data never leaves the continent.
252
00:09:59,280 --> 00:10:00,600
Same thing for localized content.
253
00:10:00,600 --> 00:10:04,200
If you want users in Japan to see a Japanese language version of your site,
254
00:10:04,200 --> 00:10:07,520
geographic routing sends them to the endpoint that serves that content.
255
00:10:07,520 --> 00:10:09,120
There's one key rule you need to know.
256
00:10:09,120 --> 00:10:12,040
Every geographic region must map to exactly one endpoint.
257
00:10:12,040 --> 00:10:14,800
You can't split a single country across two endpoints.
258
00:10:14,800 --> 00:10:19,440
So if you have users in Germany and you want 50% to go to Frankfurt and 50% to Berlin,
259
00:10:19,440 --> 00:10:21,240
you can't do that with geographic routing alone.
260
00:10:21,240 --> 00:10:23,560
You'd need to use a nested profile instead.
261
00:10:23,560 --> 00:10:25,560
Nested profiles are exactly what they sound like.
262
00:10:25,560 --> 00:10:27,920
You put one traffic manager profile inside another.
263
00:10:27,920 --> 00:10:32,400
So at the top level, you use geographic routing to send European users to one profile,
264
00:10:32,400 --> 00:10:34,320
North American users to another and so on.
265
00:10:34,320 --> 00:10:37,640
Then inside each of those profiles, you use weighted routing to split traffic between
266
00:10:37,640 --> 00:10:39,520
endpoints within that region.
267
00:10:39,520 --> 00:10:42,760
Geographic at the top for compliance, weighted inside for control.
268
00:10:42,760 --> 00:10:44,160
It's a powerful combination.
269
00:10:44,160 --> 00:10:46,640
Two more routing methods handle more specific scenarios.
270
00:10:46,640 --> 00:10:48,360
Let's look at those.
271
00:10:48,360 --> 00:10:51,520
Multi-value and subnet routing for fine-grained control.
272
00:10:51,520 --> 00:10:53,600
Multi-value routing is a simple but useful trick.
273
00:10:53,600 --> 00:10:57,680
Instead of returning just one endpoint in the DNS response, traffic manager sends back
274
00:10:57,680 --> 00:11:00,520
multiple healthy IP addresses all at once.
275
00:11:00,520 --> 00:11:04,280
Your browser or app picks the first one from the list, which spreads the load without traffic
276
00:11:04,280 --> 00:11:06,600
manager needing to decide for every request.
277
00:11:06,600 --> 00:11:07,600
But there's a catch.
278
00:11:07,600 --> 00:11:13,040
Multi-value only works with IPv4 and IPv6 endpoints, so you can't use it with app service, cloud
279
00:11:13,040 --> 00:11:17,480
services, or any endpoint that uses a domain name instead of an IP address.
280
00:11:17,480 --> 00:11:19,480
It's purely for IP-based endpoints.
281
00:11:19,480 --> 00:11:23,400
When you have those though, it makes the system more resilient because if one IP fails,
282
00:11:23,400 --> 00:11:26,600
the client can try another from the list without doing a new DNS lookup.
283
00:11:26,600 --> 00:11:31,160
That means faster failover on the client side, subnet routing is even more niche, but powerful
284
00:11:31,160 --> 00:11:32,160
when you need it.
285
00:11:32,160 --> 00:11:36,200
It routes users based on the source IP subnet that DNS query comes from.
286
00:11:36,200 --> 00:11:40,280
So you can map your company's office IP range to a staging endpoint and everyone else gets
287
00:11:40,280 --> 00:11:41,760
the production version.
288
00:11:41,760 --> 00:11:46,960
Or you can route users from a specific VPN subnet to a dedicated backend for testing.
289
00:11:46,960 --> 00:11:51,280
Picture an internal testing scenario where your development team is working from the office.
290
00:11:51,280 --> 00:11:55,740
The DNS queries come from your corporate IP range and you map that range to a staging
291
00:11:55,740 --> 00:11:58,480
environment where they can test the latest build.
292
00:11:58,480 --> 00:12:00,760
Everyone else on the internet gets the production version.
293
00:12:00,760 --> 00:12:05,320
No special URLs, no VPN configurations, just transparent routing based on where the request
294
00:12:05,320 --> 00:12:06,320
comes from.
295
00:12:06,320 --> 00:12:07,720
Both of these methods are niche.
296
00:12:07,720 --> 00:12:11,720
Most people will use priority, performance, weighted, or geographic for their main traffic
297
00:12:11,720 --> 00:12:15,680
management, but multi-value and subnet are there when you need them and they solve problems
298
00:12:15,680 --> 00:12:17,600
that the other methods can't.
299
00:12:17,600 --> 00:12:19,720
Health monitoring and failover in practice.
300
00:12:19,720 --> 00:12:24,200
All these routing methods depend on one thing, knowing which endpoints are actually healthy.
301
00:12:24,200 --> 00:12:28,400
Routing traffic to a broken server doesn't help anyone, so let's talk about how health monitoring
302
00:12:28,400 --> 00:12:29,960
works in practice.
303
00:12:29,960 --> 00:12:33,880
Traffic manager sends a health probe to each endpoint every 30 seconds by default and that
304
00:12:33,880 --> 00:12:38,480
probe is an HTTP or HTTPS request to a specific path on your endpoint.
305
00:12:38,480 --> 00:12:43,880
It expects a response with a status code between 200 and 299 within a certain timeout period.
306
00:12:43,880 --> 00:12:46,080
If the endpoint responds correctly, it's healthy.
307
00:12:46,080 --> 00:12:48,600
If it doesn't, traffic manager tries again.
308
00:12:48,600 --> 00:12:52,680
After a configurable number of failures, default three, traffic manager marks that endpoint
309
00:12:52,680 --> 00:12:56,760
as degraded and excludes it from routing until it starts passing health checks again.
310
00:12:56,760 --> 00:12:59,400
You can configure the probing interval and the timeout.
311
00:12:59,400 --> 00:13:01,000
Faster probes mean faster failover.
312
00:13:01,000 --> 00:13:05,760
If you set the interval to 10 seconds instead of 30, traffic manager detects failures sooner
313
00:13:05,760 --> 00:13:07,680
and redirects traffic more quickly.
314
00:13:07,680 --> 00:13:08,760
But there's a trade-off.
315
00:13:08,760 --> 00:13:12,200
Faster probes put more load on your endpoints because every probe is a request your server
316
00:13:12,200 --> 00:13:13,200
has to handle.
317
00:13:13,200 --> 00:13:16,720
So if you have thousands of endpoints and you're probing every 10 seconds, the requests add
318
00:13:16,720 --> 00:13:17,720
up.
319
00:13:17,720 --> 00:13:19,360
And speed against overhead.
320
00:13:19,360 --> 00:13:23,440
The real impact of proper health check configuration is the difference between a seamless
321
00:13:23,440 --> 00:13:26,520
failover and a false alarm that breaks your routing.
322
00:13:26,520 --> 00:13:30,720
If your probe is too sensitive, you might mark an endpoint as degraded when it's actually
323
00:13:30,720 --> 00:13:31,720
fine.
324
00:13:31,720 --> 00:13:36,200
A temporary spike in latency, a brief network glitch, a slow database query.
325
00:13:36,200 --> 00:13:38,320
Any of these could trigger a false positive.
326
00:13:38,320 --> 00:13:42,320
When traffic manager stops sending users to that endpoint, you've just created an outage
327
00:13:42,320 --> 00:13:43,640
that didn't need to happen.
328
00:13:43,640 --> 00:13:45,040
Here's a common pitfall.
329
00:13:45,040 --> 00:13:48,800
A couple set the probe path to the root of their application, just a forward slash.
330
00:13:48,800 --> 00:13:52,720
That's fine for a basic health check, but it's not ideal because the root page might
331
00:13:52,720 --> 00:13:57,960
load slowly if it renders a full page with database queries, images, and JavaScript.
332
00:13:57,960 --> 00:14:02,040
A better approach is to create a dedicated health check endpoint, something lightweight.
333
00:14:02,040 --> 00:14:05,760
A simple endpoint that returns a 200 status code quickly and confirms the application is
334
00:14:05,760 --> 00:14:06,760
running.
335
00:14:06,760 --> 00:14:09,640
No database queries, no heavy processing, just a heartbeat.
336
00:14:09,640 --> 00:14:13,920
That way your probes are fast, reliable and less likely to trigger false alarms.
337
00:14:13,920 --> 00:14:19,240
Let me wrap up with when you should actually use traffic manager versus other options.
338
00:14:19,240 --> 00:14:20,600
Conclusion and decision guide.
339
00:14:20,600 --> 00:14:22,160
So here's the quick recap.
340
00:14:22,160 --> 00:14:26,160
Traffic manager is a DNS-based global traffic director with six routing methods.
341
00:14:26,160 --> 00:14:28,080
It doesn't actually handle your traffic.
342
00:14:28,080 --> 00:14:32,080
It just points users to the right place based on the method you pick.
343
00:14:32,080 --> 00:14:33,800
Priority routing is for disaster recovery.
344
00:14:33,800 --> 00:14:37,640
It keeps your app running even if an entire region goes down.
345
00:14:37,640 --> 00:14:39,760
Performance routing is all about speed.
346
00:14:39,760 --> 00:14:43,400
It sends each user to the endpoint with the lowest latency.
347
00:14:43,400 --> 00:14:48,720
Weighted routing lets you do controlled rollouts like canary releases or A/B testing.
348
00:14:48,720 --> 00:14:50,280
Geographic routing handles compliance.
349
00:14:50,280 --> 00:14:53,920
You keep data in the right region according to where your users are located.
350
00:14:53,920 --> 00:14:57,760
Multi-value is for simple IP-level distribution across multiple addresses.
351
00:14:57,760 --> 00:15:01,600
And subnet routing routes based on the source IP of the DNS query.
352
00:15:01,600 --> 00:15:05,000
Now let's talk about where traffic manager fits into a real architecture.
353
00:15:05,000 --> 00:15:06,600
Think of it as the first layer.
354
00:15:06,600 --> 00:15:08,560
It roots users to the right region.
355
00:15:08,560 --> 00:15:11,800
Once they arrive there, you need other services to handle the actual traffic.
356
00:15:11,800 --> 00:15:15,840
Azure Load Balancer distributes traffic across VMs inside a single region.
357
00:15:15,840 --> 00:15:19,680
Application gateway gives you layer 7 routing and a web application firewall.
358
00:15:19,680 --> 00:15:24,000
Front door adds global caching, TLS termination and deeper security features.
359
00:15:24,000 --> 00:15:25,600
Traffic manager works alongside all of these.
360
00:15:25,600 --> 00:15:27,320
It's not a replacement for any of them.
361
00:15:27,320 --> 00:15:29,000
Here's a quick mental shortcut.
362
00:15:29,000 --> 00:15:31,160
Use traffic manager for cross-region routing.
363
00:15:31,160 --> 00:15:34,080
Use Azure Load Balancer for within region distribution.
364
00:15:34,080 --> 00:15:37,960
Use Front Door when you also need WAF caching and TLS termination at the edge.
365
00:15:37,960 --> 00:15:39,560
Each one solves a different problem.
366
00:15:39,560 --> 00:15:41,120
Here's your final challenge.
367
00:15:41,120 --> 00:15:43,440
Take a look at your current app's architecture.
368
00:15:43,440 --> 00:15:47,200
If users in different regions get different speeds, or if you don't have a failover plan
369
00:15:47,200 --> 00:15:51,000
for when a region goes down, traffic manager might be your simplest fix.
370
00:15:51,000 --> 00:15:54,560
It's not complicated to set up and it solves a problem that only gets harder to ignore
371
00:15:54,560 --> 00:15:55,720
as your app grows.
372
00:15:55,720 --> 00:15:58,400
That wraps up this episode of Microsoft Knowledge Nuggets.
373
00:15:58,400 --> 00:16:01,840
If this helped you understand traffic manager a little better, share it with someone who's
374
00:16:01,840 --> 00:16:03,320
starting their Azure journey.
375
00:16:03,320 --> 00:16:06,600
subscribe on your favorite podcast platform and I'll see you in the next one.
Founder of m365.fm, m365.show and m365con.net
Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.
Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.
With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.
