July 17, 2026
Azure Private Link - Simply Explained
Azure Private Link is Microsoft's networking service that enables secure, private connectivity between your Azure Virtual Network and Azure Platform-as-a-Service (PaaS) resources such as Azure Storage, Azure SQL Database, Key Vault, Cosmos DB, and many other services. Instead of accessing these services through their default public endpoints, Private Link creates a private endpoint with its own private IP address inside your virtual network. As a result, all traffic remains on Microsoft's private backbone network and never traverses the public internet, significantly reducing your attack surface while improving security and compliance.
WHY PRIVATE LINK EXISTS
Many Azure services are internet-accessible by default. Even if your virtual machines and storage accounts exist within the same Azure subscription, communication with a Storage Account or SQL Database normally uses a public endpoint protected only by authentication and firewall rules. While encrypted, the network path still travels over public internet infrastructure. Azure Private Link eliminates this unnecessary exposure by providing a direct private connection. Instead of routing traffic outside your virtual network and back into Azure, communication stays entirely within Microsoft's global backbone, creating a far more secure architecture for sensitive workloads and regulated environments.
HOW PRIVATE ENDPOINTS AND PRIVATE DNS WORK
The foundation of Azure Private Link is the Private Endpoint, a virtual network interface that receives a private IP address from your subnet. Your applications continue using the same Azure service URL, but Azure automatically redirects DNS resolution through a Private DNS Zone. Instead of resolving to a public IP address, the service name resolves to the private endpoint inside your virtual network. From the application's perspective, nothing changes—the connection string remains identical—but the network path is completely different. Traffic flows directly from your workload to the private endpoint and across Microsoft's private backbone, completely bypassing the public internet.
PRIVATE LINK VS VPN, EXPRESSROUTE, AND SERVICE ENDPOINTS
Azure Private Link is often confused with other networking technologies, but each serves a different purpose. VPN Gateway securely connects on-premises networks to Azure over the public internet. ExpressRoute provides a dedicated private connection into Microsoft's network but does not automatically privatize Azure PaaS services. Service Endpoints restrict which virtual networks can access a public endpoint, but the service itself still remains publicly reachable. Azure Private Link goes one step further by assigning a private IP directly inside your virtual network, removing public exposure entirely. For maximum security, many enterprise architectures combine ExpressRoute with Private Link to achieve fully private connectivity from on-premises environments to Azure services.
PRIVATE LINK ISN'T JUST FOR MICROSOFT SERVICES
Azure Private Link also enables organizations to publish their own applications privately through Private Link Service. Instead of exposing applications behind public load balancers or building complex VPN connections for every customer, software vendors can publish services through a Standard Load Balancer and allow customers to connect using their own private endpoints. This creates secure, private connectivity between separate Azure environments without network peering or public internet exposure. It has become an increasingly popular solution for SaaS providers that need to deliver enterprise-grade connectivity while maintaining strict security and isolation between customers.
SECURITY, COMPLIANCE, AND BEST PRACTICES
Azure Private Link dramatically reduces network exposure by eliminating public endpoints for sensitive Azure services. However, one common mistake is assuming that creating a private endpoint automatically disables the public endpoint—it does not. Administrators should explicitly disable public network access after validating the private connection. Proper Private DNS configuration is equally important, especially for hybrid environments where on-premises clients require DNS forwarding or Azure DNS Private Resolver. While Private Link introduces additional costs for private endpoints and data processing, it provides substantial security benefits for production workloads, financial services, healthcare, government organizations, and any environment where compliance, Zero Trust networking, and data privacy are business-critical requirements.
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:03,640
Welcome to another episode of Microsoft Knowledge Nudgets here on M365.
2
00:00:03,640 --> 00:00:05,440
FM, I'm your host, Mirko Peters.
3
00:00:05,440 --> 00:00:07,560
Today's topic is one that almost everyone has heard of,
4
00:00:07,560 --> 00:00:09,320
but few can explain clearly.
5
00:00:09,320 --> 00:00:10,840
Azure Private Link.
6
00:00:10,840 --> 00:00:13,120
You've probably seen the option when setting up a storage account
7
00:00:13,120 --> 00:00:14,480
or a SQL database.
8
00:00:14,480 --> 00:00:15,600
But what does it actually do?
9
00:00:15,600 --> 00:00:16,840
And do you really need it?
10
00:00:16,840 --> 00:00:18,480
Here's the thing most people get wrong.
11
00:00:18,480 --> 00:00:21,120
They assume that because the service runs inside Azure,
12
00:00:21,120 --> 00:00:22,360
it's automatically private,
13
00:00:22,360 --> 00:00:24,720
that it somehow walled off from the internet by default.
14
00:00:24,720 --> 00:00:26,560
That's not true, not even close.
15
00:00:27,520 --> 00:00:30,960
Most as your past services, storage, SQL, key vault,
16
00:00:30,960 --> 00:00:33,320
they ship with a public endpoint right out of the box.
17
00:00:33,320 --> 00:00:35,520
That means anyone on the internet can reach them
18
00:00:35,520 --> 00:00:38,280
as long as they have the right URL and credentials.
19
00:00:38,280 --> 00:00:39,760
By the end of this episode,
20
00:00:39,760 --> 00:00:41,840
you'll understand what private link actually is,
21
00:00:41,840 --> 00:00:45,560
why it exists and how it keeps your traffic off the public internet.
22
00:00:45,560 --> 00:00:47,360
We'll break it down using simple analogies.
23
00:00:47,360 --> 00:00:50,480
No marketing fluff, no jargon, just plain English.
24
00:00:50,480 --> 00:00:52,920
The old way, public endpoints everywhere.
25
00:00:52,920 --> 00:00:54,640
Let's start with the problem.
26
00:00:54,640 --> 00:00:57,600
Before private link existed, every Azure PASS service
27
00:00:57,600 --> 00:00:59,440
got a public endpoint by default.
28
00:00:59,440 --> 00:01:00,600
You create a storage account,
29
00:01:00,600 --> 00:01:03,600
Azure gives you something like my storage account.
30
00:01:03,600 --> 00:01:05,400
Blob.co.windows.net,
31
00:01:05,400 --> 00:01:07,720
that URL resolves to a public IP address.
32
00:01:07,720 --> 00:01:09,960
Anyone with internet access can try to connect to it.
33
00:01:09,960 --> 00:01:12,640
Now imagine you have a virtual machine running inside your own
34
00:01:12,640 --> 00:01:14,200
Azure Virtual Network,
35
00:01:14,200 --> 00:01:16,880
that VM needs to read some files from Blob Storage.
36
00:01:16,880 --> 00:01:19,240
You'd think the traffic would stay inside Azure, right?
37
00:01:19,240 --> 00:01:21,000
Both resources are in the same cloud,
38
00:01:21,000 --> 00:01:22,320
but that's not how it works.
39
00:01:22,320 --> 00:01:24,400
The VM has to leave your virtual network
40
00:01:24,400 --> 00:01:25,920
go out over the public internet
41
00:01:25,920 --> 00:01:28,920
and then come back into Azure to reach that storage account.
42
00:01:28,920 --> 00:01:31,360
It's like you're standing in one room of an office building
43
00:01:31,360 --> 00:01:34,480
and you need to get something from the supply closet in the same building.
44
00:01:34,480 --> 00:01:35,760
But instead of walking down the hallway,
45
00:01:35,760 --> 00:01:37,600
you have to go outside, walk around the block,
46
00:01:37,600 --> 00:01:39,080
and come back in through a different door.
47
00:01:39,080 --> 00:01:41,160
It makes no sense, but that's exactly what was happening.
48
00:01:41,160 --> 00:01:42,320
This is a real problem.
49
00:01:42,320 --> 00:01:44,520
Your data is traveling over the public internet.
50
00:01:44,520 --> 00:01:47,960
Even though both resources are sitting inside Microsoft's own data centers,
51
00:01:47,960 --> 00:01:49,800
that traffic is encrypted, sure.
52
00:01:49,800 --> 00:01:51,520
But it's still exposed to the open internet.
53
00:01:51,520 --> 00:01:55,160
It's still passing through routers and switches that you don't control.
54
00:01:55,160 --> 00:01:57,240
And if someone managed to intercept that traffic,
55
00:01:57,240 --> 00:01:58,880
they could see what you're sending.
56
00:01:58,880 --> 00:02:00,360
There's a common myth here.
57
00:02:00,360 --> 00:02:01,320
A lot of people think,
58
00:02:01,320 --> 00:02:03,680
well, it's in my subscription, so it's private.
59
00:02:03,680 --> 00:02:04,920
That's not how it works.
60
00:02:04,920 --> 00:02:06,880
Your subscription is a billing and management boundary,
61
00:02:06,880 --> 00:02:07,960
not a network boundary.
62
00:02:07,960 --> 00:02:11,120
By default, your Azure services are reachable from the internet.
63
00:02:11,120 --> 00:02:14,520
The only thing protecting them is the authentication and authorization layer,
64
00:02:14,520 --> 00:02:17,200
the keys, the passwords, the firewall rules.
65
00:02:17,200 --> 00:02:18,880
But the network path itself is public.
66
00:02:18,880 --> 00:02:20,440
So Microsoft looked at this and said,
67
00:02:20,440 --> 00:02:21,720
there has to be a better way.
68
00:02:21,720 --> 00:02:22,480
And they built it.
69
00:02:22,480 --> 00:02:24,080
They called it private link.
70
00:02:24,080 --> 00:02:27,320
The solution, private endpoint as a network interface card.
71
00:02:27,320 --> 00:02:29,120
Private link is the overall service,
72
00:02:29,120 --> 00:02:32,480
but the core piece you need to understand is the private endpoint,
73
00:02:32,480 --> 00:02:37,240
a virtual network interface card or NIC that sits inside your virtual network
74
00:02:37,240 --> 00:02:39,280
and connects to a past service.
75
00:02:39,280 --> 00:02:40,360
Here's how it works.
76
00:02:40,360 --> 00:02:42,840
You create a private endpoint for your storage account,
77
00:02:42,840 --> 00:02:46,080
and as your builds a virtual nick inside your virtual network
78
00:02:46,080 --> 00:02:48,480
with a private IP from your subnet,
79
00:02:48,480 --> 00:02:52,640
that NIC connects to the storage account through private link on the backend.
80
00:02:52,640 --> 00:02:57,440
So from your VM's viewpoint, the storage account now looks like it lives inside your own network
81
00:02:57,440 --> 00:03:00,440
with a private IP, just like any other resource.
82
00:03:00,440 --> 00:03:02,840
When your VM sends traffic to that storage account,
83
00:03:02,840 --> 00:03:07,520
it hits the private IP of the NIC and travels over the Microsoft backbone network.
84
00:03:07,520 --> 00:03:09,120
Never the public internet.
85
00:03:09,120 --> 00:03:11,400
It never leaves Azure's internal infrastructure.
86
00:03:11,400 --> 00:03:13,960
Think of it like that secure hallway in the office building.
87
00:03:13,960 --> 00:03:18,600
Instead of walking outside and around the block, you just walk down the corridor into the supply closet.
88
00:03:18,600 --> 00:03:20,920
Direct connection, no detour.
89
00:03:20,920 --> 00:03:23,000
Now here's a nuance, a lot of people miss.
90
00:03:23,000 --> 00:03:27,200
Enabling a private endpoint does not turn off the public endpoint automatically.
91
00:03:27,200 --> 00:03:28,760
They can both exist at the same time.
92
00:03:28,760 --> 00:03:30,200
If you create a private endpoint,
93
00:03:30,200 --> 00:03:32,280
but never touch the public endpoint settings,
94
00:03:32,280 --> 00:03:34,760
your storage account is still reachable from the internet.
95
00:03:34,760 --> 00:03:38,480
You have to explicitly disable public network access to lock it down completely.
96
00:03:38,480 --> 00:03:40,840
Many people think creating the private endpoint is enough.
97
00:03:40,840 --> 00:03:41,680
It's not.
98
00:03:41,680 --> 00:03:44,040
You have to tell Azure, I only want private access.
99
00:03:44,040 --> 00:03:46,120
Let me clear up another myth while we're here.
100
00:03:46,120 --> 00:03:49,120
Private link is not the same as a VPN or express route.
101
00:03:49,120 --> 00:03:52,440
They solve different problems and we'll get into that comparison later.
102
00:03:52,440 --> 00:03:55,800
For now, just know private link is about accessing a specific service,
103
00:03:55,800 --> 00:03:58,000
not connecting your whole network to Azure.
104
00:03:58,000 --> 00:04:02,840
So you've got your private endpoint and your VM can reach the storage account over a private IP.
105
00:04:02,840 --> 00:04:05,560
But how does your VM actually find that storage account?
106
00:04:05,560 --> 00:04:08,440
It used to resolve the public URL to a public IP.
107
00:04:08,440 --> 00:04:09,600
Now it needs a private IP.
108
00:04:09,600 --> 00:04:10,440
How does that work?
109
00:04:10,440 --> 00:04:13,240
That's where DNS comes in and that's what we'll look at next.
110
00:04:13,240 --> 00:04:16,560
DNS, the secret source that makes it all work.
111
00:04:16,560 --> 00:04:21,560
So you've got your private endpoint and your VM can reach the storage account over a private IP.
112
00:04:21,560 --> 00:04:25,240
But here's the thing, your VM doesn't know that IP.
113
00:04:25,240 --> 00:04:28,400
It knows the storage accounts URL, something like my storage account,
114
00:04:28,400 --> 00:04:31,600
blob.core.windows.net, that's the name it uses to connect.
115
00:04:31,600 --> 00:04:34,200
So how does it find the private IP instead of the public one?
116
00:04:34,200 --> 00:04:36,400
This is where DNS does the heavy lifting.
117
00:04:36,400 --> 00:04:40,480
When you create a private endpoint and choose to integrate with a private DNS zone,
118
00:04:40,480 --> 00:04:43,600
which you should Azure automatically creates one for you.
119
00:04:43,600 --> 00:04:48,600
For a blob storage account, that zone is called private link, blob.core.windows.net.
120
00:04:48,600 --> 00:04:53,600
Inside that zone, Azure adds an A record that maps your storage account name to the endpoint's private IP.
121
00:04:53,600 --> 00:04:54,840
Now here's the clever part.
122
00:04:54,840 --> 00:04:57,000
The original public URL still resolves.
123
00:04:57,000 --> 00:05:02,160
But instead of returning a public IP directly, it returns a name record that points to the private zone.
124
00:05:02,160 --> 00:05:07,200
So the resolution chain goes like this, your VM asks for the storage account URL, DNS returns at
125
00:05:07,200 --> 00:05:12,800
C name pointing to my storage account, private link.blog.core.windows.net,
126
00:05:12,800 --> 00:05:15,840
which lives in the private DNS zone linked to your virtual network.
127
00:05:15,840 --> 00:05:20,040
DNS resolves it to the private IP, your VM connects to that private IP,
128
00:05:20,040 --> 00:05:22,400
and traffic never touches the public internet.
129
00:05:22,400 --> 00:05:24,840
Think of it like a reception desk in an office building.
130
00:05:24,840 --> 00:05:27,000
Someone walks in and asks for the supply closet,
131
00:05:27,000 --> 00:05:28,880
and the receptionist doesn't send them outside.
132
00:05:28,880 --> 00:05:31,040
They point them to the correct hallway inside.
133
00:05:31,040 --> 00:05:36,240
The private DNS zone is that receptionist redirecting traffic to the right place without leaving the building.
134
00:05:36,240 --> 00:05:38,440
Now how this works depends on where your VM is.
135
00:05:38,440 --> 00:05:42,520
If it's in the same virtual network as the private endpoint, the private DNS zone is linked.
136
00:05:42,520 --> 00:05:44,560
So resolution happens automatically.
137
00:05:44,560 --> 00:05:48,080
If it's in a peer network, you need to link the zone to that peer network too.
138
00:05:48,080 --> 00:05:51,840
For on-premises machines through VPN or ExpressRoute, it gets more involved.
139
00:05:51,840 --> 00:05:57,360
You typically set up a DNS forwarder or use Azure DNS private resolver to make sure queries reach the private zone.
140
00:05:57,360 --> 00:06:01,000
But for most scenarios inside Azure, the basics are handled for you.
141
00:06:01,000 --> 00:06:04,880
DNS can get complex in larger environments, but for the standard case,
142
00:06:04,880 --> 00:06:07,880
a VM in the same virtual network as the private endpoint.
143
00:06:07,880 --> 00:06:09,480
Azure handles it automatically.
144
00:06:09,480 --> 00:06:11,000
You don't need to touch a thing.
145
00:06:11,000 --> 00:06:13,160
Let's see this in action with a real example.
146
00:06:13,160 --> 00:06:16,240
Real-world walkthrough, private link with Azure storage.
147
00:06:16,240 --> 00:06:17,400
Let's make this real.
148
00:06:17,400 --> 00:06:21,200
Say you've got a virtual machine running inside your Azure virtual network.
149
00:06:21,200 --> 00:06:24,640
That VM needs to grab files from an Azure blob storage account.
150
00:06:24,640 --> 00:06:25,880
It's a common setup.
151
00:06:25,880 --> 00:06:30,440
Maybe an app storing user uploads, or a data processing job reading from a container.
152
00:06:30,440 --> 00:06:32,440
Without private link, here's what happens.
153
00:06:32,440 --> 00:06:36,480
Your VM looks up to storage accounts, public URL, and gets a public IP address.
154
00:06:36,480 --> 00:06:39,960
Traffic leaves your virtual network, goes out over the public internet,
155
00:06:39,960 --> 00:06:42,440
then re-enters Azure to reach the storage account.
156
00:06:42,440 --> 00:06:43,800
That run trip is unnecessary.
157
00:06:43,800 --> 00:06:48,440
Both resources are already in Azure, but the data takes a detour through the open internet anyway.
158
00:06:48,440 --> 00:06:52,920
With private link, you deploy a private endpoint for the storage accounts, blob sub-resource.
159
00:06:52,920 --> 00:06:55,320
That's the specific part that handles blob data.
160
00:06:55,320 --> 00:06:59,080
Azure creates a virtual niki in your virtual network with a private IP,
161
00:06:59,080 --> 00:07:03,880
sets up the private DNS zone and the whole DNS resolution chain we talked about kicks in.
162
00:07:03,880 --> 00:07:10,320
Now when your VM resolves the same URL, my storage account, blob.co.windows.net.
163
00:07:10,320 --> 00:07:12,880
It gets the private IP instead of the public one.
164
00:07:12,880 --> 00:07:15,320
Traffic flows from the VM to the private endpoint,
165
00:07:15,320 --> 00:07:17,800
then over the Microsoft backbone to the storage account.
166
00:07:17,800 --> 00:07:19,760
It never leaves Azure's internal network.
167
00:07:19,760 --> 00:07:20,680
Here's the key point.
168
00:07:20,680 --> 00:07:22,160
Your application doesn't change.
169
00:07:22,160 --> 00:07:25,160
No modifying connection strings, no updating config files,
170
00:07:25,160 --> 00:07:26,600
the URL stays the same.
171
00:07:26,600 --> 00:07:28,880
The only thing that changes is how that URL resolves.
172
00:07:28,880 --> 00:07:32,160
From the app's perspective, it's still connecting to the same storage account.
173
00:07:32,160 --> 00:07:35,360
But behind the scenes, the traffic path is completely different.
174
00:07:35,360 --> 00:07:38,880
And if you want to go all the way, you can disable the public endpoint entirely.
175
00:07:38,880 --> 00:07:42,640
That means your storage account is only reachable through the private endpoint.
176
00:07:42,640 --> 00:07:43,960
Zero internet exposure.
177
00:07:43,960 --> 00:07:46,400
No one can even attempt to connect from the outside.
178
00:07:46,400 --> 00:07:47,840
One more thing worth noting.
179
00:07:47,840 --> 00:07:50,080
Storage accounts have multiple sub-resources.
180
00:07:50,080 --> 00:07:52,880
Blob is one, but there's also file, table and queue.
181
00:07:52,880 --> 00:07:54,520
Each one can have its own private endpoint.
182
00:07:54,520 --> 00:07:57,920
You could have one for blob traffic and a separate one for file traffic.
183
00:07:57,920 --> 00:08:01,040
Or use a single endpoint that covers all of them, depending on your needs.
184
00:08:01,040 --> 00:08:04,760
Now you might be wondering, how is this different from other Azure connectivity options?
185
00:08:04,760 --> 00:08:06,920
VPN, express route, service endpoints.
186
00:08:06,920 --> 00:08:07,840
They all sound similar.
187
00:08:07,840 --> 00:08:09,040
Let's clear that up.
188
00:08:09,040 --> 00:08:12,720
Private link versus VPN versus express route versus service endpoints.
189
00:08:12,720 --> 00:08:16,800
So how does private links stack up against VPN, express route and service endpoints?
190
00:08:16,800 --> 00:08:20,400
They all sound like they do the same thing, but they're actually solving different problems.
191
00:08:20,400 --> 00:08:22,280
And in many cases, you'd use them together.
192
00:08:22,280 --> 00:08:23,520
Start with VPN.
193
00:08:23,520 --> 00:08:26,720
A virtual private network connects your on-premises network to Azure
194
00:08:26,720 --> 00:08:28,000
over the public internet.
195
00:08:28,000 --> 00:08:31,160
It creates an encrypted tunnel between your site and Azure.
196
00:08:31,160 --> 00:08:34,880
Traffic is encrypted, sure, but it's still traveling over the public internet.
197
00:08:34,880 --> 00:08:37,680
The tunnel is secure that the road it's on is public.
198
00:08:37,680 --> 00:08:39,280
Private link doesn't replace VPN.
199
00:08:39,280 --> 00:08:40,520
It works alongside it.
200
00:08:40,520 --> 00:08:44,360
You might use a VPN to connect your office to Azure, then use private link to access your
201
00:08:44,360 --> 00:08:47,040
storage account privately from that connection.
202
00:08:47,040 --> 00:08:48,040
Express route is different.
203
00:08:48,040 --> 00:08:52,200
It gives you a dedicated private circuit from your data center to Azure.
204
00:08:52,200 --> 00:08:53,920
Traffic never touches the public internet at all.
205
00:08:53,920 --> 00:08:58,360
It's like having your own private road straight into Microsoft's network, but here's the catch.
206
00:08:58,360 --> 00:09:01,760
Express route alone doesn't give you private access to past services.
207
00:09:01,760 --> 00:09:05,680
It connects your network to Azure, but your storage account still has a public endpoint.
208
00:09:05,680 --> 00:09:10,120
You'd combine express route with private link to get true private access to those services.
209
00:09:10,120 --> 00:09:11,960
Service endpoints are an older technology.
210
00:09:11,960 --> 00:09:16,040
They let you restrict access to an Azure service, so only traffic from your virtual network
211
00:09:16,040 --> 00:09:17,040
can reach it.
212
00:09:17,040 --> 00:09:19,600
But here's the thing, the service still has a public endpoint.
213
00:09:19,600 --> 00:09:23,720
You're just adding a firewall rule that says, only allow traffic from this vnet.
214
00:09:23,720 --> 00:09:26,440
The endpoint itself is still exposed to the internet.
215
00:09:26,440 --> 00:09:29,680
Private link is more secure because the endpoint is truly inside your vnet.
216
00:09:29,680 --> 00:09:31,000
It has a private IP.
217
00:09:31,000 --> 00:09:32,480
There's no public endpoint to attack.
218
00:09:32,480 --> 00:09:33,840
Let me give you a simple way to think about it.
219
00:09:33,840 --> 00:09:36,680
VPN is a secure tunnel through a public road.
220
00:09:36,680 --> 00:09:39,040
Express route is a private road that goes straight to Azure.
221
00:09:39,040 --> 00:09:42,320
Service endpoints are a guard at the public gate who checks IDs.
222
00:09:42,320 --> 00:09:44,560
Private link is a direct hallway inside the building.
223
00:09:44,560 --> 00:09:46,040
You never go outside at all.
224
00:09:46,040 --> 00:09:47,440
So which one should you use?
225
00:09:47,440 --> 00:09:48,520
It depends.
226
00:09:48,520 --> 00:09:52,760
For connecting your office to Azure, VPN or express route are your options.
227
00:09:52,760 --> 00:09:56,320
For accessing past services privately, private link is the gold standard.
228
00:09:56,320 --> 00:09:58,680
And for the strongest security, combine them.
229
00:09:58,680 --> 00:10:02,320
Express route to get your traffic into Azure privately, then private link to access your
230
00:10:02,320 --> 00:10:03,960
services privately from there.
231
00:10:03,960 --> 00:10:06,360
But private link isn't just for Microsoft services.
232
00:10:06,360 --> 00:10:10,640
You can also use it for your own applications, private link service, hosting your own private
233
00:10:10,640 --> 00:10:11,640
endpoints.
234
00:10:11,640 --> 00:10:13,520
Here's something a lot of people miss.
235
00:10:13,520 --> 00:10:16,160
Private link isn't just for consuming Azure services.
236
00:10:16,160 --> 00:10:19,160
You can also use it to expose your own applications to the world.
237
00:10:19,160 --> 00:10:21,520
That's exactly what private link service was built for.
238
00:10:21,520 --> 00:10:22,960
Imagine your as-sass provider.
239
00:10:22,960 --> 00:10:26,200
You've got an application running on virtual machines behind a standard load balancer
240
00:10:26,200 --> 00:10:27,880
and your customers need access.
241
00:10:27,880 --> 00:10:29,760
Traditionally, you had two options.
242
00:10:29,760 --> 00:10:33,800
Expose everything to the internet or set up a VPN between your network and theirs.
243
00:10:33,800 --> 00:10:35,400
Both have big downsides.
244
00:10:35,400 --> 00:10:40,480
Public exposure opens you up to security risks and VPNs are complex to manage and maintain.
245
00:10:40,480 --> 00:10:42,240
Private link service cuts through that.
246
00:10:42,240 --> 00:10:45,760
You create the service, attach it to your standard load balancer, and then your customers
247
00:10:45,760 --> 00:10:48,560
can create a private endpoint in their own virtual network.
248
00:10:48,560 --> 00:10:50,520
Private endpoint connects directly to your service.
249
00:10:50,520 --> 00:10:53,680
No peering, no VPN and absolutely no public exposure.
250
00:10:53,680 --> 00:10:57,880
The traffic travels from their private endpoint across the Microsoft backbone straight to your
251
00:10:57,880 --> 00:10:58,880
service.
252
00:10:58,880 --> 00:10:59,880
It never touches the internet.
253
00:10:59,880 --> 00:11:04,240
Your service gets a globally unique alias, something like my app, guid.region.
254
00:11:04,240 --> 00:11:06,320
Azure, private link service.
255
00:11:06,320 --> 00:11:08,600
That alias is what customers use to connect.
256
00:11:08,600 --> 00:11:10,840
And you're in full control over who can see it.
257
00:11:10,840 --> 00:11:15,040
You can restrict visibility by our back roles, specific subscriptions, or let anyone with
258
00:11:15,040 --> 00:11:17,120
the alias request a connection.
259
00:11:17,120 --> 00:11:20,960
Every connection request comes to you for manual approval so you always know exactly who's
260
00:11:20,960 --> 00:11:21,960
connecting.
261
00:11:21,960 --> 00:11:25,680
For SAS providers, this is a huge shift instead of opening firewall rules or managing
262
00:11:25,680 --> 00:11:29,280
complex VPN configurations, you just hand your customer the alias.
263
00:11:29,280 --> 00:11:32,520
They create a private endpoint, you approve it, and that's it.
264
00:11:32,520 --> 00:11:33,520
Done.
265
00:11:33,520 --> 00:11:35,040
One limitation though.
266
00:11:35,040 --> 00:11:38,120
Private link service only works with standard load balancer is not basic.
267
00:11:38,120 --> 00:11:40,920
If you're still on a basic load balancer, you'll need to upgrade first.
268
00:11:40,920 --> 00:11:44,760
That's a small price to pay for the security and simplicity you get in return.
269
00:11:44,760 --> 00:11:46,360
Now all the security sounds great.
270
00:11:46,360 --> 00:11:49,760
But what does it actually mean for your compliance needs and your budget?
271
00:11:49,760 --> 00:11:51,840
Security, compliance, and cost considerations.
272
00:11:51,840 --> 00:11:55,040
Let's talk about what private link really means for your compliance requirements and your
273
00:11:55,040 --> 00:11:56,200
wallet.
274
00:11:56,200 --> 00:11:57,640
First, the security side.
275
00:11:57,640 --> 00:12:01,280
Private link reduces your attack service by eliminating public endpoints entirely.
276
00:12:01,280 --> 00:12:02,280
That's the headline benefit.
277
00:12:02,280 --> 00:12:06,000
Instead of a storage account or SQL database reachable from anywhere on the internet, you've
278
00:12:06,000 --> 00:12:09,560
got a resource that only responds to traffic from inside your virtual network.
279
00:12:09,560 --> 00:12:12,120
No public IP to scan, no open port to probe.
280
00:12:12,120 --> 00:12:14,080
The attack service shrinks dramatically.
281
00:12:14,080 --> 00:12:17,600
There's another benefit that doesn't get enough attention, data leakage prevention, each
282
00:12:17,600 --> 00:12:20,640
private endpoint maps to a specific resource instance.
283
00:12:20,640 --> 00:12:23,880
Not the whole service, not every storage account in your subscription.
284
00:12:23,880 --> 00:12:24,880
Just that one.
285
00:12:24,880 --> 00:12:28,440
So if someone compromises a workload in your virtual network, they can't use that private
286
00:12:28,440 --> 00:12:31,000
endpoint to reach other storage accounts.
287
00:12:31,000 --> 00:12:33,120
They're locked to the one resource you approved.
288
00:12:33,120 --> 00:12:35,640
For security teams, that containment is a big deal.
289
00:12:35,640 --> 00:12:38,640
On the compliance front, private link checks a lot of boxes.
290
00:12:38,640 --> 00:12:43,200
Regulations like HIPAA, GDPR, and PCI often require that sensitive data never travels
291
00:12:43,200 --> 00:12:44,720
over public networks.
292
00:12:44,720 --> 00:12:46,920
Private link gives you a clean way to prove that.
293
00:12:46,920 --> 00:12:50,760
Your traffic stays on the Microsoft backbone and you can point to the audit logs and say,
294
00:12:50,760 --> 00:12:52,000
"Here's the proof."
295
00:12:52,000 --> 00:12:55,320
For regulated industries, that alone can justify the investment.
296
00:12:55,320 --> 00:12:58,280
Now let's talk about cost because this is where people get surprised.
297
00:12:58,280 --> 00:12:59,320
Private link is not free.
298
00:12:59,320 --> 00:13:03,600
You pay a per hour charge for each private endpoint plus data processing fees for the traffic
299
00:13:03,600 --> 00:13:04,920
that flows through it.
300
00:13:04,920 --> 00:13:08,520
Depending on your usage, it can be two to three times more expensive than using a public
301
00:13:08,520 --> 00:13:10,200
endpoint with firewall rules.
302
00:13:10,200 --> 00:13:12,880
That adds up quickly, especially if you have many endpoints.
303
00:13:12,880 --> 00:13:14,480
So here's the honest take.
304
00:13:14,480 --> 00:13:16,400
Private link isn't always the right choice.
305
00:13:16,400 --> 00:13:20,600
If you're running a dev or test environment with no sensitive data, public endpoints with
306
00:13:20,600 --> 00:13:23,040
proper firewall rules are probably fine.
307
00:13:23,040 --> 00:13:26,560
If you're hosting a public website meant to be accessible from the internet, private link
308
00:13:26,560 --> 00:13:27,640
doesn't help you.
309
00:13:27,640 --> 00:13:31,740
But for production workloads in regulated industries, finance, healthcare, government, private
310
00:13:31,740 --> 00:13:32,740
link is often mandatory.
311
00:13:32,740 --> 00:13:34,840
It's the cost of doing business securely.
312
00:13:34,840 --> 00:13:38,640
Now before you implement this, there are a few gotchas to watch out for.
313
00:13:38,640 --> 00:13:39,640
Implementation gotchas.
314
00:13:39,640 --> 00:13:40,960
What beginners miss?
315
00:13:40,960 --> 00:13:42,440
Let me save you some headaches.
316
00:13:42,440 --> 00:13:46,320
There are the most common mistakes people make when they first set up private link.
317
00:13:46,320 --> 00:13:49,840
First up, you have to disable the public endpoint after creating the private endpoint.
318
00:13:49,840 --> 00:13:51,040
This is the biggest gotcha.
319
00:13:51,040 --> 00:13:55,080
A lot of people create the private endpoint and assume that's enough, but it's not.
320
00:13:55,080 --> 00:13:58,480
The public endpoint stays active by default, which means your traffic can still go over
321
00:13:58,480 --> 00:13:59,480
the internet.
322
00:13:59,480 --> 00:14:03,600
You have to go into the networking settings and explicitly turn off public network access.
323
00:14:03,600 --> 00:14:06,240
If you skip the step, you haven't actually secured anything.
324
00:14:06,240 --> 00:14:09,880
Next, DNS resolution for on-premises clients requires extra setup.
325
00:14:09,880 --> 00:14:14,560
If you've got machines in your office connecting through a VPN or express route, they won't automatically
326
00:14:14,560 --> 00:14:16,560
resolve your private endpoints IP.
327
00:14:16,560 --> 00:14:21,240
The private DNS zone is linked to your Azure virtual network, not to your on-premises DNS
328
00:14:21,240 --> 00:14:22,240
servers.
329
00:14:22,240 --> 00:14:26,120
You need to set up a DNS forwarder or use Azure DNS private resolver to make those queries
330
00:14:26,120 --> 00:14:27,120
reach the private zone.
331
00:14:27,120 --> 00:14:31,120
A lot of people overlook this and then wonder why their on-premises apps can't connect.
332
00:14:31,120 --> 00:14:34,240
Also, private endpoints don't magically work across regions.
333
00:14:34,240 --> 00:14:38,000
If your virtual network is in West Europe and you create a private endpoint for a storage
334
00:14:38,000 --> 00:14:39,840
account in East US, it won't work.
335
00:14:39,840 --> 00:14:43,600
The private endpoint has to be in the same region as the virtual network.
336
00:14:43,600 --> 00:14:47,280
The past service can be in a different region, but the endpoint itself must match the vnet's
337
00:14:47,280 --> 00:14:49,520
region, plan accordingly.
338
00:14:49,520 --> 00:14:53,960
One more thing, network security groups affect the private endpoint, NIC.
339
00:14:53,960 --> 00:14:56,440
The private endpoint creates a virtual ennick in your subnet.
340
00:14:56,440 --> 00:15:01,080
That NIC is subject to the same NSG rules as anything else in that subnet.
341
00:15:01,080 --> 00:15:04,360
If you block traffic to the NIC subnet, the endpoint won't work.
342
00:15:04,360 --> 00:15:06,880
Make sure your NSG rules allow the traffic you need.
343
00:15:06,880 --> 00:15:10,680
The most common mistake overall, creating the endpoint but forgetting to update DNS for
344
00:15:10,680 --> 00:15:11,680
on-prem users.
345
00:15:11,680 --> 00:15:13,560
You set everything up perfectly in Azure.
346
00:15:13,560 --> 00:15:17,180
Your VMs can reach the storage account privately, but your on-premises team calls and says
347
00:15:17,180 --> 00:15:18,180
nothing works.
348
00:15:18,180 --> 00:15:21,360
That's because their DNS servers don't know about the private zone.
349
00:15:21,360 --> 00:15:24,280
Fix that first and you'll save yourself a lot of troubleshooting.
350
00:15:24,280 --> 00:15:26,360
Let's wrap up with a simple takeaway.
351
00:15:26,360 --> 00:15:27,880
Here's what you need to remember.
352
00:15:27,880 --> 00:15:31,760
Azure Private Link lets you place private endpoints inside your virtual network.
353
00:15:31,760 --> 00:15:36,240
Those endpoints connect to past services like storage and SQL over the Microsoft backbone.
354
00:15:36,240 --> 00:15:38,920
Next stays off the public internet, that's the core idea.
355
00:15:38,920 --> 00:15:41,200
You don't need to remember every detail we covered today.
356
00:15:41,200 --> 00:15:42,400
Just understand this one thing.
357
00:15:42,400 --> 00:15:43,960
Azure services don't have to be public.
358
00:15:43,960 --> 00:15:46,480
By default they are, but they don't have to be.
359
00:15:46,480 --> 00:15:48,240
Private Link gives you a way to change that.
360
00:15:48,240 --> 00:15:49,660
Here's your challenge.
361
00:15:49,660 --> 00:15:54,680
Next time you deploy an Azure service that holds sensitive data, ask yourself one question.
362
00:15:54,680 --> 00:15:56,080
Should this be reachable from the internet?
363
00:15:56,080 --> 00:15:57,920
If the answer is no, you know what to do.
364
00:15:57,920 --> 00:16:01,760
If this episode helped you connect the dots, share it with a colleague who's new to Azure
365
00:16:01,760 --> 00:16:02,920
and hit subscribe.
366
00:16:02,920 --> 00:16:07,080
Next time we'll look at how to combine private link with ExpressRoot for maximum security.
00:00:00,000 --> 00:00:03,640
Welcome to another episode of Microsoft Knowledge Nudgets here on M365.
2
00:00:03,640 --> 00:00:05,440
FM, I'm your host, Mirko Peters.
3
00:00:05,440 --> 00:00:07,560
Today's topic is one that almost everyone has heard of,
4
00:00:07,560 --> 00:00:09,320
but few can explain clearly.
5
00:00:09,320 --> 00:00:10,840
Azure Private Link.
6
00:00:10,840 --> 00:00:13,120
You've probably seen the option when setting up a storage account
7
00:00:13,120 --> 00:00:14,480
or a SQL database.
8
00:00:14,480 --> 00:00:15,600
But what does it actually do?
9
00:00:15,600 --> 00:00:16,840
And do you really need it?
10
00:00:16,840 --> 00:00:18,480
Here's the thing most people get wrong.
11
00:00:18,480 --> 00:00:21,120
They assume that because the service runs inside Azure,
12
00:00:21,120 --> 00:00:22,360
it's automatically private,
13
00:00:22,360 --> 00:00:24,720
that it somehow walled off from the internet by default.
14
00:00:24,720 --> 00:00:26,560
That's not true, not even close.
15
00:00:27,520 --> 00:00:30,960
Most as your past services, storage, SQL, key vault,
16
00:00:30,960 --> 00:00:33,320
they ship with a public endpoint right out of the box.
17
00:00:33,320 --> 00:00:35,520
That means anyone on the internet can reach them
18
00:00:35,520 --> 00:00:38,280
as long as they have the right URL and credentials.
19
00:00:38,280 --> 00:00:39,760
By the end of this episode,
20
00:00:39,760 --> 00:00:41,840
you'll understand what private link actually is,
21
00:00:41,840 --> 00:00:45,560
why it exists and how it keeps your traffic off the public internet.
22
00:00:45,560 --> 00:00:47,360
We'll break it down using simple analogies.
23
00:00:47,360 --> 00:00:50,480
No marketing fluff, no jargon, just plain English.
24
00:00:50,480 --> 00:00:52,920
The old way, public endpoints everywhere.
25
00:00:52,920 --> 00:00:54,640
Let's start with the problem.
26
00:00:54,640 --> 00:00:57,600
Before private link existed, every Azure PASS service
27
00:00:57,600 --> 00:00:59,440
got a public endpoint by default.
28
00:00:59,440 --> 00:01:00,600
You create a storage account,
29
00:01:00,600 --> 00:01:03,600
Azure gives you something like my storage account.
30
00:01:03,600 --> 00:01:05,400
Blob.co.windows.net,
31
00:01:05,400 --> 00:01:07,720
that URL resolves to a public IP address.
32
00:01:07,720 --> 00:01:09,960
Anyone with internet access can try to connect to it.
33
00:01:09,960 --> 00:01:12,640
Now imagine you have a virtual machine running inside your own
34
00:01:12,640 --> 00:01:14,200
Azure Virtual Network,
35
00:01:14,200 --> 00:01:16,880
that VM needs to read some files from Blob Storage.
36
00:01:16,880 --> 00:01:19,240
You'd think the traffic would stay inside Azure, right?
37
00:01:19,240 --> 00:01:21,000
Both resources are in the same cloud,
38
00:01:21,000 --> 00:01:22,320
but that's not how it works.
39
00:01:22,320 --> 00:01:24,400
The VM has to leave your virtual network
40
00:01:24,400 --> 00:01:25,920
go out over the public internet
41
00:01:25,920 --> 00:01:28,920
and then come back into Azure to reach that storage account.
42
00:01:28,920 --> 00:01:31,360
It's like you're standing in one room of an office building
43
00:01:31,360 --> 00:01:34,480
and you need to get something from the supply closet in the same building.
44
00:01:34,480 --> 00:01:35,760
But instead of walking down the hallway,
45
00:01:35,760 --> 00:01:37,600
you have to go outside, walk around the block,
46
00:01:37,600 --> 00:01:39,080
and come back in through a different door.
47
00:01:39,080 --> 00:01:41,160
It makes no sense, but that's exactly what was happening.
48
00:01:41,160 --> 00:01:42,320
This is a real problem.
49
00:01:42,320 --> 00:01:44,520
Your data is traveling over the public internet.
50
00:01:44,520 --> 00:01:47,960
Even though both resources are sitting inside Microsoft's own data centers,
51
00:01:47,960 --> 00:01:49,800
that traffic is encrypted, sure.
52
00:01:49,800 --> 00:01:51,520
But it's still exposed to the open internet.
53
00:01:51,520 --> 00:01:55,160
It's still passing through routers and switches that you don't control.
54
00:01:55,160 --> 00:01:57,240
And if someone managed to intercept that traffic,
55
00:01:57,240 --> 00:01:58,880
they could see what you're sending.
56
00:01:58,880 --> 00:02:00,360
There's a common myth here.
57
00:02:00,360 --> 00:02:01,320
A lot of people think,
58
00:02:01,320 --> 00:02:03,680
well, it's in my subscription, so it's private.
59
00:02:03,680 --> 00:02:04,920
That's not how it works.
60
00:02:04,920 --> 00:02:06,880
Your subscription is a billing and management boundary,
61
00:02:06,880 --> 00:02:07,960
not a network boundary.
62
00:02:07,960 --> 00:02:11,120
By default, your Azure services are reachable from the internet.
63
00:02:11,120 --> 00:02:14,520
The only thing protecting them is the authentication and authorization layer,
64
00:02:14,520 --> 00:02:17,200
the keys, the passwords, the firewall rules.
65
00:02:17,200 --> 00:02:18,880
But the network path itself is public.
66
00:02:18,880 --> 00:02:20,440
So Microsoft looked at this and said,
67
00:02:20,440 --> 00:02:21,720
there has to be a better way.
68
00:02:21,720 --> 00:02:22,480
And they built it.
69
00:02:22,480 --> 00:02:24,080
They called it private link.
70
00:02:24,080 --> 00:02:27,320
The solution, private endpoint as a network interface card.
71
00:02:27,320 --> 00:02:29,120
Private link is the overall service,
72
00:02:29,120 --> 00:02:32,480
but the core piece you need to understand is the private endpoint,
73
00:02:32,480 --> 00:02:37,240
a virtual network interface card or NIC that sits inside your virtual network
74
00:02:37,240 --> 00:02:39,280
and connects to a past service.
75
00:02:39,280 --> 00:02:40,360
Here's how it works.
76
00:02:40,360 --> 00:02:42,840
You create a private endpoint for your storage account,
77
00:02:42,840 --> 00:02:46,080
and as your builds a virtual nick inside your virtual network
78
00:02:46,080 --> 00:02:48,480
with a private IP from your subnet,
79
00:02:48,480 --> 00:02:52,640
that NIC connects to the storage account through private link on the backend.
80
00:02:52,640 --> 00:02:57,440
So from your VM's viewpoint, the storage account now looks like it lives inside your own network
81
00:02:57,440 --> 00:03:00,440
with a private IP, just like any other resource.
82
00:03:00,440 --> 00:03:02,840
When your VM sends traffic to that storage account,
83
00:03:02,840 --> 00:03:07,520
it hits the private IP of the NIC and travels over the Microsoft backbone network.
84
00:03:07,520 --> 00:03:09,120
Never the public internet.
85
00:03:09,120 --> 00:03:11,400
It never leaves Azure's internal infrastructure.
86
00:03:11,400 --> 00:03:13,960
Think of it like that secure hallway in the office building.
87
00:03:13,960 --> 00:03:18,600
Instead of walking outside and around the block, you just walk down the corridor into the supply closet.
88
00:03:18,600 --> 00:03:20,920
Direct connection, no detour.
89
00:03:20,920 --> 00:03:23,000
Now here's a nuance, a lot of people miss.
90
00:03:23,000 --> 00:03:27,200
Enabling a private endpoint does not turn off the public endpoint automatically.
91
00:03:27,200 --> 00:03:28,760
They can both exist at the same time.
92
00:03:28,760 --> 00:03:30,200
If you create a private endpoint,
93
00:03:30,200 --> 00:03:32,280
but never touch the public endpoint settings,
94
00:03:32,280 --> 00:03:34,760
your storage account is still reachable from the internet.
95
00:03:34,760 --> 00:03:38,480
You have to explicitly disable public network access to lock it down completely.
96
00:03:38,480 --> 00:03:40,840
Many people think creating the private endpoint is enough.
97
00:03:40,840 --> 00:03:41,680
It's not.
98
00:03:41,680 --> 00:03:44,040
You have to tell Azure, I only want private access.
99
00:03:44,040 --> 00:03:46,120
Let me clear up another myth while we're here.
100
00:03:46,120 --> 00:03:49,120
Private link is not the same as a VPN or express route.
101
00:03:49,120 --> 00:03:52,440
They solve different problems and we'll get into that comparison later.
102
00:03:52,440 --> 00:03:55,800
For now, just know private link is about accessing a specific service,
103
00:03:55,800 --> 00:03:58,000
not connecting your whole network to Azure.
104
00:03:58,000 --> 00:04:02,840
So you've got your private endpoint and your VM can reach the storage account over a private IP.
105
00:04:02,840 --> 00:04:05,560
But how does your VM actually find that storage account?
106
00:04:05,560 --> 00:04:08,440
It used to resolve the public URL to a public IP.
107
00:04:08,440 --> 00:04:09,600
Now it needs a private IP.
108
00:04:09,600 --> 00:04:10,440
How does that work?
109
00:04:10,440 --> 00:04:13,240
That's where DNS comes in and that's what we'll look at next.
110
00:04:13,240 --> 00:04:16,560
DNS, the secret source that makes it all work.
111
00:04:16,560 --> 00:04:21,560
So you've got your private endpoint and your VM can reach the storage account over a private IP.
112
00:04:21,560 --> 00:04:25,240
But here's the thing, your VM doesn't know that IP.
113
00:04:25,240 --> 00:04:28,400
It knows the storage accounts URL, something like my storage account,
114
00:04:28,400 --> 00:04:31,600
blob.core.windows.net, that's the name it uses to connect.
115
00:04:31,600 --> 00:04:34,200
So how does it find the private IP instead of the public one?
116
00:04:34,200 --> 00:04:36,400
This is where DNS does the heavy lifting.
117
00:04:36,400 --> 00:04:40,480
When you create a private endpoint and choose to integrate with a private DNS zone,
118
00:04:40,480 --> 00:04:43,600
which you should Azure automatically creates one for you.
119
00:04:43,600 --> 00:04:48,600
For a blob storage account, that zone is called private link, blob.core.windows.net.
120
00:04:48,600 --> 00:04:53,600
Inside that zone, Azure adds an A record that maps your storage account name to the endpoint's private IP.
121
00:04:53,600 --> 00:04:54,840
Now here's the clever part.
122
00:04:54,840 --> 00:04:57,000
The original public URL still resolves.
123
00:04:57,000 --> 00:05:02,160
But instead of returning a public IP directly, it returns a name record that points to the private zone.
124
00:05:02,160 --> 00:05:07,200
So the resolution chain goes like this, your VM asks for the storage account URL, DNS returns at
125
00:05:07,200 --> 00:05:12,800
C name pointing to my storage account, private link.blog.core.windows.net,
126
00:05:12,800 --> 00:05:15,840
which lives in the private DNS zone linked to your virtual network.
127
00:05:15,840 --> 00:05:20,040
DNS resolves it to the private IP, your VM connects to that private IP,
128
00:05:20,040 --> 00:05:22,400
and traffic never touches the public internet.
129
00:05:22,400 --> 00:05:24,840
Think of it like a reception desk in an office building.
130
00:05:24,840 --> 00:05:27,000
Someone walks in and asks for the supply closet,
131
00:05:27,000 --> 00:05:28,880
and the receptionist doesn't send them outside.
132
00:05:28,880 --> 00:05:31,040
They point them to the correct hallway inside.
133
00:05:31,040 --> 00:05:36,240
The private DNS zone is that receptionist redirecting traffic to the right place without leaving the building.
134
00:05:36,240 --> 00:05:38,440
Now how this works depends on where your VM is.
135
00:05:38,440 --> 00:05:42,520
If it's in the same virtual network as the private endpoint, the private DNS zone is linked.
136
00:05:42,520 --> 00:05:44,560
So resolution happens automatically.
137
00:05:44,560 --> 00:05:48,080
If it's in a peer network, you need to link the zone to that peer network too.
138
00:05:48,080 --> 00:05:51,840
For on-premises machines through VPN or ExpressRoute, it gets more involved.
139
00:05:51,840 --> 00:05:57,360
You typically set up a DNS forwarder or use Azure DNS private resolver to make sure queries reach the private zone.
140
00:05:57,360 --> 00:06:01,000
But for most scenarios inside Azure, the basics are handled for you.
141
00:06:01,000 --> 00:06:04,880
DNS can get complex in larger environments, but for the standard case,
142
00:06:04,880 --> 00:06:07,880
a VM in the same virtual network as the private endpoint.
143
00:06:07,880 --> 00:06:09,480
Azure handles it automatically.
144
00:06:09,480 --> 00:06:11,000
You don't need to touch a thing.
145
00:06:11,000 --> 00:06:13,160
Let's see this in action with a real example.
146
00:06:13,160 --> 00:06:16,240
Real-world walkthrough, private link with Azure storage.
147
00:06:16,240 --> 00:06:17,400
Let's make this real.
148
00:06:17,400 --> 00:06:21,200
Say you've got a virtual machine running inside your Azure virtual network.
149
00:06:21,200 --> 00:06:24,640
That VM needs to grab files from an Azure blob storage account.
150
00:06:24,640 --> 00:06:25,880
It's a common setup.
151
00:06:25,880 --> 00:06:30,440
Maybe an app storing user uploads, or a data processing job reading from a container.
152
00:06:30,440 --> 00:06:32,440
Without private link, here's what happens.
153
00:06:32,440 --> 00:06:36,480
Your VM looks up to storage accounts, public URL, and gets a public IP address.
154
00:06:36,480 --> 00:06:39,960
Traffic leaves your virtual network, goes out over the public internet,
155
00:06:39,960 --> 00:06:42,440
then re-enters Azure to reach the storage account.
156
00:06:42,440 --> 00:06:43,800
That run trip is unnecessary.
157
00:06:43,800 --> 00:06:48,440
Both resources are already in Azure, but the data takes a detour through the open internet anyway.
158
00:06:48,440 --> 00:06:52,920
With private link, you deploy a private endpoint for the storage accounts, blob sub-resource.
159
00:06:52,920 --> 00:06:55,320
That's the specific part that handles blob data.
160
00:06:55,320 --> 00:06:59,080
Azure creates a virtual niki in your virtual network with a private IP,
161
00:06:59,080 --> 00:07:03,880
sets up the private DNS zone and the whole DNS resolution chain we talked about kicks in.
162
00:07:03,880 --> 00:07:10,320
Now when your VM resolves the same URL, my storage account, blob.co.windows.net.
163
00:07:10,320 --> 00:07:12,880
It gets the private IP instead of the public one.
164
00:07:12,880 --> 00:07:15,320
Traffic flows from the VM to the private endpoint,
165
00:07:15,320 --> 00:07:17,800
then over the Microsoft backbone to the storage account.
166
00:07:17,800 --> 00:07:19,760
It never leaves Azure's internal network.
167
00:07:19,760 --> 00:07:20,680
Here's the key point.
168
00:07:20,680 --> 00:07:22,160
Your application doesn't change.
169
00:07:22,160 --> 00:07:25,160
No modifying connection strings, no updating config files,
170
00:07:25,160 --> 00:07:26,600
the URL stays the same.
171
00:07:26,600 --> 00:07:28,880
The only thing that changes is how that URL resolves.
172
00:07:28,880 --> 00:07:32,160
From the app's perspective, it's still connecting to the same storage account.
173
00:07:32,160 --> 00:07:35,360
But behind the scenes, the traffic path is completely different.
174
00:07:35,360 --> 00:07:38,880
And if you want to go all the way, you can disable the public endpoint entirely.
175
00:07:38,880 --> 00:07:42,640
That means your storage account is only reachable through the private endpoint.
176
00:07:42,640 --> 00:07:43,960
Zero internet exposure.
177
00:07:43,960 --> 00:07:46,400
No one can even attempt to connect from the outside.
178
00:07:46,400 --> 00:07:47,840
One more thing worth noting.
179
00:07:47,840 --> 00:07:50,080
Storage accounts have multiple sub-resources.
180
00:07:50,080 --> 00:07:52,880
Blob is one, but there's also file, table and queue.
181
00:07:52,880 --> 00:07:54,520
Each one can have its own private endpoint.
182
00:07:54,520 --> 00:07:57,920
You could have one for blob traffic and a separate one for file traffic.
183
00:07:57,920 --> 00:08:01,040
Or use a single endpoint that covers all of them, depending on your needs.
184
00:08:01,040 --> 00:08:04,760
Now you might be wondering, how is this different from other Azure connectivity options?
185
00:08:04,760 --> 00:08:06,920
VPN, express route, service endpoints.
186
00:08:06,920 --> 00:08:07,840
They all sound similar.
187
00:08:07,840 --> 00:08:09,040
Let's clear that up.
188
00:08:09,040 --> 00:08:12,720
Private link versus VPN versus express route versus service endpoints.
189
00:08:12,720 --> 00:08:16,800
So how does private links stack up against VPN, express route and service endpoints?
190
00:08:16,800 --> 00:08:20,400
They all sound like they do the same thing, but they're actually solving different problems.
191
00:08:20,400 --> 00:08:22,280
And in many cases, you'd use them together.
192
00:08:22,280 --> 00:08:23,520
Start with VPN.
193
00:08:23,520 --> 00:08:26,720
A virtual private network connects your on-premises network to Azure
194
00:08:26,720 --> 00:08:28,000
over the public internet.
195
00:08:28,000 --> 00:08:31,160
It creates an encrypted tunnel between your site and Azure.
196
00:08:31,160 --> 00:08:34,880
Traffic is encrypted, sure, but it's still traveling over the public internet.
197
00:08:34,880 --> 00:08:37,680
The tunnel is secure that the road it's on is public.
198
00:08:37,680 --> 00:08:39,280
Private link doesn't replace VPN.
199
00:08:39,280 --> 00:08:40,520
It works alongside it.
200
00:08:40,520 --> 00:08:44,360
You might use a VPN to connect your office to Azure, then use private link to access your
201
00:08:44,360 --> 00:08:47,040
storage account privately from that connection.
202
00:08:47,040 --> 00:08:48,040
Express route is different.
203
00:08:48,040 --> 00:08:52,200
It gives you a dedicated private circuit from your data center to Azure.
204
00:08:52,200 --> 00:08:53,920
Traffic never touches the public internet at all.
205
00:08:53,920 --> 00:08:58,360
It's like having your own private road straight into Microsoft's network, but here's the catch.
206
00:08:58,360 --> 00:09:01,760
Express route alone doesn't give you private access to past services.
207
00:09:01,760 --> 00:09:05,680
It connects your network to Azure, but your storage account still has a public endpoint.
208
00:09:05,680 --> 00:09:10,120
You'd combine express route with private link to get true private access to those services.
209
00:09:10,120 --> 00:09:11,960
Service endpoints are an older technology.
210
00:09:11,960 --> 00:09:16,040
They let you restrict access to an Azure service, so only traffic from your virtual network
211
00:09:16,040 --> 00:09:17,040
can reach it.
212
00:09:17,040 --> 00:09:19,600
But here's the thing, the service still has a public endpoint.
213
00:09:19,600 --> 00:09:23,720
You're just adding a firewall rule that says, only allow traffic from this vnet.
214
00:09:23,720 --> 00:09:26,440
The endpoint itself is still exposed to the internet.
215
00:09:26,440 --> 00:09:29,680
Private link is more secure because the endpoint is truly inside your vnet.
216
00:09:29,680 --> 00:09:31,000
It has a private IP.
217
00:09:31,000 --> 00:09:32,480
There's no public endpoint to attack.
218
00:09:32,480 --> 00:09:33,840
Let me give you a simple way to think about it.
219
00:09:33,840 --> 00:09:36,680
VPN is a secure tunnel through a public road.
220
00:09:36,680 --> 00:09:39,040
Express route is a private road that goes straight to Azure.
221
00:09:39,040 --> 00:09:42,320
Service endpoints are a guard at the public gate who checks IDs.
222
00:09:42,320 --> 00:09:44,560
Private link is a direct hallway inside the building.
223
00:09:44,560 --> 00:09:46,040
You never go outside at all.
224
00:09:46,040 --> 00:09:47,440
So which one should you use?
225
00:09:47,440 --> 00:09:48,520
It depends.
226
00:09:48,520 --> 00:09:52,760
For connecting your office to Azure, VPN or express route are your options.
227
00:09:52,760 --> 00:09:56,320
For accessing past services privately, private link is the gold standard.
228
00:09:56,320 --> 00:09:58,680
And for the strongest security, combine them.
229
00:09:58,680 --> 00:10:02,320
Express route to get your traffic into Azure privately, then private link to access your
230
00:10:02,320 --> 00:10:03,960
services privately from there.
231
00:10:03,960 --> 00:10:06,360
But private link isn't just for Microsoft services.
232
00:10:06,360 --> 00:10:10,640
You can also use it for your own applications, private link service, hosting your own private
233
00:10:10,640 --> 00:10:11,640
endpoints.
234
00:10:11,640 --> 00:10:13,520
Here's something a lot of people miss.
235
00:10:13,520 --> 00:10:16,160
Private link isn't just for consuming Azure services.
236
00:10:16,160 --> 00:10:19,160
You can also use it to expose your own applications to the world.
237
00:10:19,160 --> 00:10:21,520
That's exactly what private link service was built for.
238
00:10:21,520 --> 00:10:22,960
Imagine your as-sass provider.
239
00:10:22,960 --> 00:10:26,200
You've got an application running on virtual machines behind a standard load balancer
240
00:10:26,200 --> 00:10:27,880
and your customers need access.
241
00:10:27,880 --> 00:10:29,760
Traditionally, you had two options.
242
00:10:29,760 --> 00:10:33,800
Expose everything to the internet or set up a VPN between your network and theirs.
243
00:10:33,800 --> 00:10:35,400
Both have big downsides.
244
00:10:35,400 --> 00:10:40,480
Public exposure opens you up to security risks and VPNs are complex to manage and maintain.
245
00:10:40,480 --> 00:10:42,240
Private link service cuts through that.
246
00:10:42,240 --> 00:10:45,760
You create the service, attach it to your standard load balancer, and then your customers
247
00:10:45,760 --> 00:10:48,560
can create a private endpoint in their own virtual network.
248
00:10:48,560 --> 00:10:50,520
Private endpoint connects directly to your service.
249
00:10:50,520 --> 00:10:53,680
No peering, no VPN and absolutely no public exposure.
250
00:10:53,680 --> 00:10:57,880
The traffic travels from their private endpoint across the Microsoft backbone straight to your
251
00:10:57,880 --> 00:10:58,880
service.
252
00:10:58,880 --> 00:10:59,880
It never touches the internet.
253
00:10:59,880 --> 00:11:04,240
Your service gets a globally unique alias, something like my app, guid.region.
254
00:11:04,240 --> 00:11:06,320
Azure, private link service.
255
00:11:06,320 --> 00:11:08,600
That alias is what customers use to connect.
256
00:11:08,600 --> 00:11:10,840
And you're in full control over who can see it.
257
00:11:10,840 --> 00:11:15,040
You can restrict visibility by our back roles, specific subscriptions, or let anyone with
258
00:11:15,040 --> 00:11:17,120
the alias request a connection.
259
00:11:17,120 --> 00:11:20,960
Every connection request comes to you for manual approval so you always know exactly who's
260
00:11:20,960 --> 00:11:21,960
connecting.
261
00:11:21,960 --> 00:11:25,680
For SAS providers, this is a huge shift instead of opening firewall rules or managing
262
00:11:25,680 --> 00:11:29,280
complex VPN configurations, you just hand your customer the alias.
263
00:11:29,280 --> 00:11:32,520
They create a private endpoint, you approve it, and that's it.
264
00:11:32,520 --> 00:11:33,520
Done.
265
00:11:33,520 --> 00:11:35,040
One limitation though.
266
00:11:35,040 --> 00:11:38,120
Private link service only works with standard load balancer is not basic.
267
00:11:38,120 --> 00:11:40,920
If you're still on a basic load balancer, you'll need to upgrade first.
268
00:11:40,920 --> 00:11:44,760
That's a small price to pay for the security and simplicity you get in return.
269
00:11:44,760 --> 00:11:46,360
Now all the security sounds great.
270
00:11:46,360 --> 00:11:49,760
But what does it actually mean for your compliance needs and your budget?
271
00:11:49,760 --> 00:11:51,840
Security, compliance, and cost considerations.
272
00:11:51,840 --> 00:11:55,040
Let's talk about what private link really means for your compliance requirements and your
273
00:11:55,040 --> 00:11:56,200
wallet.
274
00:11:56,200 --> 00:11:57,640
First, the security side.
275
00:11:57,640 --> 00:12:01,280
Private link reduces your attack service by eliminating public endpoints entirely.
276
00:12:01,280 --> 00:12:02,280
That's the headline benefit.
277
00:12:02,280 --> 00:12:06,000
Instead of a storage account or SQL database reachable from anywhere on the internet, you've
278
00:12:06,000 --> 00:12:09,560
got a resource that only responds to traffic from inside your virtual network.
279
00:12:09,560 --> 00:12:12,120
No public IP to scan, no open port to probe.
280
00:12:12,120 --> 00:12:14,080
The attack service shrinks dramatically.
281
00:12:14,080 --> 00:12:17,600
There's another benefit that doesn't get enough attention, data leakage prevention, each
282
00:12:17,600 --> 00:12:20,640
private endpoint maps to a specific resource instance.
283
00:12:20,640 --> 00:12:23,880
Not the whole service, not every storage account in your subscription.
284
00:12:23,880 --> 00:12:24,880
Just that one.
285
00:12:24,880 --> 00:12:28,440
So if someone compromises a workload in your virtual network, they can't use that private
286
00:12:28,440 --> 00:12:31,000
endpoint to reach other storage accounts.
287
00:12:31,000 --> 00:12:33,120
They're locked to the one resource you approved.
288
00:12:33,120 --> 00:12:35,640
For security teams, that containment is a big deal.
289
00:12:35,640 --> 00:12:38,640
On the compliance front, private link checks a lot of boxes.
290
00:12:38,640 --> 00:12:43,200
Regulations like HIPAA, GDPR, and PCI often require that sensitive data never travels
291
00:12:43,200 --> 00:12:44,720
over public networks.
292
00:12:44,720 --> 00:12:46,920
Private link gives you a clean way to prove that.
293
00:12:46,920 --> 00:12:50,760
Your traffic stays on the Microsoft backbone and you can point to the audit logs and say,
294
00:12:50,760 --> 00:12:52,000
"Here's the proof."
295
00:12:52,000 --> 00:12:55,320
For regulated industries, that alone can justify the investment.
296
00:12:55,320 --> 00:12:58,280
Now let's talk about cost because this is where people get surprised.
297
00:12:58,280 --> 00:12:59,320
Private link is not free.
298
00:12:59,320 --> 00:13:03,600
You pay a per hour charge for each private endpoint plus data processing fees for the traffic
299
00:13:03,600 --> 00:13:04,920
that flows through it.
300
00:13:04,920 --> 00:13:08,520
Depending on your usage, it can be two to three times more expensive than using a public
301
00:13:08,520 --> 00:13:10,200
endpoint with firewall rules.
302
00:13:10,200 --> 00:13:12,880
That adds up quickly, especially if you have many endpoints.
303
00:13:12,880 --> 00:13:14,480
So here's the honest take.
304
00:13:14,480 --> 00:13:16,400
Private link isn't always the right choice.
305
00:13:16,400 --> 00:13:20,600
If you're running a dev or test environment with no sensitive data, public endpoints with
306
00:13:20,600 --> 00:13:23,040
proper firewall rules are probably fine.
307
00:13:23,040 --> 00:13:26,560
If you're hosting a public website meant to be accessible from the internet, private link
308
00:13:26,560 --> 00:13:27,640
doesn't help you.
309
00:13:27,640 --> 00:13:31,740
But for production workloads in regulated industries, finance, healthcare, government, private
310
00:13:31,740 --> 00:13:32,740
link is often mandatory.
311
00:13:32,740 --> 00:13:34,840
It's the cost of doing business securely.
312
00:13:34,840 --> 00:13:38,640
Now before you implement this, there are a few gotchas to watch out for.
313
00:13:38,640 --> 00:13:39,640
Implementation gotchas.
314
00:13:39,640 --> 00:13:40,960
What beginners miss?
315
00:13:40,960 --> 00:13:42,440
Let me save you some headaches.
316
00:13:42,440 --> 00:13:46,320
There are the most common mistakes people make when they first set up private link.
317
00:13:46,320 --> 00:13:49,840
First up, you have to disable the public endpoint after creating the private endpoint.
318
00:13:49,840 --> 00:13:51,040
This is the biggest gotcha.
319
00:13:51,040 --> 00:13:55,080
A lot of people create the private endpoint and assume that's enough, but it's not.
320
00:13:55,080 --> 00:13:58,480
The public endpoint stays active by default, which means your traffic can still go over
321
00:13:58,480 --> 00:13:59,480
the internet.
322
00:13:59,480 --> 00:14:03,600
You have to go into the networking settings and explicitly turn off public network access.
323
00:14:03,600 --> 00:14:06,240
If you skip the step, you haven't actually secured anything.
324
00:14:06,240 --> 00:14:09,880
Next, DNS resolution for on-premises clients requires extra setup.
325
00:14:09,880 --> 00:14:14,560
If you've got machines in your office connecting through a VPN or express route, they won't automatically
326
00:14:14,560 --> 00:14:16,560
resolve your private endpoints IP.
327
00:14:16,560 --> 00:14:21,240
The private DNS zone is linked to your Azure virtual network, not to your on-premises DNS
328
00:14:21,240 --> 00:14:22,240
servers.
329
00:14:22,240 --> 00:14:26,120
You need to set up a DNS forwarder or use Azure DNS private resolver to make those queries
330
00:14:26,120 --> 00:14:27,120
reach the private zone.
331
00:14:27,120 --> 00:14:31,120
A lot of people overlook this and then wonder why their on-premises apps can't connect.
332
00:14:31,120 --> 00:14:34,240
Also, private endpoints don't magically work across regions.
333
00:14:34,240 --> 00:14:38,000
If your virtual network is in West Europe and you create a private endpoint for a storage
334
00:14:38,000 --> 00:14:39,840
account in East US, it won't work.
335
00:14:39,840 --> 00:14:43,600
The private endpoint has to be in the same region as the virtual network.
336
00:14:43,600 --> 00:14:47,280
The past service can be in a different region, but the endpoint itself must match the vnet's
337
00:14:47,280 --> 00:14:49,520
region, plan accordingly.
338
00:14:49,520 --> 00:14:53,960
One more thing, network security groups affect the private endpoint, NIC.
339
00:14:53,960 --> 00:14:56,440
The private endpoint creates a virtual ennick in your subnet.
340
00:14:56,440 --> 00:15:01,080
That NIC is subject to the same NSG rules as anything else in that subnet.
341
00:15:01,080 --> 00:15:04,360
If you block traffic to the NIC subnet, the endpoint won't work.
342
00:15:04,360 --> 00:15:06,880
Make sure your NSG rules allow the traffic you need.
343
00:15:06,880 --> 00:15:10,680
The most common mistake overall, creating the endpoint but forgetting to update DNS for
344
00:15:10,680 --> 00:15:11,680
on-prem users.
345
00:15:11,680 --> 00:15:13,560
You set everything up perfectly in Azure.
346
00:15:13,560 --> 00:15:17,180
Your VMs can reach the storage account privately, but your on-premises team calls and says
347
00:15:17,180 --> 00:15:18,180
nothing works.
348
00:15:18,180 --> 00:15:21,360
That's because their DNS servers don't know about the private zone.
349
00:15:21,360 --> 00:15:24,280
Fix that first and you'll save yourself a lot of troubleshooting.
350
00:15:24,280 --> 00:15:26,360
Let's wrap up with a simple takeaway.
351
00:15:26,360 --> 00:15:27,880
Here's what you need to remember.
352
00:15:27,880 --> 00:15:31,760
Azure Private Link lets you place private endpoints inside your virtual network.
353
00:15:31,760 --> 00:15:36,240
Those endpoints connect to past services like storage and SQL over the Microsoft backbone.
354
00:15:36,240 --> 00:15:38,920
Next stays off the public internet, that's the core idea.
355
00:15:38,920 --> 00:15:41,200
You don't need to remember every detail we covered today.
356
00:15:41,200 --> 00:15:42,400
Just understand this one thing.
357
00:15:42,400 --> 00:15:43,960
Azure services don't have to be public.
358
00:15:43,960 --> 00:15:46,480
By default they are, but they don't have to be.
359
00:15:46,480 --> 00:15:48,240
Private Link gives you a way to change that.
360
00:15:48,240 --> 00:15:49,660
Here's your challenge.
361
00:15:49,660 --> 00:15:54,680
Next time you deploy an Azure service that holds sensitive data, ask yourself one question.
362
00:15:54,680 --> 00:15:56,080
Should this be reachable from the internet?
363
00:15:56,080 --> 00:15:57,920
If the answer is no, you know what to do.
364
00:15:57,920 --> 00:16:01,760
If this episode helped you connect the dots, share it with a colleague who's new to Azure
365
00:16:01,760 --> 00:16:02,920
and hit subscribe.
366
00:16:02,920 --> 00:16:07,080
Next time we'll look at how to combine private link with ExpressRoot for maximum security.
