1
00:00:00,000 --> 00:00:01,340
So imagine you've got a website.

2
00:00:01,340 --> 00:00:04,140
Maybe it's an online store, a blog, or a business site.

3
00:00:04,140 --> 00:00:06,880
You host it in one place, say a data center in Virginia.

4
00:00:06,880 --> 00:00:09,360
That works fine for customers in New York or Chicago.

5
00:00:09,360 --> 00:00:12,440
But what about someone in Tokyo, or in London, or in Sydney?

6
00:00:12,440 --> 00:00:14,360
Every time that person visits your site,

7
00:00:14,360 --> 00:00:17,040
their request has to cross oceans and continents

8
00:00:17,040 --> 00:00:18,640
just to reach your server.

9
00:00:18,640 --> 00:00:20,880
Each image, each page load, each API call

10
00:00:20,880 --> 00:00:23,720
makes the same long journey, and that delay adds up quickly.

11
00:00:23,720 --> 00:00:26,720
Actually, studies show that even a one-second delay

12
00:00:26,720 --> 00:00:28,960
in page load time can cost you conversions

13
00:00:28,960 --> 00:00:30,880
and drive frustrated visitors away.

14
00:00:30,880 --> 00:00:33,520
But here's the thing, what happens when your site goes viral,

15
00:00:33,520 --> 00:00:35,280
or a botnet decides to attack?

16
00:00:35,280 --> 00:00:37,000
Your single server in Virginia gets hammered.

17
00:00:37,000 --> 00:00:38,960
It slows down and it can even crash entirely.

18
00:00:38,960 --> 00:00:40,320
You're stuck with no backup plan.

19
00:00:40,320 --> 00:00:41,840
You can fix the availability problem

20
00:00:41,840 --> 00:00:44,000
by building copies of your site in different regions,

21
00:00:44,000 --> 00:00:45,560
Tokyo, London, São Paulo.

22
00:00:45,560 --> 00:00:46,800
That helps.

23
00:00:46,800 --> 00:00:48,120
But now you have a new problem.

24
00:00:48,120 --> 00:00:50,520
How do you send each visitor to the right location?

25
00:00:50,520 --> 00:00:51,560
You don't want someone in Japan

26
00:00:51,560 --> 00:00:53,480
hitting your US server by accident.

27
00:00:53,480 --> 00:00:55,240
You need a smart way to route traffic,

28
00:00:55,240 --> 00:00:58,040
and that's exactly where Azure Front Door comes in.

29
00:00:58,040 --> 00:01:01,000
Meet the global traffic cop, what Azure Front Door is.

30
00:01:01,000 --> 00:01:03,120
Think of Azure Front Door as a global traffic cop,

31
00:01:03,120 --> 00:01:04,680
not just one at a single intersection,

32
00:01:04,680 --> 00:01:07,080
but thousands of them stationed at major intersections

33
00:01:07,080 --> 00:01:08,080
all over the world.

34
00:01:08,080 --> 00:01:09,400
Every time someone visits your website,

35
00:01:09,400 --> 00:01:11,280
the nearest cop steps in and says,

36
00:01:11,280 --> 00:01:12,240
you're in Tokyo.

37
00:01:12,240 --> 00:01:14,120
The fastest store for you is in Singapore.

38
00:01:14,120 --> 00:01:15,200
Let me take you there.

39
00:01:15,200 --> 00:01:17,800
So how is this different from a regular load balancer?

40
00:01:17,800 --> 00:01:19,680
Most load balancers work at layer four,

41
00:01:19,680 --> 00:01:22,360
looking at IP addresses and ports to route traffic.

42
00:01:22,360 --> 00:01:23,960
That's fine for basic needs.

43
00:01:23,960 --> 00:01:25,840
But Azure Front Door works at layer seven,

44
00:01:25,840 --> 00:01:29,400
meaning it understands HTTP and HTTPS traffic.

45
00:01:29,400 --> 00:01:31,160
It can look at the URL someone typed,

46
00:01:31,160 --> 00:01:32,520
check their browser headers,

47
00:01:32,520 --> 00:01:34,440
see what kind of content they're asking for,

48
00:01:34,440 --> 00:01:37,440
and make smart routing decisions based on all of that.

49
00:01:37,440 --> 00:01:40,280
Instead of just saying, this IP goes to that server,

50
00:01:40,280 --> 00:01:43,320
Front Door can say this request for API users

51
00:01:43,320 --> 00:01:45,040
goes to your US back end,

52
00:01:45,040 --> 00:01:49,080
but this request for images goes to the cashed copy in Tokyo.

53
00:01:49,080 --> 00:01:51,800
Now here's what makes this possible behind the scenes.

54
00:01:51,800 --> 00:01:54,640
Azure Front Door runs on Microsoft's global network

55
00:01:54,640 --> 00:01:56,840
with over 210 points of presence

56
00:01:56,840 --> 00:02:00,200
across more than 130 metro locations worldwide.

57
00:02:00,200 --> 00:02:02,960
Think of each point of presence as a small traffic booth,

58
00:02:02,960 --> 00:02:04,640
a local office in every major city

59
00:02:04,640 --> 00:02:06,720
that can handle the initial request quickly.

60
00:02:06,720 --> 00:02:08,240
When a user visits your site,

