July 16, 2026
Azure Load Balancer — Simply Explained
Every application starts small. A single virtual machine serves your website, processes customer requests, and handles all incoming traffic. At first, everything works perfectly. But as your user base grows, traffic spikes, maintenance windows, or unexpected server failures quickly expose a major weakness—your entire application depends on one machine. In this episode of m365.fm, we explain Azure Load Balancer in plain English and show how Microsoft distributes network traffic across multiple servers to improve availability, scalability, and reliability. You'll learn why Azure Load Balancer acts like a smart reception desk for your infrastructure, ensuring users are always connected to healthy servers without even realizing anything has changed. Whether you're preparing for Azure certifications or building production cloud applications, this episode gives you a practical understanding of one of Azure's core networking services.
WHY EVERY MODERN APPLICATION NEEDS LOAD BALANCING
Running applications on a single server creates three major risks: downtime, poor performance during traffic spikes, and maintenance interruptions. We explain why adding more servers alone doesn't solve the problem and why a load balancer is needed to intelligently distribute requests across multiple backend systems. Through simple real-world analogies—including a busy restaurant and a reception desk—you'll discover how Azure Load Balancer automatically directs incoming traffic to available virtual machines while protecting users from outages and keeping applications responsive under heavy workloads.
FRONTEND IPS, BACKEND POOLS, HEALTH PROBES, AND RULES
Azure Load Balancer consists of four core building blocks that work together to deliver high availability. This episode explains Frontend IP addresses, Backend Pools, Health Probes, Load Balancing Rules, and Inbound NAT Rules using practical examples that make Azure networking easy to understand. You'll learn how health probes continuously monitor server availability, why unhealthy virtual machines are automatically removed from rotation, and how Azure Load Balancer distributes TCP and UDP traffic using its hash-based load balancing algorithm. We also cover session persistence, client IP affinity, public versus internal load balancers, and why Azure Load Balancer operates at Layer 4 of the OSI networking model.
STANDARD LOAD BALANCER, HIGH AVAILABILITY, AND BEST PRACTICES
Modern Azure deployments almost always use the Standard Load Balancer, which provides zone redundancy, advanced diagnostics, support for up to 1,000 backend instances, and significantly improved resilience compared to the retired Basic SKU. We explain when to use Standard Load Balancer, Gateway Load Balancer, and internal versus internet-facing deployments. You'll also discover common configuration mistakes—including blocked health probes, incorrect Network Security Group rules, SKU mismatches, routing issues, and unnecessary session persistence—and learn how to troubleshoot them before they impact production environments.
AZURE LOAD BALANCER VS. APPLICATION GATEWAY, FRONT DOOR, AND TRAFFIC MANAGER
One of the most common Azure networking questions is choosing the right traffic distribution service. This episode concludes by comparing Azure Load Balancer, Azure Application Gateway, Azure Front Door, and Azure Traffic Manager, explaining where each service fits within a modern Azure architecture. You'll learn why Azure Load Balancer is optimized for Layer 4 TCP/UDP traffic, when Application Gateway becomes the better choice for web applications, and how Front Door and Traffic Manager extend traffic management across multiple Azure regions worldwide. Whether you're designing highly available business applications, building cloud-native services, or preparing for Microsoft Azure certifications, this episode provides the practical foundation needed to confidently deploy Azure Load Balancer and create resilient, scalable cloud infrastructure.
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:04,800
Welcome to another episode of Microsoft Knowledge Nuggets here on M365 FFM, I'm your host,
2
00:00:04,800 --> 00:00:05,800
Mucopeters.
3
00:00:05,800 --> 00:00:09,560
In this series, we take one Microsoft technology and explain it in plain English.
4
00:00:09,560 --> 00:00:13,360
Today's topic is one that almost everyone has heard of, but very few people actually
5
00:00:13,360 --> 00:00:15,680
understand as you're a load balancer.
6
00:00:15,680 --> 00:00:17,840
Imagine running a restaurant with only one chef.
7
00:00:17,840 --> 00:00:19,880
If they call in sick, the kitchen shuts down.
8
00:00:19,880 --> 00:00:24,160
If a crowd shows up, the orders pile up, and nobody gets fed, that's the problem with
9
00:00:24,160 --> 00:00:25,880
running your app on a single server.
10
00:00:25,880 --> 00:00:29,560
Most people think a single server is fine for low traffic apps until it isn't.
11
00:00:29,560 --> 00:00:31,120
And by then, it's too late.
12
00:00:31,120 --> 00:00:34,640
By the end of this episode, you'll understand what Azure Load Balancer actually does, why
13
00:00:34,640 --> 00:00:38,280
you need one, and how it keeps your apps running even when things break.
14
00:00:38,280 --> 00:00:41,160
Think of it as the smart reception desk for your servers.
15
00:00:41,160 --> 00:00:44,640
That mental model is going to carry us through everything that follows.
16
00:00:44,640 --> 00:00:47,840
Why your app needs a bouncer, the case for load balancing?
17
00:00:47,840 --> 00:00:52,080
Here's the thing, when you start a new app, it's easy to just put everything on one server.
18
00:00:52,080 --> 00:00:53,560
One VM handles all the traffic.
19
00:00:53,560 --> 00:00:54,240
It's simple.
20
00:00:54,240 --> 00:00:56,520
It works, until it doesn't.
21
00:00:56,520 --> 00:01:00,440
That single server has three problems it can't solve on its own.
22
00:01:00,440 --> 00:01:02,840
First availability, what if the server crashes?
23
00:01:02,840 --> 00:01:04,040
The app goes down.
24
00:01:04,040 --> 00:01:05,040
Second, performance.
25
00:01:05,040 --> 00:01:06,160
What if traffic spikes?
26
00:01:06,160 --> 00:01:09,240
The server gets overwhelmed and your users get a spinning wheel of death.
27
00:01:09,240 --> 00:01:10,720
Third, maintenance.
28
00:01:10,720 --> 00:01:13,840
How do you update the software without taking the app offline?
29
00:01:13,840 --> 00:01:15,600
You can't, because there's only one server.
30
00:01:15,600 --> 00:01:19,560
The solution is obvious when you step back, spread the work across multiple servers, and
31
00:01:19,560 --> 00:01:23,040
put something in front that decides which server handles each request.
32
00:01:23,040 --> 00:01:24,560
That something is a load balancer.
33
00:01:24,560 --> 00:01:26,280
Let me give you a real example.
34
00:01:26,280 --> 00:01:28,880
Imagine a small e-commerce site during Black Friday.
35
00:01:28,880 --> 00:01:31,880
One server buckles under the traffic, pages load slowly.
36
00:01:31,880 --> 00:01:32,880
Customers leave.
37
00:01:32,880 --> 00:01:36,080
But with multiple servers behind a load balancer, nobody notices.
38
00:01:36,080 --> 00:01:37,080
Traffic gets spread out.
39
00:01:37,080 --> 00:01:40,120
Every server handles its share, and the site stays fast.
40
00:01:40,120 --> 00:01:43,000
One server fails, the load balancer sends traffic to the others.
41
00:01:43,000 --> 00:01:44,440
The customers never even know.
42
00:01:44,440 --> 00:01:46,160
So how does Azure actually do this?
43
00:01:46,160 --> 00:01:47,960
Let's build a mental model.
44
00:01:47,960 --> 00:01:49,320
The Smart Reception Desk.
45
00:01:49,320 --> 00:01:51,560
Your mental model for Azure Load Balancer.
46
00:01:51,560 --> 00:01:54,960
Think of Azure Load Balancer as the reception desk in a busy office building.
47
00:01:54,960 --> 00:01:57,560
The front end IP is the building's street address.
48
00:01:57,560 --> 00:02:00,000
It's the one single door that everyone knocks on.
49
00:02:00,000 --> 00:02:03,200
When someone visits your app, they hit this address, they don't know about the servers behind
50
00:02:03,200 --> 00:02:04,200
the scenes.
51
00:02:04,200 --> 00:02:07,720
The back end pool is the group of employees who actually do the work.
52
00:02:07,720 --> 00:02:08,880
These are your virtual machines.
53
00:02:08,880 --> 00:02:11,440
They sit in the back, ready to handle whatever comes in.
54
00:02:11,440 --> 00:02:15,000
Health probes are the receptionist checking if each employee is awake and able to take
55
00:02:15,000 --> 00:02:16,000
work.
56
00:02:16,000 --> 00:02:20,400
Every few seconds, the receptionist looks over and says, hey, are you still with us?
57
00:02:20,400 --> 00:02:23,960
If an employee doesn't respond, the receptionist stops sending people their way.
58
00:02:23,960 --> 00:02:26,640
Load balancing rules are the instructions for who goes where?
59
00:02:26,640 --> 00:02:31,200
The receptionist has a set of rules that say, anyone asking about billing goes to desk three,
60
00:02:31,200 --> 00:02:33,400
anyone with a delivery goes to desk five.
61
00:02:33,400 --> 00:02:37,880
In Azure, these rules say, anyone hitting port 80 goes to port 80 on a VM in the back end
62
00:02:37,880 --> 00:02:38,880
pool.
63
00:02:38,880 --> 00:02:40,000
Here's the thing to remember.
64
00:02:40,000 --> 00:02:41,760
The load balancer itself doesn't do the work.
65
00:02:41,760 --> 00:02:43,600
It's a traffic cop, not a worker.
66
00:02:43,600 --> 00:02:47,040
It just directs traffic to the servers that actually handle the requests.
67
00:02:47,040 --> 00:02:51,840
It operates at layer four of the network model, which means it works with TCP and UDP traffic.
68
00:02:51,840 --> 00:02:54,720
It doesn't read your web traffic or inspect what's inside the packets.
69
00:02:54,720 --> 00:02:58,280
It just looks at IP addresses and ports and makes a decision.
70
00:02:58,280 --> 00:03:02,280
Now let's break down each part of this reception desk one at a time.
71
00:03:02,280 --> 00:03:04,920
Frontend IP, back end pool and the rules that connect them.
72
00:03:04,920 --> 00:03:08,120
So you've got this reception desk, but how does it actually work?
73
00:03:08,120 --> 00:03:10,480
Let's walk through the three pieces that make it tick.
74
00:03:10,480 --> 00:03:12,120
First, the frontend IP.
75
00:03:12,120 --> 00:03:14,280
This is the address your user actually connect to.
76
00:03:14,280 --> 00:03:19,200
It can be a public IP if your app faces the internet or a private IP if it only lives inside your
77
00:03:19,200 --> 00:03:20,200
virtual network.
78
00:03:20,200 --> 00:03:23,240
You can even have multiple frontend IPs on the same load balancer.
79
00:03:23,240 --> 00:03:26,440
Think of it like having a main entrance and a loading dock, different traffic, different
80
00:03:26,440 --> 00:03:27,960
doors, same building.
81
00:03:27,960 --> 00:03:29,160
Second, the back end pool.
82
00:03:29,160 --> 00:03:32,080
This is where you put your virtual machines or VM scale sets.
83
00:03:32,080 --> 00:03:35,760
The load balancer only sends traffic to members of this pool that are healthy.
84
00:03:35,760 --> 00:03:39,560
If a VM is in the pool but not responding, it doesn't get traffic, simple as that.
85
00:03:39,560 --> 00:03:41,280
Third, the load balancing rules.
86
00:03:41,280 --> 00:03:42,880
These are the glue that connects everything.
87
00:03:42,880 --> 00:03:46,960
A rule says anyone hitting port 80 on this frontend IP gets sent to port 80 on a VM in this
88
00:03:46,960 --> 00:03:48,200
back end pool.
89
00:03:48,200 --> 00:03:49,200
That's it.
90
00:03:49,200 --> 00:03:53,120
You define the frontend, you define the back end and the rule tells the load balancer how
91
00:03:53,120 --> 00:03:54,520
to connect them.
92
00:03:54,520 --> 00:03:55,520
Here's a concrete example.
93
00:03:55,520 --> 00:03:57,840
Say you have a web app running on port 80.
94
00:03:57,840 --> 00:04:01,080
You create a frontend IP, let's call it 40.40404040.
95
00:04:01,080 --> 00:04:03,040
You create a back end pool with two VMs.
96
00:04:03,040 --> 00:04:07,920
Then you create a rule that says traffic to 40404040 on port 80 goes to port 80 on the
97
00:04:07,920 --> 00:04:09,240
back end pool.
98
00:04:09,240 --> 00:04:12,560
Now when someone visits your site, the load balancer picks one of those two VMs and
99
00:04:12,560 --> 00:04:14,080
sends the request there.
100
00:04:14,080 --> 00:04:16,960
There's also something called inbound in-at rules.
101
00:04:16,960 --> 00:04:21,400
These let you map specific ports on the frontend IP to specific VMs in the back end pool.
102
00:04:21,400 --> 00:04:26,400
So if you need to RDP into VM number one, you can hit port 5,001 on the frontend and
103
00:04:26,400 --> 00:04:30,360
the load balancer sends you directly to port 3389 on that VM.
104
00:04:30,360 --> 00:04:32,280
No public IP needed on the VM itself.
105
00:04:32,280 --> 00:04:36,840
It's a clean way to manage remote access without exposing your VMs directly to the internet.
106
00:04:36,840 --> 00:04:40,560
But how does the receptionist know which employee is actually ready to work?
107
00:04:40,560 --> 00:04:42,440
That's where health probes come in.
108
00:04:42,440 --> 00:04:43,440
Who's listening?
109
00:04:43,440 --> 00:04:45,080
Health probes and why they matter.
110
00:04:45,080 --> 00:04:47,760
This is the feature that makes high availability possible.
111
00:04:47,760 --> 00:04:51,440
Without health probes, your load balancer would just blindly send traffic to every server
112
00:04:51,440 --> 00:04:53,200
in the pool, even the dead ones.
113
00:04:53,200 --> 00:04:54,200
Here's how it works.
114
00:04:54,200 --> 00:04:58,000
The load balancer sends a ping to each back end server every few seconds.
115
00:04:58,000 --> 00:05:00,800
Think of it like the receptionist checking in on each employee.
116
00:05:00,800 --> 00:05:01,800
You still there?
117
00:05:01,800 --> 00:05:02,800
You still able to work?
118
00:05:02,800 --> 00:05:05,080
If the server responds great, it stays in rotation.
119
00:05:05,080 --> 00:05:09,000
If it doesn't respond within a certain window, the load balancer removes it from the pool
120
00:05:09,000 --> 00:05:10,000
immediately.
121
00:05:10,000 --> 00:05:12,880
More traffic gets sent to it until it starts responding again.
122
00:05:12,880 --> 00:05:14,120
There are two types of probes.
123
00:05:14,120 --> 00:05:15,840
TCP probes just check if the port is open.
124
00:05:15,840 --> 00:05:17,760
They say, "Hey, is port 80 listening?"
125
00:05:17,760 --> 00:05:19,120
If yes, the server is healthy.
126
00:05:19,120 --> 00:05:22,040
HTTP and HTTPS probes go a step further.
127
00:05:22,040 --> 00:05:25,680
They actually send a request to a specific endpoint and check for a valid response.
128
00:05:25,680 --> 00:05:29,800
This is useful when you want to make sure the application itself is running, not just the
129
00:05:29,800 --> 00:05:30,800
operating system.
130
00:05:30,800 --> 00:05:32,640
Here's where beginners get tripped up.
131
00:05:32,640 --> 00:05:37,400
You set up a probe, you configure everything correctly, but the backend keeps showing as unhealthy.
132
00:05:37,400 --> 00:05:39,920
Nine times out of ten, the problem is the network security group.
133
00:05:39,920 --> 00:05:45,800
The probe traffic comes from a specific Azure IP address, 168.63, 129.16.
134
00:05:45,800 --> 00:05:48,400
If your NSG blocks that IP, the probe can't reach your server.
135
00:05:48,400 --> 00:05:51,640
The server is running fine, but the load balancer thinks it's dead.
136
00:05:51,640 --> 00:05:52,640
Traffic stops flowing.
137
00:05:52,640 --> 00:05:55,720
It's a simple fix once you know to look for it, but it catches almost everyone the first
138
00:05:55,720 --> 00:05:56,720
time.
139
00:05:56,720 --> 00:05:58,360
The real impact of health probes is this.
140
00:05:58,360 --> 00:06:01,120
When a server fails, users see zero downtime.
141
00:06:01,120 --> 00:06:05,920
The load balancer detects the failure, removes that server from rotation, and sends all traffic
142
00:06:05,920 --> 00:06:07,760
to the remaining healthy servers.
143
00:06:07,760 --> 00:06:09,360
Your users never know anything happened.
144
00:06:09,360 --> 00:06:11,040
That's the whole point of a load balancer.
145
00:06:11,040 --> 00:06:14,040
Now how does the load balancer decide which server gets each visitor?
146
00:06:14,040 --> 00:06:15,920
It's not random.
147
00:06:15,920 --> 00:06:17,920
Distribution logic, how traffic gets spread.
148
00:06:17,920 --> 00:06:21,960
So you've got a load balancer, you've got healthy servers in the backend pool, and you've
149
00:06:21,960 --> 00:06:24,200
got health probes keeping everyone honest.
150
00:06:24,200 --> 00:06:27,560
But how does the load balancer actually decide which server gets each visitor?
151
00:06:27,560 --> 00:06:29,320
Here's the thing, most people get wrong.
152
00:06:29,320 --> 00:06:31,600
Azure load balancer does not use round robin.
153
00:06:31,600 --> 00:06:35,040
It doesn't just take turns sending traffic to each server like a schoolteacher calling on
154
00:06:35,040 --> 00:06:36,200
students.
155
00:06:36,200 --> 00:06:39,240
Instead it uses something called a hash based distribution.
156
00:06:39,240 --> 00:06:40,400
Here's how it works.
157
00:06:40,400 --> 00:06:43,560
When a request comes in, the load balancer looks at five things.
158
00:06:43,560 --> 00:06:48,560
The source IP address, the source port, the destination IP address, the destination port,
159
00:06:48,560 --> 00:06:49,560
and the protocol.
160
00:06:49,560 --> 00:06:51,120
That's called the five tuple hash.
161
00:06:51,120 --> 00:06:55,120
It runs those five values through a mathematical function and gets a number.
162
00:06:55,120 --> 00:06:58,160
That number determines which backend server gets the request.
163
00:06:58,160 --> 00:07:00,920
The key insight is that this is per flow, not per packet.
164
00:07:00,920 --> 00:07:03,560
Every packet in a single connection goes to the same backend server.
165
00:07:03,560 --> 00:07:07,680
You don't want packets from the same user session bouncing between different servers.
166
00:07:07,680 --> 00:07:08,680
That would break things.
167
00:07:08,680 --> 00:07:13,040
Once the load balancer decides which server handles a connection, all packets in that connection
168
00:07:13,040 --> 00:07:14,400
stay with that server.
169
00:07:14,400 --> 00:07:17,840
Now there's something called session persistence or client IP affinity.
170
00:07:17,840 --> 00:07:21,880
When you enable this, all requests from the same client go to the same backend server.
171
00:07:21,880 --> 00:07:23,800
This is important for stateful applications.
172
00:07:23,800 --> 00:07:24,840
Think about a shopping cart.
173
00:07:24,840 --> 00:07:27,480
You add items, you browse around, you come back.
174
00:07:27,480 --> 00:07:31,160
If each request went to a different server, your cart would keep disappearing.
175
00:07:31,160 --> 00:07:34,880
Session persistence keeps you tied to one server, so your state stays intact.
176
00:07:34,880 --> 00:07:35,880
But here's the catch.
177
00:07:35,880 --> 00:07:39,160
Your load balancer does not enable session persistence by default.
178
00:07:39,160 --> 00:07:43,360
You have to explicitly turn it on and you should only do that when you actually need it.
179
00:07:43,360 --> 00:07:46,560
Because session persistence can cause uneven traffic distribution.
180
00:07:46,560 --> 00:07:50,800
If one client makes a thousand requests, they all go to the same server, even if the other
181
00:07:50,800 --> 00:07:52,280
servers are sitting idle.
182
00:07:52,280 --> 00:07:56,360
For most applications, the default hash based distribution is actually better.
183
00:07:56,360 --> 00:08:00,400
It spreads traffic more evenly across your backend servers, especially when you have a large
184
00:08:00,400 --> 00:08:01,720
number of connections.
185
00:08:01,720 --> 00:08:06,000
So to summarize, hash based distribution, per flow routing and session persistence only
186
00:08:06,000 --> 00:08:07,000
when you need it.
187
00:08:07,000 --> 00:08:08,480
That's how traffic gets spread.
188
00:08:08,480 --> 00:08:11,480
The load balancer we've been talking about handles traffic from the internet.
189
00:08:11,480 --> 00:08:14,120
But what about traffic between your own services?
190
00:08:14,120 --> 00:08:16,800
Public versus internal, two flavors, same engine.
191
00:08:16,800 --> 00:08:19,760
So far, we've been talking about a public load balancer.
192
00:08:19,760 --> 00:08:23,560
Someone on the internet hits your front end IP and the load balancer sends them to a backend
193
00:08:23,560 --> 00:08:24,560
server.
194
00:08:24,560 --> 00:08:25,560
But that's only half the story.
195
00:08:25,560 --> 00:08:30,000
There are actually two flavors of Azure load balancer and they use the exact same engine.
196
00:08:30,000 --> 00:08:31,440
The only difference is the front end.
197
00:08:31,440 --> 00:08:34,680
A public load balancer has a front end with a public IP address.
198
00:08:34,680 --> 00:08:38,120
Users from anywhere on the internet can hit that IP and reach your application.
199
00:08:38,120 --> 00:08:41,520
This is what you use for anything that faces the outside world.
200
00:08:41,520 --> 00:08:44,160
Your website, your API, your customer facing app.
201
00:08:44,160 --> 00:08:48,560
An internal load balancer has a front end with a private IP inside your virtual network.
202
00:08:48,560 --> 00:08:50,560
Only resources inside your vnet can reach it.
203
00:08:50,560 --> 00:08:51,560
No internet access.
204
00:08:51,560 --> 00:08:53,600
This is what you use for internal services.
205
00:08:53,600 --> 00:08:57,920
Your databases, your APIs between application tiers, your microservices that talk to each other
206
00:08:57,920 --> 00:08:59,160
behind the scenes.
207
00:08:59,160 --> 00:09:00,360
Here's where it gets interesting.
208
00:09:00,360 --> 00:09:02,360
Both types use the exact same logic.
209
00:09:02,360 --> 00:09:03,680
Both use health probes.
210
00:09:03,680 --> 00:09:05,600
Both use the same distribution algorithm.
211
00:09:05,600 --> 00:09:07,480
Both support the same rules and features.
212
00:09:07,480 --> 00:09:09,840
The only difference is the IP address at the front.
213
00:09:09,840 --> 00:09:11,720
Public or private, that's it.
214
00:09:11,720 --> 00:09:13,720
In a real world architecture, you'd use both.
215
00:09:13,720 --> 00:09:17,720
A public load balancer at the web tier handles incoming traffic from users.
216
00:09:17,720 --> 00:09:21,760
Behind that, your web servers process requests and send them to an internal load balancer
217
00:09:21,760 --> 00:09:23,560
at the business logic tier.
218
00:09:23,560 --> 00:09:27,240
That internal load balancer distributes work across your application servers.
219
00:09:27,240 --> 00:09:31,920
So behind those, another internal load balancer might connect to your database cluster.
220
00:09:31,920 --> 00:09:35,680
Each tier gets its own load balancer and traffic flows from public to private.
221
00:09:35,680 --> 00:09:37,480
Each step handled by the right tool.
222
00:09:37,480 --> 00:09:40,320
But Azure gives you more than one type of load balancer.
223
00:09:40,320 --> 00:09:44,400
Let's clear up the difference between standard gateway and the retired one.
224
00:09:44,400 --> 00:09:46,840
Standard versus gateway versus the dead basic.
225
00:09:46,840 --> 00:09:49,480
So we've covered public and internal load balancers.
226
00:09:49,480 --> 00:09:53,040
But Azure actually gives you three different types of load balancers and knowing which one
227
00:09:53,040 --> 00:09:54,040
to use matters.
228
00:09:54,040 --> 00:09:58,200
The one you should use for pretty much everything new is the standard load balancer.
229
00:09:58,200 --> 00:10:02,200
It's zone redundant, meaning it can survive an entire Azure data center going down.
230
00:10:02,200 --> 00:10:06,800
It supports HA ports, which lets you load balance all ports and protocols at once for things
231
00:10:06,800 --> 00:10:08,520
like network virtual appliances.
232
00:10:08,520 --> 00:10:12,040
It can handle up to a thousand backend instances in a single pool.
233
00:10:12,040 --> 00:10:15,160
And it gives you advanced diagnostics so you can actually see what's happening with your
234
00:10:15,160 --> 00:10:16,160
traffic.
235
00:10:16,160 --> 00:10:17,440
Standard is the default choice.
236
00:10:17,440 --> 00:10:19,560
If you're building something new, start here.
237
00:10:19,560 --> 00:10:21,480
Then there's the gateway load balancer.
238
00:10:21,480 --> 00:10:22,720
This one is more specialized.
239
00:10:22,720 --> 00:10:26,320
It's not designed to distribute traffic directly to your application servers.
240
00:10:26,320 --> 00:10:29,560
Instead it's a middleman that hands traffic off to a security appliance before it reaches
241
00:10:29,560 --> 00:10:30,560
your app.
242
00:10:30,560 --> 00:10:34,240
Think firewalls, intrusion detection systems or packet inspection tools.
243
00:10:34,240 --> 00:10:37,880
The gateway load balancer sits in the traffic path, sends everything through the appliance
244
00:10:37,880 --> 00:10:40,360
first and then forwards the clean traffic to your application.
245
00:10:40,360 --> 00:10:42,320
You don't need this for a simple web app.
246
00:10:42,320 --> 00:10:46,320
But if you have strict security requirements and need to chain multiple network appliances
247
00:10:46,320 --> 00:10:48,280
together, this is the tool.
248
00:10:48,280 --> 00:10:49,920
And then there's the basic load balancer.
249
00:10:49,920 --> 00:10:50,920
Don't use it.
250
00:10:50,920 --> 00:10:51,920
You can use it for a simple web app.
251
00:10:51,920 --> 00:10:52,920
You can use it for a simple web app.
252
00:10:52,920 --> 00:10:53,920
You can use it for a simple web app.
253
00:10:53,920 --> 00:10:54,920
You can use it for a simple web app.
254
00:10:54,920 --> 00:10:55,920
You can use it for a simple web app.
255
00:10:55,920 --> 00:10:56,920
You can use it for a simple web app.
256
00:10:56,920 --> 00:10:57,920
You can use it for a simple web app.
257
00:10:57,920 --> 00:10:58,920
You can use it for a simple web app.
258
00:10:58,920 --> 00:10:59,920
You can use it for a simple web app.
259
00:10:59,920 --> 00:11:00,920
You can use it for a simple web app.
260
00:11:00,920 --> 00:11:01,920
You can use it for a simple web app.
261
00:11:01,920 --> 00:11:02,920
You can use it for a simple web app.
262
00:11:02,920 --> 00:11:03,920
You can use it for a simple web app.
263
00:11:03,920 --> 00:11:04,920
You can use it for a simple web app.
264
00:11:04,920 --> 00:11:05,920
You can use it for a simple web app.
265
00:11:05,920 --> 00:11:06,920
You can use it for a simple web app.
266
00:11:06,920 --> 00:11:07,920
You can use it for a simple web app.
267
00:11:07,920 --> 00:11:08,920
You can use it for a simple web app.
268
00:11:08,920 --> 00:11:23,920
You can use it for a simple web app.
269
00:11:23,920 --> 00:11:24,920
You can use it for a simple web app.
270
00:11:24,920 --> 00:11:26,920
You can use it for a simple web app.
271
00:11:26,920 --> 00:11:27,920
You can use it for a simple web app.
272
00:11:27,920 --> 00:11:28,920
You can use it for a simple web app.
273
00:11:28,920 --> 00:11:30,920
You can use it for a simple web app.
274
00:11:30,920 --> 00:11:31,920
You can use it for a simple web app.
275
00:11:31,920 --> 00:11:32,920
You can use it for a simple web app.
276
00:11:32,920 --> 00:11:33,920
You can use it for a simple web app.
277
00:11:33,920 --> 00:11:34,920
You can use it for a simple web app.
278
00:11:34,920 --> 00:11:35,920
You can use it for a simple web app.
279
00:11:35,920 --> 00:11:36,920
You can use it for a simple web app.
280
00:11:36,920 --> 00:11:37,920
You can use it for a simple web app.
281
00:11:37,920 --> 00:11:40,920
You can figure the health probe, but the backend servers keep showing as unhealthy.
282
00:11:40,920 --> 00:11:44,920
Nine times out of ten, the problem is that your NSG is blocking the probe traffic.
283
00:11:44,920 --> 00:11:49,920
The probe comes from a specific Azure IP address 168.63, 129.16.
284
00:11:49,920 --> 00:11:52,920
If that IP isn't allowed in your NSG rules, the probe can't reach your server.
285
00:11:52,920 --> 00:11:55,920
The server is running fine, but the load balancer thinks it's dead.
286
00:11:55,920 --> 00:11:56,920
The server is running fine, but the load balancer thinks it's dead.
287
00:11:56,920 --> 00:11:57,920
The server is running fine, but the load balancer thinks it's dead.
288
00:11:57,920 --> 00:12:01,920
The fix is simple, just add an inbound rule that allows traffic from that Azure IP on your probe port.
289
00:12:01,920 --> 00:12:02,920
The fix is simple, just add an inbound rule that allows traffic from that Azure IP on your probe port.
290
00:12:02,920 --> 00:12:03,920
That's it.
291
00:12:03,920 --> 00:12:04,920
Next up is the wrong probe protocol of port.
292
00:12:04,920 --> 00:12:09,920
You set up a TCP probe on port 80, but your application is actually listening on port 8080.
293
00:12:09,920 --> 00:12:14,920
The probe checks port 80, gets no response, and marks the server as unhealthy.
294
00:12:14,920 --> 00:12:15,920
The server is fine.
295
00:12:15,920 --> 00:12:17,920
The probe is just looking in the wrong place.
296
00:12:17,920 --> 00:12:20,920
Make sure your probe protocol and port match what your application is actually doing.
297
00:12:20,920 --> 00:12:23,920
If your app listens on 8080, probe port 8080.
298
00:12:23,920 --> 00:12:27,920
If your app expects an HTTP response, use an HTTP probe instead of TCP.
299
00:12:27,920 --> 00:12:31,920
As QMS match is another common one, you create a standard load balancer,
300
00:12:31,920 --> 00:12:36,920
but attach a basic public IP. They don't match, and the deployment fails or behaves unpredictably.
301
00:12:36,920 --> 00:12:38,920
The rule is simple. Keep your SKUs consistent.
302
00:12:38,920 --> 00:12:43,920
Standard with standard, basic with basic, and since basic is retired, just use standard for everything.
303
00:12:43,920 --> 00:12:46,920
Session persistence left on by mistake can cause uneven traffic distribution.
304
00:12:46,920 --> 00:12:49,920
You enable sticky sessions because you read somewhere that it's good for performance,
305
00:12:49,920 --> 00:12:51,920
but your application doesn't actually need it.
306
00:12:51,920 --> 00:12:54,920
Now one server gets hammered with traffic while the other sit idle.
307
00:12:54,920 --> 00:12:57,920
The fix is to understand your application's state requirements.
308
00:12:57,920 --> 00:13:01,920
If your app stores session state in a database or distributed cache,
309
00:13:01,920 --> 00:13:04,920
you don't need session persistence at the load balancer level.
310
00:13:04,920 --> 00:13:06,920
Only enable it when you absolutely have to.
311
00:13:06,920 --> 00:13:10,920
User defined routes or UDRs can silently break your load balancer.
312
00:13:10,920 --> 00:13:14,920
You set up a custom root table that sends traffic through a firewall or a network appliance.
313
00:13:14,920 --> 00:13:17,920
The problem is that your probe traffic also follows those routes.
314
00:13:17,920 --> 00:13:20,920
If the root sends probe packets somewhere they shouldn't go,
315
00:13:20,920 --> 00:13:23,920
the backend appears unhealthy even though the application is running perfectly.
316
00:13:23,920 --> 00:13:27,920
Always check your root tables when troubleshooting load balancer issues.
317
00:13:27,920 --> 00:13:28,920
And here's a classic one.
318
00:13:28,920 --> 00:13:31,920
Someone sets up a load balancer with a single VM in the backend pool.
319
00:13:31,920 --> 00:13:35,920
They tested traffic flows, everything looks good, then they stopped the VM to simulate a failure,
320
00:13:35,920 --> 00:13:36,920
and the app goes down.
321
00:13:36,920 --> 00:13:38,920
They think the load balancer is broken.
322
00:13:38,920 --> 00:13:42,920
It's not. A load balancer with one backend server provides zero redundancy.
323
00:13:42,920 --> 00:13:45,920
If that server goes down, there's nowhere else to send traffic.
324
00:13:45,920 --> 00:13:47,920
Always have at least two instances in your backend pool.
325
00:13:47,920 --> 00:13:50,920
That's the whole point of having a load balancer in the first place.
326
00:13:50,920 --> 00:13:54,920
So here's your troubleshooting checklist. Check the NSG rules, check the probe protocol in port,
327
00:13:54,920 --> 00:13:59,920
check the root tables, and check the application health directly from another VM in the same network.
328
00:13:59,920 --> 00:14:02,920
Nine times out of ten, the problem is in one of those four places.
329
00:14:02,920 --> 00:14:06,920
When to choose load balancer versus app gateway versus traffic manager.
330
00:14:06,920 --> 00:14:08,920
So you understand what a load balancer does.
331
00:14:08,920 --> 00:14:12,920
But as your actually gives you four different services for distributing traffic,
332
00:14:12,920 --> 00:14:15,920
and each one has a specific job as your load balancer is layer four.
333
00:14:15,920 --> 00:14:19,920
It handles any TCP or UDP protocol within a single region.
334
00:14:19,920 --> 00:14:23,920
Use it for internal services, non-HTTP workloads, or when you just need simple distribution.
335
00:14:23,920 --> 00:14:24,920
It's your foundation.
336
00:14:24,920 --> 00:14:28,920
Application gateway is layer seven HTP and HTTP only.
337
00:14:28,920 --> 00:14:34,920
Think of it like a hotel concierge who knows exactly where each guest should go based on what they're asking for.
338
00:14:34,920 --> 00:14:37,920
It can route traffic by URL path, handle SSL termination,
339
00:14:37,920 --> 00:14:40,920
and protect your web apps with a web application firewall.
340
00:14:40,920 --> 00:14:43,920
Use it when you need smart routing for web traffic.
341
00:14:43,920 --> 00:14:47,920
Traffic manager works at the DNS level. It's like a travel agent who sends you to the nearest office.
342
00:14:47,920 --> 00:14:50,920
If your users are in Europe, it routes them to your European servers.
343
00:14:50,920 --> 00:14:54,920
If your European data center goes down, it sends them to the next closest region.
344
00:14:54,920 --> 00:14:57,920
As your front door is the global version of application gateway.
345
00:14:57,920 --> 00:15:01,920
It gives you layer seven routing, acceleration, and WAF protection at the edge.
346
00:15:01,920 --> 00:15:05,920
Use it for global web applications where performance and security matter.
347
00:15:05,920 --> 00:15:07,920
Here's the practical rule of thumb.
348
00:15:07,920 --> 00:15:09,920
Use load balancer for non-HTTP traffic.
349
00:15:09,920 --> 00:15:12,920
Use application gateway for web apps in one region.
350
00:15:12,920 --> 00:15:14,920
Use front door or traffic manager for global distribution.
351
00:15:14,920 --> 00:15:20,920
Start with load balancer as your foundation and layer the other services on top as your needs grow.
352
00:15:20,920 --> 00:15:22,920
So now you have it.
353
00:15:22,920 --> 00:15:25,920
Azure load balancer is the smart reception desk for your servers.
354
00:15:25,920 --> 00:15:27,920
The front end IP is the door everyone knocks on.
355
00:15:27,920 --> 00:15:30,920
The backend pool is your team doing the work and health probes keep everyone honest.
356
00:15:30,920 --> 00:15:33,920
Next time you set up a VM in Azure, ask yourself one question.
357
00:15:33,920 --> 00:15:35,920
What happens if this one VM fails?
358
00:15:35,920 --> 00:15:37,920
If the answer is downtime, you need a load balancer.
359
00:15:37,920 --> 00:15:41,920
Start with a standard load balancer in front of at least two VMs.
360
00:15:41,920 --> 00:15:42,920
Add health probes.
361
00:15:42,920 --> 00:15:45,920
Test by stopping one VM and watch the traffic keep flowing.
362
00:15:45,920 --> 00:15:47,920
That's all for this episode of Microsoft Knowledge Nuggets.
363
00:15:47,920 --> 00:15:51,920
Subscribe on your favorite podcast platform and share this with someone starting their journey.
364
00:15:51,920 --> 00:15:53,920
Next time we'll cover application gateway.
365
00:15:53,920 --> 00:15:54,920
Simply explained.
00:00:00,000 --> 00:00:04,800
Welcome to another episode of Microsoft Knowledge Nuggets here on M365 FFM, I'm your host,
2
00:00:04,800 --> 00:00:05,800
Mucopeters.
3
00:00:05,800 --> 00:00:09,560
In this series, we take one Microsoft technology and explain it in plain English.
4
00:00:09,560 --> 00:00:13,360
Today's topic is one that almost everyone has heard of, but very few people actually
5
00:00:13,360 --> 00:00:15,680
understand as you're a load balancer.
6
00:00:15,680 --> 00:00:17,840
Imagine running a restaurant with only one chef.
7
00:00:17,840 --> 00:00:19,880
If they call in sick, the kitchen shuts down.
8
00:00:19,880 --> 00:00:24,160
If a crowd shows up, the orders pile up, and nobody gets fed, that's the problem with
9
00:00:24,160 --> 00:00:25,880
running your app on a single server.
10
00:00:25,880 --> 00:00:29,560
Most people think a single server is fine for low traffic apps until it isn't.
11
00:00:29,560 --> 00:00:31,120
And by then, it's too late.
12
00:00:31,120 --> 00:00:34,640
By the end of this episode, you'll understand what Azure Load Balancer actually does, why
13
00:00:34,640 --> 00:00:38,280
you need one, and how it keeps your apps running even when things break.
14
00:00:38,280 --> 00:00:41,160
Think of it as the smart reception desk for your servers.
15
00:00:41,160 --> 00:00:44,640
That mental model is going to carry us through everything that follows.
16
00:00:44,640 --> 00:00:47,840
Why your app needs a bouncer, the case for load balancing?
17
00:00:47,840 --> 00:00:52,080
Here's the thing, when you start a new app, it's easy to just put everything on one server.
18
00:00:52,080 --> 00:00:53,560
One VM handles all the traffic.
19
00:00:53,560 --> 00:00:54,240
It's simple.
20
00:00:54,240 --> 00:00:56,520
It works, until it doesn't.
21
00:00:56,520 --> 00:01:00,440
That single server has three problems it can't solve on its own.
22
00:01:00,440 --> 00:01:02,840
First availability, what if the server crashes?
23
00:01:02,840 --> 00:01:04,040
The app goes down.
24
00:01:04,040 --> 00:01:05,040
Second, performance.
25
00:01:05,040 --> 00:01:06,160
What if traffic spikes?
26
00:01:06,160 --> 00:01:09,240
The server gets overwhelmed and your users get a spinning wheel of death.
27
00:01:09,240 --> 00:01:10,720
Third, maintenance.
28
00:01:10,720 --> 00:01:13,840
How do you update the software without taking the app offline?
29
00:01:13,840 --> 00:01:15,600
You can't, because there's only one server.
30
00:01:15,600 --> 00:01:19,560
The solution is obvious when you step back, spread the work across multiple servers, and
31
00:01:19,560 --> 00:01:23,040
put something in front that decides which server handles each request.
32
00:01:23,040 --> 00:01:24,560
That something is a load balancer.
33
00:01:24,560 --> 00:01:26,280
Let me give you a real example.
34
00:01:26,280 --> 00:01:28,880
Imagine a small e-commerce site during Black Friday.
35
00:01:28,880 --> 00:01:31,880
One server buckles under the traffic, pages load slowly.
36
00:01:31,880 --> 00:01:32,880
Customers leave.
37
00:01:32,880 --> 00:01:36,080
But with multiple servers behind a load balancer, nobody notices.
38
00:01:36,080 --> 00:01:37,080
Traffic gets spread out.
39
00:01:37,080 --> 00:01:40,120
Every server handles its share, and the site stays fast.
40
00:01:40,120 --> 00:01:43,000
One server fails, the load balancer sends traffic to the others.
41
00:01:43,000 --> 00:01:44,440
The customers never even know.
42
00:01:44,440 --> 00:01:46,160
So how does Azure actually do this?
43
00:01:46,160 --> 00:01:47,960
Let's build a mental model.
44
00:01:47,960 --> 00:01:49,320
The Smart Reception Desk.
45
00:01:49,320 --> 00:01:51,560
Your mental model for Azure Load Balancer.
46
00:01:51,560 --> 00:01:54,960
Think of Azure Load Balancer as the reception desk in a busy office building.
47
00:01:54,960 --> 00:01:57,560
The front end IP is the building's street address.
48
00:01:57,560 --> 00:02:00,000
It's the one single door that everyone knocks on.
49
00:02:00,000 --> 00:02:03,200
When someone visits your app, they hit this address, they don't know about the servers behind
50
00:02:03,200 --> 00:02:04,200
the scenes.
51
00:02:04,200 --> 00:02:07,720
The back end pool is the group of employees who actually do the work.
52
00:02:07,720 --> 00:02:08,880
These are your virtual machines.
53
00:02:08,880 --> 00:02:11,440
They sit in the back, ready to handle whatever comes in.
54
00:02:11,440 --> 00:02:15,000
Health probes are the receptionist checking if each employee is awake and able to take
55
00:02:15,000 --> 00:02:16,000
work.
56
00:02:16,000 --> 00:02:20,400
Every few seconds, the receptionist looks over and says, hey, are you still with us?
57
00:02:20,400 --> 00:02:23,960
If an employee doesn't respond, the receptionist stops sending people their way.
58
00:02:23,960 --> 00:02:26,640
Load balancing rules are the instructions for who goes where?
59
00:02:26,640 --> 00:02:31,200
The receptionist has a set of rules that say, anyone asking about billing goes to desk three,
60
00:02:31,200 --> 00:02:33,400
anyone with a delivery goes to desk five.
61
00:02:33,400 --> 00:02:37,880
In Azure, these rules say, anyone hitting port 80 goes to port 80 on a VM in the back end
62
00:02:37,880 --> 00:02:38,880
pool.
63
00:02:38,880 --> 00:02:40,000
Here's the thing to remember.
64
00:02:40,000 --> 00:02:41,760
The load balancer itself doesn't do the work.
65
00:02:41,760 --> 00:02:43,600
It's a traffic cop, not a worker.
66
00:02:43,600 --> 00:02:47,040
It just directs traffic to the servers that actually handle the requests.
67
00:02:47,040 --> 00:02:51,840
It operates at layer four of the network model, which means it works with TCP and UDP traffic.
68
00:02:51,840 --> 00:02:54,720
It doesn't read your web traffic or inspect what's inside the packets.
69
00:02:54,720 --> 00:02:58,280
It just looks at IP addresses and ports and makes a decision.
70
00:02:58,280 --> 00:03:02,280
Now let's break down each part of this reception desk one at a time.
71
00:03:02,280 --> 00:03:04,920
Frontend IP, back end pool and the rules that connect them.
72
00:03:04,920 --> 00:03:08,120
So you've got this reception desk, but how does it actually work?
73
00:03:08,120 --> 00:03:10,480
Let's walk through the three pieces that make it tick.
74
00:03:10,480 --> 00:03:12,120
First, the frontend IP.
75
00:03:12,120 --> 00:03:14,280
This is the address your user actually connect to.
76
00:03:14,280 --> 00:03:19,200
It can be a public IP if your app faces the internet or a private IP if it only lives inside your
77
00:03:19,200 --> 00:03:20,200
virtual network.
78
00:03:20,200 --> 00:03:23,240
You can even have multiple frontend IPs on the same load balancer.
79
00:03:23,240 --> 00:03:26,440
Think of it like having a main entrance and a loading dock, different traffic, different
80
00:03:26,440 --> 00:03:27,960
doors, same building.
81
00:03:27,960 --> 00:03:29,160
Second, the back end pool.
82
00:03:29,160 --> 00:03:32,080
This is where you put your virtual machines or VM scale sets.
83
00:03:32,080 --> 00:03:35,760
The load balancer only sends traffic to members of this pool that are healthy.
84
00:03:35,760 --> 00:03:39,560
If a VM is in the pool but not responding, it doesn't get traffic, simple as that.
85
00:03:39,560 --> 00:03:41,280
Third, the load balancing rules.
86
00:03:41,280 --> 00:03:42,880
These are the glue that connects everything.
87
00:03:42,880 --> 00:03:46,960
A rule says anyone hitting port 80 on this frontend IP gets sent to port 80 on a VM in this
88
00:03:46,960 --> 00:03:48,200
back end pool.
89
00:03:48,200 --> 00:03:49,200
That's it.
90
00:03:49,200 --> 00:03:53,120
You define the frontend, you define the back end and the rule tells the load balancer how
91
00:03:53,120 --> 00:03:54,520
to connect them.
92
00:03:54,520 --> 00:03:55,520
Here's a concrete example.
93
00:03:55,520 --> 00:03:57,840
Say you have a web app running on port 80.
94
00:03:57,840 --> 00:04:01,080
You create a frontend IP, let's call it 40.40404040.
95
00:04:01,080 --> 00:04:03,040
You create a back end pool with two VMs.
96
00:04:03,040 --> 00:04:07,920
Then you create a rule that says traffic to 40404040 on port 80 goes to port 80 on the
97
00:04:07,920 --> 00:04:09,240
back end pool.
98
00:04:09,240 --> 00:04:12,560
Now when someone visits your site, the load balancer picks one of those two VMs and
99
00:04:12,560 --> 00:04:14,080
sends the request there.
100
00:04:14,080 --> 00:04:16,960
There's also something called inbound in-at rules.
101
00:04:16,960 --> 00:04:21,400
These let you map specific ports on the frontend IP to specific VMs in the back end pool.
102
00:04:21,400 --> 00:04:26,400
So if you need to RDP into VM number one, you can hit port 5,001 on the frontend and
103
00:04:26,400 --> 00:04:30,360
the load balancer sends you directly to port 3389 on that VM.
104
00:04:30,360 --> 00:04:32,280
No public IP needed on the VM itself.
105
00:04:32,280 --> 00:04:36,840
It's a clean way to manage remote access without exposing your VMs directly to the internet.
106
00:04:36,840 --> 00:04:40,560
But how does the receptionist know which employee is actually ready to work?
107
00:04:40,560 --> 00:04:42,440
That's where health probes come in.
108
00:04:42,440 --> 00:04:43,440
Who's listening?
109
00:04:43,440 --> 00:04:45,080
Health probes and why they matter.
110
00:04:45,080 --> 00:04:47,760
This is the feature that makes high availability possible.
111
00:04:47,760 --> 00:04:51,440
Without health probes, your load balancer would just blindly send traffic to every server
112
00:04:51,440 --> 00:04:53,200
in the pool, even the dead ones.
113
00:04:53,200 --> 00:04:54,200
Here's how it works.
114
00:04:54,200 --> 00:04:58,000
The load balancer sends a ping to each back end server every few seconds.
115
00:04:58,000 --> 00:05:00,800
Think of it like the receptionist checking in on each employee.
116
00:05:00,800 --> 00:05:01,800
You still there?
117
00:05:01,800 --> 00:05:02,800
You still able to work?
118
00:05:02,800 --> 00:05:05,080
If the server responds great, it stays in rotation.
119
00:05:05,080 --> 00:05:09,000
If it doesn't respond within a certain window, the load balancer removes it from the pool
120
00:05:09,000 --> 00:05:10,000
immediately.
121
00:05:10,000 --> 00:05:12,880
More traffic gets sent to it until it starts responding again.
122
00:05:12,880 --> 00:05:14,120
There are two types of probes.
123
00:05:14,120 --> 00:05:15,840
TCP probes just check if the port is open.
124
00:05:15,840 --> 00:05:17,760
They say, "Hey, is port 80 listening?"
125
00:05:17,760 --> 00:05:19,120
If yes, the server is healthy.
126
00:05:19,120 --> 00:05:22,040
HTTP and HTTPS probes go a step further.
127
00:05:22,040 --> 00:05:25,680
They actually send a request to a specific endpoint and check for a valid response.
128
00:05:25,680 --> 00:05:29,800
This is useful when you want to make sure the application itself is running, not just the
129
00:05:29,800 --> 00:05:30,800
operating system.
130
00:05:30,800 --> 00:05:32,640
Here's where beginners get tripped up.
131
00:05:32,640 --> 00:05:37,400
You set up a probe, you configure everything correctly, but the backend keeps showing as unhealthy.
132
00:05:37,400 --> 00:05:39,920
Nine times out of ten, the problem is the network security group.
133
00:05:39,920 --> 00:05:45,800
The probe traffic comes from a specific Azure IP address, 168.63, 129.16.
134
00:05:45,800 --> 00:05:48,400
If your NSG blocks that IP, the probe can't reach your server.
135
00:05:48,400 --> 00:05:51,640
The server is running fine, but the load balancer thinks it's dead.
136
00:05:51,640 --> 00:05:52,640
Traffic stops flowing.
137
00:05:52,640 --> 00:05:55,720
It's a simple fix once you know to look for it, but it catches almost everyone the first
138
00:05:55,720 --> 00:05:56,720
time.
139
00:05:56,720 --> 00:05:58,360
The real impact of health probes is this.
140
00:05:58,360 --> 00:06:01,120
When a server fails, users see zero downtime.
141
00:06:01,120 --> 00:06:05,920
The load balancer detects the failure, removes that server from rotation, and sends all traffic
142
00:06:05,920 --> 00:06:07,760
to the remaining healthy servers.
143
00:06:07,760 --> 00:06:09,360
Your users never know anything happened.
144
00:06:09,360 --> 00:06:11,040
That's the whole point of a load balancer.
145
00:06:11,040 --> 00:06:14,040
Now how does the load balancer decide which server gets each visitor?
146
00:06:14,040 --> 00:06:15,920
It's not random.
147
00:06:15,920 --> 00:06:17,920
Distribution logic, how traffic gets spread.
148
00:06:17,920 --> 00:06:21,960
So you've got a load balancer, you've got healthy servers in the backend pool, and you've
149
00:06:21,960 --> 00:06:24,200
got health probes keeping everyone honest.
150
00:06:24,200 --> 00:06:27,560
But how does the load balancer actually decide which server gets each visitor?
151
00:06:27,560 --> 00:06:29,320
Here's the thing, most people get wrong.
152
00:06:29,320 --> 00:06:31,600
Azure load balancer does not use round robin.
153
00:06:31,600 --> 00:06:35,040
It doesn't just take turns sending traffic to each server like a schoolteacher calling on
154
00:06:35,040 --> 00:06:36,200
students.
155
00:06:36,200 --> 00:06:39,240
Instead it uses something called a hash based distribution.
156
00:06:39,240 --> 00:06:40,400
Here's how it works.
157
00:06:40,400 --> 00:06:43,560
When a request comes in, the load balancer looks at five things.
158
00:06:43,560 --> 00:06:48,560
The source IP address, the source port, the destination IP address, the destination port,
159
00:06:48,560 --> 00:06:49,560
and the protocol.
160
00:06:49,560 --> 00:06:51,120
That's called the five tuple hash.
161
00:06:51,120 --> 00:06:55,120
It runs those five values through a mathematical function and gets a number.
162
00:06:55,120 --> 00:06:58,160
That number determines which backend server gets the request.
163
00:06:58,160 --> 00:07:00,920
The key insight is that this is per flow, not per packet.
164
00:07:00,920 --> 00:07:03,560
Every packet in a single connection goes to the same backend server.
165
00:07:03,560 --> 00:07:07,680
You don't want packets from the same user session bouncing between different servers.
166
00:07:07,680 --> 00:07:08,680
That would break things.
167
00:07:08,680 --> 00:07:13,040
Once the load balancer decides which server handles a connection, all packets in that connection
168
00:07:13,040 --> 00:07:14,400
stay with that server.
169
00:07:14,400 --> 00:07:17,840
Now there's something called session persistence or client IP affinity.
170
00:07:17,840 --> 00:07:21,880
When you enable this, all requests from the same client go to the same backend server.
171
00:07:21,880 --> 00:07:23,800
This is important for stateful applications.
172
00:07:23,800 --> 00:07:24,840
Think about a shopping cart.
173
00:07:24,840 --> 00:07:27,480
You add items, you browse around, you come back.
174
00:07:27,480 --> 00:07:31,160
If each request went to a different server, your cart would keep disappearing.
175
00:07:31,160 --> 00:07:34,880
Session persistence keeps you tied to one server, so your state stays intact.
176
00:07:34,880 --> 00:07:35,880
But here's the catch.
177
00:07:35,880 --> 00:07:39,160
Your load balancer does not enable session persistence by default.
178
00:07:39,160 --> 00:07:43,360
You have to explicitly turn it on and you should only do that when you actually need it.
179
00:07:43,360 --> 00:07:46,560
Because session persistence can cause uneven traffic distribution.
180
00:07:46,560 --> 00:07:50,800
If one client makes a thousand requests, they all go to the same server, even if the other
181
00:07:50,800 --> 00:07:52,280
servers are sitting idle.
182
00:07:52,280 --> 00:07:56,360
For most applications, the default hash based distribution is actually better.
183
00:07:56,360 --> 00:08:00,400
It spreads traffic more evenly across your backend servers, especially when you have a large
184
00:08:00,400 --> 00:08:01,720
number of connections.
185
00:08:01,720 --> 00:08:06,000
So to summarize, hash based distribution, per flow routing and session persistence only
186
00:08:06,000 --> 00:08:07,000
when you need it.
187
00:08:07,000 --> 00:08:08,480
That's how traffic gets spread.
188
00:08:08,480 --> 00:08:11,480
The load balancer we've been talking about handles traffic from the internet.
189
00:08:11,480 --> 00:08:14,120
But what about traffic between your own services?
190
00:08:14,120 --> 00:08:16,800
Public versus internal, two flavors, same engine.
191
00:08:16,800 --> 00:08:19,760
So far, we've been talking about a public load balancer.
192
00:08:19,760 --> 00:08:23,560
Someone on the internet hits your front end IP and the load balancer sends them to a backend
193
00:08:23,560 --> 00:08:24,560
server.
194
00:08:24,560 --> 00:08:25,560
But that's only half the story.
195
00:08:25,560 --> 00:08:30,000
There are actually two flavors of Azure load balancer and they use the exact same engine.
196
00:08:30,000 --> 00:08:31,440
The only difference is the front end.
197
00:08:31,440 --> 00:08:34,680
A public load balancer has a front end with a public IP address.
198
00:08:34,680 --> 00:08:38,120
Users from anywhere on the internet can hit that IP and reach your application.
199
00:08:38,120 --> 00:08:41,520
This is what you use for anything that faces the outside world.
200
00:08:41,520 --> 00:08:44,160
Your website, your API, your customer facing app.
201
00:08:44,160 --> 00:08:48,560
An internal load balancer has a front end with a private IP inside your virtual network.
202
00:08:48,560 --> 00:08:50,560
Only resources inside your vnet can reach it.
203
00:08:50,560 --> 00:08:51,560
No internet access.
204
00:08:51,560 --> 00:08:53,600
This is what you use for internal services.
205
00:08:53,600 --> 00:08:57,920
Your databases, your APIs between application tiers, your microservices that talk to each other
206
00:08:57,920 --> 00:08:59,160
behind the scenes.
207
00:08:59,160 --> 00:09:00,360
Here's where it gets interesting.
208
00:09:00,360 --> 00:09:02,360
Both types use the exact same logic.
209
00:09:02,360 --> 00:09:03,680
Both use health probes.
210
00:09:03,680 --> 00:09:05,600
Both use the same distribution algorithm.
211
00:09:05,600 --> 00:09:07,480
Both support the same rules and features.
212
00:09:07,480 --> 00:09:09,840
The only difference is the IP address at the front.
213
00:09:09,840 --> 00:09:11,720
Public or private, that's it.
214
00:09:11,720 --> 00:09:13,720
In a real world architecture, you'd use both.
215
00:09:13,720 --> 00:09:17,720
A public load balancer at the web tier handles incoming traffic from users.
216
00:09:17,720 --> 00:09:21,760
Behind that, your web servers process requests and send them to an internal load balancer
217
00:09:21,760 --> 00:09:23,560
at the business logic tier.
218
00:09:23,560 --> 00:09:27,240
That internal load balancer distributes work across your application servers.
219
00:09:27,240 --> 00:09:31,920
So behind those, another internal load balancer might connect to your database cluster.
220
00:09:31,920 --> 00:09:35,680
Each tier gets its own load balancer and traffic flows from public to private.
221
00:09:35,680 --> 00:09:37,480
Each step handled by the right tool.
222
00:09:37,480 --> 00:09:40,320
But Azure gives you more than one type of load balancer.
223
00:09:40,320 --> 00:09:44,400
Let's clear up the difference between standard gateway and the retired one.
224
00:09:44,400 --> 00:09:46,840
Standard versus gateway versus the dead basic.
225
00:09:46,840 --> 00:09:49,480
So we've covered public and internal load balancers.
226
00:09:49,480 --> 00:09:53,040
But Azure actually gives you three different types of load balancers and knowing which one
227
00:09:53,040 --> 00:09:54,040
to use matters.
228
00:09:54,040 --> 00:09:58,200
The one you should use for pretty much everything new is the standard load balancer.
229
00:09:58,200 --> 00:10:02,200
It's zone redundant, meaning it can survive an entire Azure data center going down.
230
00:10:02,200 --> 00:10:06,800
It supports HA ports, which lets you load balance all ports and protocols at once for things
231
00:10:06,800 --> 00:10:08,520
like network virtual appliances.
232
00:10:08,520 --> 00:10:12,040
It can handle up to a thousand backend instances in a single pool.
233
00:10:12,040 --> 00:10:15,160
And it gives you advanced diagnostics so you can actually see what's happening with your
234
00:10:15,160 --> 00:10:16,160
traffic.
235
00:10:16,160 --> 00:10:17,440
Standard is the default choice.
236
00:10:17,440 --> 00:10:19,560
If you're building something new, start here.
237
00:10:19,560 --> 00:10:21,480
Then there's the gateway load balancer.
238
00:10:21,480 --> 00:10:22,720
This one is more specialized.
239
00:10:22,720 --> 00:10:26,320
It's not designed to distribute traffic directly to your application servers.
240
00:10:26,320 --> 00:10:29,560
Instead it's a middleman that hands traffic off to a security appliance before it reaches
241
00:10:29,560 --> 00:10:30,560
your app.
242
00:10:30,560 --> 00:10:34,240
Think firewalls, intrusion detection systems or packet inspection tools.
243
00:10:34,240 --> 00:10:37,880
The gateway load balancer sits in the traffic path, sends everything through the appliance
244
00:10:37,880 --> 00:10:40,360
first and then forwards the clean traffic to your application.
245
00:10:40,360 --> 00:10:42,320
You don't need this for a simple web app.
246
00:10:42,320 --> 00:10:46,320
But if you have strict security requirements and need to chain multiple network appliances
247
00:10:46,320 --> 00:10:48,280
together, this is the tool.
248
00:10:48,280 --> 00:10:49,920
And then there's the basic load balancer.
249
00:10:49,920 --> 00:10:50,920
Don't use it.
250
00:10:50,920 --> 00:10:51,920
You can use it for a simple web app.
251
00:10:51,920 --> 00:10:52,920
You can use it for a simple web app.
252
00:10:52,920 --> 00:10:53,920
You can use it for a simple web app.
253
00:10:53,920 --> 00:10:54,920
You can use it for a simple web app.
254
00:10:54,920 --> 00:10:55,920
You can use it for a simple web app.
255
00:10:55,920 --> 00:10:56,920
You can use it for a simple web app.
256
00:10:56,920 --> 00:10:57,920
You can use it for a simple web app.
257
00:10:57,920 --> 00:10:58,920
You can use it for a simple web app.
258
00:10:58,920 --> 00:10:59,920
You can use it for a simple web app.
259
00:10:59,920 --> 00:11:00,920
You can use it for a simple web app.
260
00:11:00,920 --> 00:11:01,920
You can use it for a simple web app.
261
00:11:01,920 --> 00:11:02,920
You can use it for a simple web app.
262
00:11:02,920 --> 00:11:03,920
You can use it for a simple web app.
263
00:11:03,920 --> 00:11:04,920
You can use it for a simple web app.
264
00:11:04,920 --> 00:11:05,920
You can use it for a simple web app.
265
00:11:05,920 --> 00:11:06,920
You can use it for a simple web app.
266
00:11:06,920 --> 00:11:07,920
You can use it for a simple web app.
267
00:11:07,920 --> 00:11:08,920
You can use it for a simple web app.
268
00:11:08,920 --> 00:11:23,920
You can use it for a simple web app.
269
00:11:23,920 --> 00:11:24,920
You can use it for a simple web app.
270
00:11:24,920 --> 00:11:26,920
You can use it for a simple web app.
271
00:11:26,920 --> 00:11:27,920
You can use it for a simple web app.
272
00:11:27,920 --> 00:11:28,920
You can use it for a simple web app.
273
00:11:28,920 --> 00:11:30,920
You can use it for a simple web app.
274
00:11:30,920 --> 00:11:31,920
You can use it for a simple web app.
275
00:11:31,920 --> 00:11:32,920
You can use it for a simple web app.
276
00:11:32,920 --> 00:11:33,920
You can use it for a simple web app.
277
00:11:33,920 --> 00:11:34,920
You can use it for a simple web app.
278
00:11:34,920 --> 00:11:35,920
You can use it for a simple web app.
279
00:11:35,920 --> 00:11:36,920
You can use it for a simple web app.
280
00:11:36,920 --> 00:11:37,920
You can use it for a simple web app.
281
00:11:37,920 --> 00:11:40,920
You can figure the health probe, but the backend servers keep showing as unhealthy.
282
00:11:40,920 --> 00:11:44,920
Nine times out of ten, the problem is that your NSG is blocking the probe traffic.
283
00:11:44,920 --> 00:11:49,920
The probe comes from a specific Azure IP address 168.63, 129.16.
284
00:11:49,920 --> 00:11:52,920
If that IP isn't allowed in your NSG rules, the probe can't reach your server.
285
00:11:52,920 --> 00:11:55,920
The server is running fine, but the load balancer thinks it's dead.
286
00:11:55,920 --> 00:11:56,920
The server is running fine, but the load balancer thinks it's dead.
287
00:11:56,920 --> 00:11:57,920
The server is running fine, but the load balancer thinks it's dead.
288
00:11:57,920 --> 00:12:01,920
The fix is simple, just add an inbound rule that allows traffic from that Azure IP on your probe port.
289
00:12:01,920 --> 00:12:02,920
The fix is simple, just add an inbound rule that allows traffic from that Azure IP on your probe port.
290
00:12:02,920 --> 00:12:03,920
That's it.
291
00:12:03,920 --> 00:12:04,920
Next up is the wrong probe protocol of port.
292
00:12:04,920 --> 00:12:09,920
You set up a TCP probe on port 80, but your application is actually listening on port 8080.
293
00:12:09,920 --> 00:12:14,920
The probe checks port 80, gets no response, and marks the server as unhealthy.
294
00:12:14,920 --> 00:12:15,920
The server is fine.
295
00:12:15,920 --> 00:12:17,920
The probe is just looking in the wrong place.
296
00:12:17,920 --> 00:12:20,920
Make sure your probe protocol and port match what your application is actually doing.
297
00:12:20,920 --> 00:12:23,920
If your app listens on 8080, probe port 8080.
298
00:12:23,920 --> 00:12:27,920
If your app expects an HTTP response, use an HTTP probe instead of TCP.
299
00:12:27,920 --> 00:12:31,920
As QMS match is another common one, you create a standard load balancer,
300
00:12:31,920 --> 00:12:36,920
but attach a basic public IP. They don't match, and the deployment fails or behaves unpredictably.
301
00:12:36,920 --> 00:12:38,920
The rule is simple. Keep your SKUs consistent.
302
00:12:38,920 --> 00:12:43,920
Standard with standard, basic with basic, and since basic is retired, just use standard for everything.
303
00:12:43,920 --> 00:12:46,920
Session persistence left on by mistake can cause uneven traffic distribution.
304
00:12:46,920 --> 00:12:49,920
You enable sticky sessions because you read somewhere that it's good for performance,
305
00:12:49,920 --> 00:12:51,920
but your application doesn't actually need it.
306
00:12:51,920 --> 00:12:54,920
Now one server gets hammered with traffic while the other sit idle.
307
00:12:54,920 --> 00:12:57,920
The fix is to understand your application's state requirements.
308
00:12:57,920 --> 00:13:01,920
If your app stores session state in a database or distributed cache,
309
00:13:01,920 --> 00:13:04,920
you don't need session persistence at the load balancer level.
310
00:13:04,920 --> 00:13:06,920
Only enable it when you absolutely have to.
311
00:13:06,920 --> 00:13:10,920
User defined routes or UDRs can silently break your load balancer.
312
00:13:10,920 --> 00:13:14,920
You set up a custom root table that sends traffic through a firewall or a network appliance.
313
00:13:14,920 --> 00:13:17,920
The problem is that your probe traffic also follows those routes.
314
00:13:17,920 --> 00:13:20,920
If the root sends probe packets somewhere they shouldn't go,
315
00:13:20,920 --> 00:13:23,920
the backend appears unhealthy even though the application is running perfectly.
316
00:13:23,920 --> 00:13:27,920
Always check your root tables when troubleshooting load balancer issues.
317
00:13:27,920 --> 00:13:28,920
And here's a classic one.
318
00:13:28,920 --> 00:13:31,920
Someone sets up a load balancer with a single VM in the backend pool.
319
00:13:31,920 --> 00:13:35,920
They tested traffic flows, everything looks good, then they stopped the VM to simulate a failure,
320
00:13:35,920 --> 00:13:36,920
and the app goes down.
321
00:13:36,920 --> 00:13:38,920
They think the load balancer is broken.
322
00:13:38,920 --> 00:13:42,920
It's not. A load balancer with one backend server provides zero redundancy.
323
00:13:42,920 --> 00:13:45,920
If that server goes down, there's nowhere else to send traffic.
324
00:13:45,920 --> 00:13:47,920
Always have at least two instances in your backend pool.
325
00:13:47,920 --> 00:13:50,920
That's the whole point of having a load balancer in the first place.
326
00:13:50,920 --> 00:13:54,920
So here's your troubleshooting checklist. Check the NSG rules, check the probe protocol in port,
327
00:13:54,920 --> 00:13:59,920
check the root tables, and check the application health directly from another VM in the same network.
328
00:13:59,920 --> 00:14:02,920
Nine times out of ten, the problem is in one of those four places.
329
00:14:02,920 --> 00:14:06,920
When to choose load balancer versus app gateway versus traffic manager.
330
00:14:06,920 --> 00:14:08,920
So you understand what a load balancer does.
331
00:14:08,920 --> 00:14:12,920
But as your actually gives you four different services for distributing traffic,
332
00:14:12,920 --> 00:14:15,920
and each one has a specific job as your load balancer is layer four.
333
00:14:15,920 --> 00:14:19,920
It handles any TCP or UDP protocol within a single region.
334
00:14:19,920 --> 00:14:23,920
Use it for internal services, non-HTTP workloads, or when you just need simple distribution.
335
00:14:23,920 --> 00:14:24,920
It's your foundation.
336
00:14:24,920 --> 00:14:28,920
Application gateway is layer seven HTP and HTTP only.
337
00:14:28,920 --> 00:14:34,920
Think of it like a hotel concierge who knows exactly where each guest should go based on what they're asking for.
338
00:14:34,920 --> 00:14:37,920
It can route traffic by URL path, handle SSL termination,
339
00:14:37,920 --> 00:14:40,920
and protect your web apps with a web application firewall.
340
00:14:40,920 --> 00:14:43,920
Use it when you need smart routing for web traffic.
341
00:14:43,920 --> 00:14:47,920
Traffic manager works at the DNS level. It's like a travel agent who sends you to the nearest office.
342
00:14:47,920 --> 00:14:50,920
If your users are in Europe, it routes them to your European servers.
343
00:14:50,920 --> 00:14:54,920
If your European data center goes down, it sends them to the next closest region.
344
00:14:54,920 --> 00:14:57,920
As your front door is the global version of application gateway.
345
00:14:57,920 --> 00:15:01,920
It gives you layer seven routing, acceleration, and WAF protection at the edge.
346
00:15:01,920 --> 00:15:05,920
Use it for global web applications where performance and security matter.
347
00:15:05,920 --> 00:15:07,920
Here's the practical rule of thumb.
348
00:15:07,920 --> 00:15:09,920
Use load balancer for non-HTTP traffic.
349
00:15:09,920 --> 00:15:12,920
Use application gateway for web apps in one region.
350
00:15:12,920 --> 00:15:14,920
Use front door or traffic manager for global distribution.
351
00:15:14,920 --> 00:15:20,920
Start with load balancer as your foundation and layer the other services on top as your needs grow.
352
00:15:20,920 --> 00:15:22,920
So now you have it.
353
00:15:22,920 --> 00:15:25,920
Azure load balancer is the smart reception desk for your servers.
354
00:15:25,920 --> 00:15:27,920
The front end IP is the door everyone knocks on.
355
00:15:27,920 --> 00:15:30,920
The backend pool is your team doing the work and health probes keep everyone honest.
356
00:15:30,920 --> 00:15:33,920
Next time you set up a VM in Azure, ask yourself one question.
357
00:15:33,920 --> 00:15:35,920
What happens if this one VM fails?
358
00:15:35,920 --> 00:15:37,920
If the answer is downtime, you need a load balancer.
359
00:15:37,920 --> 00:15:41,920
Start with a standard load balancer in front of at least two VMs.
360
00:15:41,920 --> 00:15:42,920
Add health probes.
361
00:15:42,920 --> 00:15:45,920
Test by stopping one VM and watch the traffic keep flowing.
362
00:15:45,920 --> 00:15:47,920
That's all for this episode of Microsoft Knowledge Nuggets.
363
00:15:47,920 --> 00:15:51,920
Subscribe on your favorite podcast platform and share this with someone starting their journey.
364
00:15:51,920 --> 00:15:53,920
Next time we'll cover application gateway.
365
00:15:53,920 --> 00:15:54,920
Simply explained.
