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.