61
00:02:08,240 --> 00:02:09,480
they connect to the nearest booth

62
00:02:09,480 --> 00:02:12,400
instead of traveling all the way to your origin server in Virginia.

63
00:02:12,400 --> 00:02:14,080
That booth then routes their request

64
00:02:14,080 --> 00:02:16,640
over Microsoft's private backbone to your back end.

65
00:02:16,640 --> 00:02:19,680
This matters because the public internet is unpredictable.

66
00:02:19,680 --> 00:02:22,360
Your traffic might take a dozen hops through different networks,

67
00:02:22,360 --> 00:02:25,440
each one adding latency and potential packet loss.

68
00:02:25,440 --> 00:02:27,160
Microsoft's backbone, on the other hand,

69
00:02:27,160 --> 00:02:28,920
is a private high-speed network

70
00:02:28,920 --> 00:02:30,920
that connects their data centers directly.

71
00:02:30,920 --> 00:02:33,760
So once your request hits that nearest point of presence,

72
00:02:33,760 --> 00:02:36,800
the rest of the journey happens on a fast, reliable highway.

73
00:02:36,800 --> 00:02:39,280
You get faster load times, lower latency,

74
00:02:39,280 --> 00:02:41,200
and a better experience for users everywhere,

75
00:02:41,200 --> 00:02:43,960
whether they're in Tokyo, London, or Sao Paulo.

76
00:02:43,960 --> 00:02:45,560
And all of this happens automatically

77
00:02:45,560 --> 00:02:48,080
without your visitors ever knowing it's there.

78
00:02:48,080 --> 00:02:51,360
Three layers of resiliency, how AFD stays up.

79
00:02:51,360 --> 00:02:52,920
Now, you might be thinking,

80
00:02:52,920 --> 00:02:55,240
this whole global traffic cop idea sounds great,

81
00:02:55,240 --> 00:02:57,520
but what happens if the cop itself crashes?

82
00:02:57,520 --> 00:03:00,800
If Azure Front Door is the single entry point for your entire app,

83
00:03:00,800 --> 00:03:02,600
that's a pretty big single point of failure, right?

84
00:03:02,600 --> 00:03:03,720
Microsoft thought about that,

85
00:03:03,720 --> 00:03:06,360
they built three layers of resiliency into Front Door,

86
00:03:06,360 --> 00:03:07,600
so it almost never goes down.

87
00:03:07,600 --> 00:03:08,720
Let me walk you through them.

88
00:03:08,720 --> 00:03:10,440
First layer, the Front End.

89
00:03:10,440 --> 00:03:14,320
Remember those 210 plus points of presence I mentioned?

90
00:03:14,320 --> 00:03:16,560
Each one is a fully independent traffic booth.

91
00:03:16,560 --> 00:03:20,240
These pop sit in more than 130 metro locations worldwide,

92
00:03:20,240 --> 00:03:22,120
running inside Microsoft data centers

93
00:03:22,120 --> 00:03:24,000
and partner location facilities.

94
00:03:24,000 --> 00:03:26,480
Every single pop holds multiple racks of servers

95
00:03:26,480 --> 00:03:29,520
with edge controllers on top acting as a built-in load balancer.

96
00:03:29,520 --> 00:03:31,720
If one server inside a pop fails,

97
00:03:31,720 --> 00:03:33,600
the edge controller re-route traffic

98
00:03:33,600 --> 00:03:35,480
to a healthy one inside that same pop.

99
00:03:35,480 --> 00:03:37,160
And if an entire pop goes down,

100
00:03:37,160 --> 00:03:39,320
that's where any cast IP addressing kicks in,

101
00:03:39,320 --> 00:03:41,360
your visitors request automatically routes

102
00:03:41,360 --> 00:03:43,040
to the next closest pop.

103
00:03:43,040 --> 00:03:45,880
No disruption and no manual intervention, it just happens.

104
00:03:45,880 --> 00:03:47,320
Second layer, the fallback.

105
00:03:47,320 --> 00:03:49,040
But what if a pop he gets overwhelmed?

106
00:03:49,040 --> 00:03:50,520
Say there's a massive traffic spike

107
00:03:50,520 --> 00:03:52,960
or multiple pops in a region go down at once.

108
00:03:52,960 --> 00:03:55,160
The remaining pops might not be able to handle the load.

109
00:03:55,160 --> 00:03:57,320
That's when the fallback layer steps in.

110
00:03:57,320 --> 00:03:59,880
This is a separate set of pops, tens of them, not hundreds,

111
00:03:59,880 --> 00:04:02,080
running the exact same software and architecture.

112
00:04:02,080 --> 00:04:05,280
They live only in Microsoft data centers, not partner facilities.

113
00:04:05,280 --> 00:04:07,440
When a Front End pop needs to shed some traffic,

114
00:04:07,440 --> 00:04:09,600
it shifts requests to this fallback layer,

115
00:04:09,600 --> 00:04:11,920
same caching, same routing, same security.

116
00:04:11,920 --> 00:04:13,520
Your visitors never notice the difference.

117
00:04:13,520 --> 00:04:15,800
They just get their content a little slower, maybe.

118
00:04:15,800 --> 00:04:16,960
But they still get it.

119
00:04:16,960 --> 00:04:18,240
Third layer, the traffic shield.

