July 17, 2026
Azure Traffic Manager - Simply Explained
Azure Traffic Manager is Microsoft's global DNS-based traffic distribution service that directs users to the most appropriate application endpoint anywhere in the world. Instead of sending every user to a single data center, Traffic Manager intelligently routes requests based on factors such as latency, geographic location, endpoint health, or custom routing policies. Because it operates at the DNS layer, Traffic Manager never sits in the data path—it simply tells users which endpoint to connect to. This makes it an extremely lightweight, highly available, and globally scalable solution for improving application performance and business continuity.
WHY GLOBAL TRAFFIC ROUTING MATTERS
As businesses expand globally, users expect fast and reliable applications regardless of where they are located. A customer in Tokyo connecting to an application hosted only in Virginia experiences much higher latency than someone located nearby. Even worse, if that single region becomes unavailable, every user loses access to the application. Azure Traffic Manager solves these challenges by directing each user to the closest, fastest, or healthiest deployment. This improves application responsiveness, reduces downtime, and enables organizations to build resilient multi-region architectures without requiring users to manually choose a server or location.
HOW AZURE TRAFFIC MANAGER WORKS
Unlike Azure Load Balancer or Azure Application Gateway, Traffic Manager does not proxy or inspect network traffic. Instead, it answers DNS queries with the IP address or hostname of the best available endpoint. Once the DNS lookup is complete, the user's device connects directly to that endpoint, meaning Traffic Manager introduces virtually no additional latency. It continuously monitors each configured endpoint using HTTP, HTTPS, or TCP health probes. If an endpoint fails multiple health checks, Traffic Manager automatically removes it from DNS responses and redirects new users to healthy locations. When the endpoint recovers, it is automatically placed back into service, providing seamless failover without manual intervention.
UNDERSTANDING THE SIX ROUTING METHODS
Azure Traffic Manager offers six routing methods designed for different business scenarios. Priority Routing provides active-passive disaster recovery by automatically failing over to backup regions. Performance Routing sends users to the endpoint with the lowest network latency. Weighted Routing distributes traffic according to administrator-defined percentages, making it ideal for canary deployments, A/B testing, and gradual migrations. Geographic Routing directs users based on their country or region to support compliance and localized experiences. Subnet Routing allows routing based on the source IP range, while Multivalue Routing returns multiple healthy IP addresses for simple client-side failover. These flexible routing policies enable organizations to optimize performance, availability, compliance, and deployment strategies with a single service.
TRAFFIC MANAGER VS LOAD BALANCER VS FRONT DOOR
Azure Traffic Manager is often confused with other Azure networking services, but each solves a different problem. Traffic Manager operates globally at the DNS layer and decides where users should connect. Azure Load Balancer distributes traffic between virtual machines within a single region using Layer 4 networking. Azure Application Gateway provides Layer 7 routing, SSL termination, and a Web Application Firewall for web applications. Azure Front Door combines global routing with edge caching, Web Application Firewall capabilities, and application acceleration. Many enterprise architectures actually use these services together—for example, Traffic Manager routes users to the closest region, while Load Balancer or Application Gateway distributes traffic within that region.
WHEN SHOULD YOU USE AZURE TRAFFIC MANAGER?
Azure Traffic Manager is the ideal solution for organizations running applications across multiple Azure regions, multiple clouds, or hybrid environments. It improves global performance, enables automatic disaster recovery, supports regulatory requirements through geographic routing, and simplifies controlled software rollouts using weighted traffic distribution. Combined with continuous health monitoring, flexible routing methods, and Microsoft's globally distributed DNS infrastructure, Azure Traffic Manager provides a reliable foundation for highly available applications that serve users around the world with minimal latency and maximum resilience.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 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.
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.