120
00:04:18,240 --> 00:04:19,520
This is the overseer.

121
00:04:19,520 --> 00:04:21,520
Think of it as a global command center

122
00:04:21,520 --> 00:04:23,640
that watches the entire front door network.

123
00:04:23,640 --> 00:04:25,440
It monitors traffic patterns, load levels,

124
00:04:25,440 --> 00:04:27,120
and health across all pops.

125
00:04:27,120 --> 00:04:29,640
When it detects that certain pops are getting overwhelmed,

126
00:04:29,640 --> 00:04:32,040
it doesn't just wait for the fallback layer to kick in.

127
00:04:32,040 --> 00:04:34,160
It proactively shifts traffic by updating

128
00:04:34,160 --> 00:04:36,800
how DNS resolves your front door endpoint.

129
00:04:36,800 --> 00:04:38,760
It can switch from a global any cast IP

130
00:04:38,760 --> 00:04:40,600
to a regional one, moving clients

131
00:04:40,600 --> 00:04:42,280
to different sets of pops entirely.

132
00:04:42,280 --> 00:04:44,000
It can even cross continents if needed.

133
00:04:44,000 --> 00:04:47,000
The traffic shield is what makes Front Door feel almost magical.

134
00:04:47,000 --> 00:04:49,200
It's constantly optimizing behind the scenes,

135
00:04:49,200 --> 00:04:51,560
adjusting routes before problems ever happen.

136
00:04:51,560 --> 00:04:53,120
Now I should mention something here.

137
00:04:53,120 --> 00:04:56,360
In October 2025, Azure Front Door suffered a significant outage.

138
00:04:56,360 --> 00:04:58,880
A configuration change skipped the safety validations

139
00:04:58,880 --> 00:05:01,720
and caused widespread issues across Microsoft 365,

140
00:05:01,720 --> 00:05:03,880
Xbox Live and thousands of customer websites.

141
00:05:03,880 --> 00:05:05,200
Microsoft learned from it.

142
00:05:05,200 --> 00:05:07,080
They removed all asynchronous processing

143
00:05:07,080 --> 00:05:08,600
from the configuration pipeline.

144
00:05:08,600 --> 00:05:11,160
Now every code path gets tested during rollout.

145
00:05:11,160 --> 00:05:13,640
They reduced the rollback time from four hours to one

146
00:05:13,640 --> 00:05:16,760
and they're targeting 10 minutes by March, 2026.

147
00:05:16,760 --> 00:05:18,960
They're also introducing microcell segmentation

148
00:05:18,960 --> 00:05:22,040
to limit any future impact to less than 1% of tenants.

149
00:05:22,040 --> 00:05:24,040
The point is, no system is perfect,

150
00:05:24,040 --> 00:05:26,320
but Front Door's three layer architecture is designed

151
00:05:26,320 --> 00:05:28,560
to survive regional outages, traffic spikes

152
00:05:28,560 --> 00:05:30,120
and even some configuration errors.

153
00:05:30,120 --> 00:05:32,200
For most applications, that's more than enough.

154
00:05:32,200 --> 00:05:33,880
For truly mission critical systems,

155
00:05:33,880 --> 00:05:35,400
you can layer Azure Traffic Manager

156
00:05:35,400 --> 00:05:37,480
in front of Front Door as a break-class path,

157
00:05:37,480 --> 00:05:39,720
but that's an advanced topic for another day.

158
00:05:39,720 --> 00:05:42,360
How it directs traffic, rooting and origin groups.

159
00:05:42,360 --> 00:05:44,080
So we've got this global traffic cop

160
00:05:44,080 --> 00:05:46,960
with over 210 booths and three layers of backup.

161
00:05:46,960 --> 00:05:49,720
But how does it actually decide where to send each visitor?

162
00:05:49,720 --> 00:05:51,320
That's where origin groups come in.

163
00:05:51,320 --> 00:05:54,440
An origin group is basically a collection of your back-end servers.

164
00:05:54,440 --> 00:05:56,160
Think of it as your list of stores,

165
00:05:56,160 --> 00:05:59,400
the actual places where your website or app runs.

166
00:05:59,400 --> 00:06:01,160
You might have one server in North America,

167
00:06:01,160 --> 00:06:02,680
one in Europe and one in Asia.

168
00:06:02,680 --> 00:06:04,200
They all go into the same origin group.

169
00:06:04,200 --> 00:06:07,120
Now Front Door doesn't just blindly send traffic to all of them,

170
00:06:07,120 --> 00:06:08,800
it constantly checks if they're alive.

171
00:06:08,800 --> 00:06:10,200
That's called a health probe.

172
00:06:10,200 --> 00:06:12,400
Every few seconds, each Front Door pop

173
00:06:12,400 --> 00:06:14,960
pings your servers by hitting a specific path,

174
00:06:14,960 --> 00:06:16,560
usually the root of your site,

175
00:06:16,560 --> 00:06:19,320
or a dedicated health endpoint like health.

176
00:06:19,320 --> 00:06:21,800
If a server doesn't respond or responds with an error code,

177
00:06:21,800 --> 00:06:24,000
Front Door marks it as unhealthy

178
00:06:24,000 --> 00:06:25,400
and stops sending traffic there.

179
00:06:25,400 --> 00:06:28,040
It's like the traffic cop checking if a store is actually open

180
00:06:28,040 --> 00:06:29,840
before sending customers in.

181
00:06:29,840 --> 00:06:31,760
But once you have multiple healthy servers,

182
00:06:31,760 --> 00:06:35,200
the question becomes, which one should get the visitor?

183
00:06:35,200 --> 00:06:37,320
Front Door uses three factors to decide,

184
00:06:37,320 --> 00:06:39,520
priority, latency and weight,

185
00:06:39,520 --> 00:06:41,600
and they work together in a specific order.

186
00:06:41,600 --> 00:06:42,680
First is priority.

187
00:06:42,680 --> 00:06:45,920
You can designate one server as primary and another as backup.

188
00:06:45,920 --> 00:06:47,680
Set the primary to priority one,

189
00:06:47,680 --> 00:06:49,240
the backup to priority two.

190
00:06:49,240 --> 00:06:51,960
Under normal conditions, all traffic goes to the primary.

191
00:06:51,960 --> 00:06:54,360
If the primary goes down, traffic shifts to the backup.

192
00:06:54,360 --> 00:06:55,160
Simple, right?

193
00:06:55,160 --> 00:06:57,160
This is great for active passive setups

194
00:06:57,160 --> 00:07:00,120
where you want one region to handle everything unless it fails.

195
00:07:00,120 --> 00:07:01,880
But what if you want both servers active?

196
00:07:01,880 --> 00:07:03,160
That's where latency comes in.

197
00:07:03,160 --> 00:07:05,120
If multiple servers have the same priority,

198
00:07:05,120 --> 00:07:06,760
Front Door sends traffic to the one

199
00:07:06,760 --> 00:07:07,880
with the lowest latency,

200
00:07:07,880 --> 00:07:10,560
the fastest response time from the visitor's location.

201
00:07:10,560 --> 00:07:13,520
So a user in London gets rooted to your European server

202
00:07:13,520 --> 00:07:15,760
while a user in Tokyo gets the Asian one.

203
00:07:15,760 --> 00:07:19,320
There's also a sensitivity setting by default 50 milliseconds.

204
00:07:19,320 --> 00:07:21,960
If two servers are within 50 milliseconds of each other,

205
00:07:21,960 --> 00:07:24,200
Front Door considers them equally fast.

206
00:07:24,200 --> 00:07:26,360
That prevents constant switching between servers

207
00:07:26,360 --> 00:07:28,080
that are basically the same speed.

208
00:07:28,080 --> 00:07:30,440
And when latency is tied, that's where weight comes in.

209
00:07:30,440 --> 00:07:33,640
You can assign weights to split traffic between servers.

210
00:07:33,640 --> 00:07:35,720
Say you want to test a new version of your app.

211
00:07:35,720 --> 00:07:37,680
You could give your current server a weight of 90

212
00:07:37,680 --> 00:07:39,200
and the new one a weight of 10.

213
00:07:39,200 --> 00:07:41,880
That means roughly nine out of 10 visitors go to the old version

214
00:07:41,880 --> 00:07:43,720
and one out of 10 goes to the new one.

215
00:07:43,720 --> 00:07:45,640
This is perfect for gradual roll outs,

216
00:07:45,640 --> 00:07:47,560
A, B testing or just balancing load

217
00:07:47,560 --> 00:07:49,520
across servers with different capacities.

218
00:07:49,520 --> 00:07:50,720
Here's the important thing.

219
00:07:50,720 --> 00:07:52,640
All of this happens automatically.

220
00:07:52,640 --> 00:07:54,320
You configure the origin group once

221
00:07:54,320 --> 00:07:55,960
and Front Door handles the rest.

222
00:07:55,960 --> 00:07:59,240
It probes your servers, measures latency, respects priorities

223
00:07:59,240 --> 00:08:01,200
and distributes traffic based on weight.

224
00:08:01,200 --> 00:08:02,680
And it does all of this at the edge

225
00:08:02,680 --> 00:08:05,000
before the request even reaches your back end.

226
00:08:05,000 --> 00:08:06,960
That means your servers don't have to figure out

227
00:08:06,960 --> 00:08:09,160
where traffic came from or how to root it.

228
00:08:09,160 --> 00:08:10,880
They just serve content.

229
00:08:10,880 --> 00:08:12,880
Security at the edge, the WAF and beyond.

230
00:08:12,880 --> 00:08:14,160
So now let's talk about security.

231
00:08:14,160 --> 00:08:17,160
Because Front Door sits at the very edge of Microsoft's network,

232
00:08:17,160 --> 00:08:19,280
it's the perfect place to stop attacks

233
00:08:19,280 --> 00:08:20,840
before they ever reach your servers.

234
00:08:20,840 --> 00:08:22,360
Think of it as a security checkpoint

235
00:08:22,360 --> 00:08:23,920
at the entrance to a building.

236
00:08:23,920 --> 00:08:26,320
Anyone who wants in has to pass through first.

237
00:08:26,320 --> 00:08:28,920
That checkpoint is called the web application firewall

238
00:08:28,920 --> 00:08:31,760
or WAF and it's built into both Front Door standard

239
00:08:31,760 --> 00:08:32,640
and premium.

240
00:08:32,640 --> 00:08:35,080
It blocks common web attacks automatically.

241
00:08:35,080 --> 00:08:37,400
Things like SQL injection, where an attacker tries

242
00:08:37,400 --> 00:08:40,280
to sneak malicious database commands into a form field

243
00:08:40,280 --> 00:08:42,800
or cross-site scripting, where they inject scripts

244
00:08:42,800 --> 00:08:44,720
into your pages or de-doss attacks,

245
00:08:44,720 --> 00:08:47,240
where they try to overwhelm your servers with traffic.

246
00:08:47,240 --> 00:08:48,840
The WAF catches all of this at the edge

247
00:08:48,840 --> 00:08:51,560
and drops it before your origin ever sees a thing.

248
00:08:51,560 --> 00:08:54,360
Beyond automatic protections, you can also create custom rules.

249
00:08:54,360 --> 00:08:57,320
For example, if your site is only meant for customers in Europe,

250
00:08:57,320 --> 00:08:59,960
you can block traffic from other regions entirely.

251
00:08:59,960 --> 00:09:01,960
Or maybe you've noticed a specific IP range

252
00:09:01,960 --> 00:09:04,720
that keeps probing your site, you can block that too.

253
00:09:04,720 --> 00:09:06,400
You can also filter based on request headers,

254
00:09:06,400 --> 00:09:08,960
URL patterns, or even the browser someone is using,

255
00:09:08,960 --> 00:09:11,480
the WAF gives you very specific control over who gets in

256
00:09:11,480 --> 00:09:12,360
and who doesn't.

257
00:09:12,360 --> 00:09:14,160
Here's where the pricing tears matter.

258
00:09:14,160 --> 00:09:16,000
Standard gives you custom WAF rules

259
00:09:16,000 --> 00:09:18,400
where you define what to block and allow.

260
00:09:18,400 --> 00:09:20,480
Premium goes further by adding managed rule sets

261
00:09:20,480 --> 00:09:22,640
powered by Microsoft threat intelligence,

262
00:09:22,640 --> 00:09:25,200
which are constantly updated based on real-world attack

263
00:09:25,200 --> 00:09:28,560
patterns, Microsoft sees across its entire network.

264
00:09:28,560 --> 00:09:30,440
Premium also includes bot protection

265
00:09:30,440 --> 00:09:32,440
that blocks automated scrapers, credential

266
00:09:32,440 --> 00:09:34,440
stuffers, and other bots automatically.

267
00:09:34,440 --> 00:09:36,520
And it adds private link support, which lets you connect

268
00:09:36,520 --> 00:09:38,440
to your origins over a private network connection

269
00:09:38,440 --> 00:09:39,840
instead of the public internet.

270
00:09:39,840 --> 00:09:42,800
That means your backend servers can be completely hidden

271
00:09:42,800 --> 00:09:44,000
from the outside world.

272
00:09:44,000 --> 00:09:45,520
Only front door can reach them.

273
00:09:45,520 --> 00:09:47,160
This is a big deal for security.

274
00:09:47,160 --> 00:09:49,560
A lot of attacks don't target the front door.

275
00:09:49,560 --> 00:09:51,880
They try to find the back door.

276
00:09:51,880 --> 00:09:54,320
If your origin server has a public IP address,

277
00:09:54,320 --> 00:09:55,800
attackers can probe it directly

278
00:09:55,800 --> 00:09:58,080
and bypass all your front door protections.

279
00:09:58,080 --> 00:09:59,800
With private link, that's not possible

280
00:09:59,800 --> 00:10:01,600
because the origin has no public endpoint

281
00:10:01,600 --> 00:10:03,480
and is only accessible through front door.

282
00:10:03,480 --> 00:10:05,720
So even if someone discovers your server's IP,

283
00:10:05,720 --> 00:10:06,800
they can't reach it.

284
00:10:06,800 --> 00:10:08,440
The result is defense in depth.

285
00:10:08,440 --> 00:10:10,440
The Waffblocks application layer attacks,

286
00:10:10,440 --> 00:10:12,680
custom rules handle your specific requirements,

287
00:10:12,680 --> 00:10:14,640
bot protection stops automated threats,

288
00:10:14,640 --> 00:10:16,840
and private link keeps your origins invisible.

289
00:10:16,840 --> 00:10:18,240
All of this happens at the edge

290
00:10:18,240 --> 00:10:20,160
before traffic even reaches your infrastructure,

291
00:10:20,160 --> 00:10:22,440
so your servers stay focused on serving content,

292
00:10:22,440 --> 00:10:24,080
not fighting off attacks.

293
00:10:24,080 --> 00:10:26,360
Caching, making things even faster.

294
00:10:26,360 --> 00:10:28,160
So we've covered routing and security,

295
00:10:28,160 --> 00:10:29,840
but there's another feature that makes front door

296
00:10:29,840 --> 00:10:30,800
really useful.

297
00:10:30,800 --> 00:10:31,880
Caching.

298
00:10:31,880 --> 00:10:33,880
Here's the idea, a lot of your website content

299
00:10:33,880 --> 00:10:35,240
doesn't change very often.

300
00:10:35,240 --> 00:10:38,720
Images, CSS files, JavaScript libraries, product photos,

301
00:10:38,720 --> 00:10:40,320
maybe even some HTML pages.

302
00:10:40,320 --> 00:10:42,320
If every single visitor has to fetch those

303
00:10:42,320 --> 00:10:45,120
from your origin server, your wasting time and bandwidth

304
00:10:45,120 --> 00:10:47,240
because the server has to process the same request

305
00:10:47,240 --> 00:10:50,160
over and over, sending the same bytes across the internet

306
00:10:50,160 --> 00:10:51,000
each time.

307
00:10:51,000 --> 00:10:52,680
Caching fixes that by keeping a copy

308
00:10:52,680 --> 00:10:54,400
of static content at the edge pop.

309
00:10:54,400 --> 00:10:56,160
The next time someone requests that same file,

310
00:10:56,160 --> 00:10:58,520
the pop serves it instantly without ever contacting

311
00:10:58,520 --> 00:10:59,320
your origin.

312
00:10:59,320 --> 00:11:01,600
It's like having a small warehouse next to every traffic

313
00:11:01,600 --> 00:11:02,440
booth.

314
00:11:02,440 --> 00:11:04,840
Instead of sending every customer back to the main factory,

315
00:11:04,840 --> 00:11:06,720
you just hand them what's already on the shelf.

316
00:11:06,720 --> 00:11:08,280
The performance difference is dramatic.

317
00:11:08,280 --> 00:11:10,080
Instead of a round trip across the ocean,

318
00:11:10,080 --> 00:11:12,560
the response comes from a server in the same city.

319
00:11:12,560 --> 00:11:14,280
Milliseconds instead of seconds.

320
00:11:14,280 --> 00:11:16,160
And your origin server gets a break because it

321
00:11:16,160 --> 00:11:18,760
handles fewer requests and can focus on the dynamic stuff

322
00:11:18,760 --> 00:11:20,080
that actually needs processing.

323
00:11:20,080 --> 00:11:22,280
Now, caching isn't automatic for everything.

324
00:11:22,280 --> 00:11:25,280
You control what gets cached and for how long.

325
00:11:25,280 --> 00:11:27,760
Front door respects standard cache control headers

326
00:11:27,760 --> 00:11:30,480
from your origin, like max-age or smax-age.

327
00:11:30,480 --> 00:11:32,920
And you can also configure caching rules directly,

328
00:11:32,920 --> 00:11:35,040
overriding your origin's headers if needed.

329
00:11:35,040 --> 00:11:36,960
When you update content, you can purge the cache

330
00:11:36,960 --> 00:11:38,840
and tell front door to throw away the old copies

331
00:11:38,840 --> 00:11:40,000
and fetch fresh ones.

332
00:11:40,000 --> 00:11:42,040
That's important for things like product launches or price

333
00:11:42,040 --> 00:11:44,880
changes where the new version needs to be visible immediately.

334
00:11:44,880 --> 00:11:45,800
Here's the thing.

335
00:11:45,800 --> 00:11:47,760
Front door isn't just for static content.

336
00:11:47,760 --> 00:11:50,920
Even for dynamic content like APIs, personalized pages,

337
00:11:50,920 --> 00:11:52,920
or shopping carts, it still accelerates delivery

338
00:11:52,920 --> 00:11:55,280
because once that request hits the nearest pop,

339
00:11:55,280 --> 00:11:58,200
it travels to your origin over Microsoft's private backbone

340
00:11:58,200 --> 00:11:59,720
instead of the public internet.

341
00:11:59,720 --> 00:12:02,040
That private backbone is faster and more reliable

342
00:12:02,040 --> 00:12:03,120
than the open web.

343
00:12:03,120 --> 00:12:05,720
So even uncached requests get a speed boost.

344
00:12:05,720 --> 00:12:08,160
This is one of the key differences between front door

345
00:12:08,160 --> 00:12:09,520
and a traditional CDN.

346
00:12:09,520 --> 00:12:12,120
A CDN caches static content and that's about it.

347
00:12:12,120 --> 00:12:13,840
Front door caches static content

348
00:12:13,840 --> 00:12:15,520
and accelerates everything else.

349
00:12:15,520 --> 00:12:17,000
It's a two for one deal.

350
00:12:17,000 --> 00:12:18,240
Pricing tiers.

351
00:12:18,240 --> 00:12:19,440
Which one to choose?

352
00:12:19,440 --> 00:12:22,000
All right, let's talk money because that's the big question.

353
00:12:22,000 --> 00:12:23,320
How much does this cost?

354
00:12:23,320 --> 00:12:25,120
And which tier should you actually pick?

355
00:12:25,120 --> 00:12:27,320
Before we get into the numbers, here's why this matters.

356
00:12:27,320 --> 00:12:29,960
The tier you choose doesn't just affect the price tag.

357
00:12:29,960 --> 00:12:32,360
It also determines the security and features available

358
00:12:32,360 --> 00:12:33,720
to protect your application.

359
00:12:33,720 --> 00:12:35,600
As your front door comes in three versions,

360
00:12:35,600 --> 00:12:36,720
classic is the old one.

361
00:12:36,720 --> 00:12:39,440
It still works, but Microsoft recommends against using it

362
00:12:39,440 --> 00:12:40,640
for new projects.

363
00:12:40,640 --> 00:12:42,120
Classic is on its way out.

364
00:12:42,120 --> 00:12:47,120
No new resources after 2025 and full retirement by 2027.

365
00:12:47,120 --> 00:12:50,520
So if you're starting fresh, you're looking at standard or premium.

366
00:12:50,520 --> 00:12:51,960
Here's the simplest breakdown.

367
00:12:51,960 --> 00:12:55,120
Standard costs $35 per month as a base fee.

368
00:12:55,120 --> 00:12:57,560
Premium costs $330 per month.

369
00:12:57,560 --> 00:12:58,400
That's a big jump.

370
00:12:58,400 --> 00:12:59,680
But here's the interesting part.

371
00:12:59,680 --> 00:13:02,040
The per gigabyte data transfer rates

372
00:13:02,040 --> 00:13:03,880
are identical between both tiers.

373
00:13:03,880 --> 00:13:05,720
In North America and Europe, outbound traffic

374
00:13:05,720 --> 00:13:07,840
runs about 8.25 cents per gigabyte

375
00:13:07,840 --> 00:13:09,320
for the first 10 terabytes.

376
00:13:09,320 --> 00:13:11,800
Edge to origin transfer is about 2 cents per gigabyte,

377
00:13:11,800 --> 00:13:13,160
same pricing on both.

378
00:13:13,160 --> 00:13:15,920
So what does that extra $300 buy you?

379
00:13:15,920 --> 00:13:16,800
Features?

380
00:13:16,800 --> 00:13:21,000
Premium ads managed waft rules powered by Microsoft threat intelligence,

381
00:13:21,000 --> 00:13:24,360
rules that update automatically based on real attack patterns.

382
00:13:24,360 --> 00:13:26,640
You also get bot protection, private link support,

383
00:13:26,640 --> 00:13:29,000
so your origins stay hidden from the public internet

384
00:13:29,000 --> 00:13:30,800
and deeper security analytics.

385
00:13:30,800 --> 00:13:32,760
Standard gives you global load balancing,

386
00:13:32,760 --> 00:13:36,040
caching, dynamic acceleration, and custom waft rules.

387
00:13:36,040 --> 00:13:39,040
You can block IP ranges, countries, or request patterns.

388
00:13:39,040 --> 00:13:41,600
You just don't get the managed rule sets or private link.

389
00:13:41,600 --> 00:13:43,320
The request charges are different too.

390
00:13:43,320 --> 00:13:47,640
Standard costs about $9 per 10,000 requests for the first $250 million.

391
00:13:47,640 --> 00:13:50,000
Premium cost about $15 per 10,000.

392
00:13:50,000 --> 00:13:51,320
At scale, that difference adds up.

393
00:13:51,320 --> 00:13:52,320
So how do you choose?

394
00:13:52,320 --> 00:13:53,440
Here's my rule of thumb.

395
00:13:53,440 --> 00:13:55,720
If you're running a typical website or API,

396
00:13:55,720 --> 00:13:58,120
something that needs global performance and basic security,

397
00:13:58,120 --> 00:13:59,200
start with standard.

398
00:13:59,200 --> 00:14:01,400
The $35 base fee is affordable,

399
00:14:01,400 --> 00:14:04,400
and the custom waft rules handle most common threats.

400
00:14:04,400 --> 00:14:07,320
You can always upgrade later if your security needs grow.

401
00:14:07,320 --> 00:14:09,040
If you're in a regulated industry,

402
00:14:09,040 --> 00:14:10,920
healthcare, finance, government,

403
00:14:10,920 --> 00:14:13,000
or if you handle sensitive customer data,

404
00:14:13,000 --> 00:14:15,040
premium is worth the extra cost.

405
00:14:15,040 --> 00:14:18,280
The managed waft rules catch threats you might not think to block.

406
00:14:18,280 --> 00:14:20,320
Private link keeps your origins invisible

407
00:14:20,320 --> 00:14:23,520
and bot protection stops automated attacks that standard wouldn't catch.

408
00:14:23,520 --> 00:14:26,080
One last thing, if you're only serving static content

409
00:14:26,080 --> 00:14:27,920
and don't need routing or security features,

410
00:14:27,920 --> 00:14:29,680
a traditional CDN might be cheaper,

411
00:14:29,680 --> 00:14:32,000
as your CDN from Microsoft still exists,

412
00:14:32,000 --> 00:14:35,000
and for pure static delivery, it's often more cost-effective.

413
00:14:35,000 --> 00:14:36,960
But for most real-world applications,

414
00:14:36,960 --> 00:14:40,440
where you need routing, security, caching, and acceleration,

415
00:14:40,440 --> 00:14:42,560
front door standard is the sweet spot.

416
00:14:42,560 --> 00:14:45,120
Putting it all together, a real-world example.

417
00:14:45,120 --> 00:14:47,040
Let me walk you through a real-world scenario

418
00:14:47,040 --> 00:14:49,840
so you can see exactly how all these pieces work together.

419
00:14:49,840 --> 00:14:51,600
Imagine you run an e-commerce site.

420
00:14:51,600 --> 00:14:52,880
You have servers in three regions,

421
00:14:52,880 --> 00:14:54,360
North America, Europe, and Asia.

422
00:14:54,360 --> 00:14:57,840
Your customers are everywhere from Japan to Brazil to South Africa.

423
00:14:57,840 --> 00:14:58,960
Without front door,

424
00:14:58,960 --> 00:15:02,560
a customer in Tokyo connects directly to your US server.

425
00:15:02,560 --> 00:15:04,760
Every image, product page, and checkout request

426
00:15:04,760 --> 00:15:07,120
has to cross the Pacific Ocean, that's slow.

427
00:15:07,120 --> 00:15:08,440
And if your US server goes down,

428
00:15:08,440 --> 00:15:10,000
that customer just sees an error.

429
00:15:10,000 --> 00:15:11,240
Now add front door.

430
00:15:11,240 --> 00:15:13,400
The customer in Tokyo opens your site.

431
00:15:13,400 --> 00:15:15,440
Their browser hits the nearest Azure location.

432
00:15:15,440 --> 00:15:16,600
Let's call it Tokyo.

433
00:15:16,600 --> 00:15:18,760
That location checks the health of your three servers,

434
00:15:18,760 --> 00:15:20,760
all healthy, it measures latency.

435
00:15:20,760 --> 00:15:22,640
The Asian server responds fastest.

436
00:15:22,640 --> 00:15:25,640
So it routes the request there over Microsoft's private backbone.

437
00:15:25,640 --> 00:15:27,880
The page loads in under a second instead of three.

438
00:15:27,880 --> 00:15:30,920
Now imagine the Asian server gets overloaded during a flash sale.

439
00:15:30,920 --> 00:15:34,040
Front door's health probes detect the increased latency.

440
00:15:34,040 --> 00:15:36,520
It starts shifting traffic to the European server,

441
00:15:36,520 --> 00:15:38,080
the next best option.

442
00:15:38,080 --> 00:15:39,920
Customers still get a fast experience,

443
00:15:39,920 --> 00:15:41,840
maybe not quite as fast as the Asian server,

444
00:15:41,840 --> 00:15:44,320
but still faster than going all the way to the US.

445
00:15:44,320 --> 00:15:46,000
The whole failover happens automatically

446
00:15:46,000 --> 00:15:47,960
without anyone touching a configuration.

447
00:15:47,960 --> 00:15:49,640
Meanwhile, the wafer runs at the edge.

448
00:15:49,640 --> 00:15:51,160
It blocks a SQL injection attempt

449
00:15:51,160 --> 00:15:53,360
from a botnet probing your checkout form.

450
00:15:53,360 --> 00:15:56,080
It blocks traffic from known malicious IP ranges.

451
00:15:56,080 --> 00:15:57,920
And it rate limits requests from an IP

452
00:15:57,920 --> 00:15:59,640
that's scraping your product catalog.

453
00:15:59,640 --> 00:16:01,960
None of these attacks ever reach your origin servers.

454
00:16:01,960 --> 00:16:04,000
Your backend team doesn't even know they happened.

455
00:16:04,000 --> 00:16:07,200
And the static content, product images, CSS files,

456
00:16:07,200 --> 00:16:10,280
JavaScript libraries, those get cashed at the Tokyo location.

457
00:16:10,280 --> 00:16:12,720
The first visitor loads them from the Asian origin.

458
00:16:12,720 --> 00:16:15,760
The second visitor gets them from the edge cash instantly.

459
00:16:15,760 --> 00:16:18,040
Repeat visitors see near instant load times

460
00:16:18,040 --> 00:16:19,800
because everything they need is already

461
00:16:19,800 --> 00:16:21,760
sitting at the edge location near them.

462
00:16:21,760 --> 00:16:24,600
All of this, faster routing, automatic failover,

463
00:16:24,600 --> 00:16:27,880
edge security and cashed content, works together seamlessly.

464
00:16:27,880 --> 00:16:29,400
Your customers never know it's there.

465
00:16:29,400 --> 00:16:31,360
They just see a fast, reliable site.

466
00:16:31,360 --> 00:16:32,440
Here's what to remember.

467
00:16:32,440 --> 00:16:34,440
Azure Front Door acts as a global traffic cop

468
00:16:34,440 --> 00:16:35,920
rooting users to the fastest server,

469
00:16:35,920 --> 00:16:38,320
caching content at the edge and blocking attacks

470
00:16:38,320 --> 00:16:39,360
before they reach you.

471
00:16:39,360 --> 00:16:41,240
It's built on three layers of resiliency.

472
00:16:41,240 --> 00:16:44,160
So even if a region goes down, your site stays up.

473
00:16:44,160 --> 00:16:47,400
For most projects, the standard tier at just $35 a month

474
00:16:47,400 --> 00:16:50,080
is the sweet spot between performance and cost.

475
00:16:50,080 --> 00:16:52,360
Upgrade to premium when you need advanced security

476
00:16:52,360 --> 00:16:53,400
or private link.

477
00:16:53,400 --> 00:16:56,280
Start small with a single origin and grow from there.

478
00:16:56,280 --> 00:16:58,120
Front door scales with you.

479
00:16:58,120 --> 00:17:00,240
If your web app has users spread across regions,

480
00:17:00,240 --> 00:17:02,080
set up a front door profile today.

481
00:17:02,080 --> 00:17:04,280
Even a single server gets global acceleration

482
00:17:04,280 --> 00:17:05,400
and security benefits.

483
00:17:05,400 --> 00:17:07,560
Subscribe on your favorite podcast platform

484
00:17:07,560 --> 00:17:10,360
and share this with someone starting their cloud journey.