Private endpoints, explained without the fog
A private endpoint drops a real network card — with a private IP from your own subnet — in front of a public Azure service. Here is what that actually means, how it differs from a service endpoint, and the one DNS gotcha that trips everyone.
Most Azure platform services — a storage account, an Azure SQL database, a Key Vault — are born with a public front door. Their address, something like myaccount.blob.core.windows.net, resolves to a public IP on the internet. You can bolt firewalls onto that front door, but it is still a front door facing the street. A private endpoint does something more fundamental: it builds a side entrance that opens only into your own private network, and lets you brick up the public door entirely.
What a private endpoint actually is
Microsoft's definition is refreshingly concrete, so learn it word for word: "A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that's powered by Azure Private Link."
Read that again, because the important word is network interface — a NIC, the same kind of virtual network card a VM has. When you create a private endpoint for your storage account, Azure carves a real NIC into one of your subnets and gives it a private IP, say 10.0.1.4. That IP is your storage account now, as far as your network is concerned. The documentation puts it beautifully: you are "bringing the service into your virtual network." Traffic to it never touches the public internet — it rides the Microsoft backbone from your subnet straight to the service.
Because it is just a private IP in your address space, everything that can already reach your VNet can reach it: VMs in the same network, peered networks, and on-premises systems connected over VPN or ExpressRoute. No public exposure required for any of them.
A private endpoint targets a specific sub-resource, not the whole account. A storage account's blob service and its file service are separate targets — so if a workload needs both privately, that is two private endpoints. It is the detail people forget when connectivity mysteriously works for blobs but not for files.
Private endpoint vs service endpoint — the question everyone confuses
They sound like twins and do opposite things. Here is the clean split:
- A service endpoint keeps the service on its public IP but tells that service, "only accept traffic that originates from this subnet." The address never changes; you are just adding a bouncer to the public door. It is free, quick, and subnet-scoped — but the resource still has a public endpoint, and it does not extend to on-premises callers.
- A private endpoint gives the service a new private IP inside your network via Azure Private Link. The public door can be shut completely. It works across peered networks and from on-premises, and it is the one you want when "no public access, full stop" is the requirement — the answer auditors and security reviews are looking for.
Shorthand for the interview: service endpoint restricts the public door; private endpoint builds a private one.
A private endpoint doesn't guard the public entrance — it brings the building inside your walls.
The DNS gotcha that catches everyone
Here is where first attempts break. You create the private endpoint, shut off public access, and your app immediately fails to connect. Nothing is wrong with the endpoint. The problem is name resolution.
Your code still connects to the friendly hostname, myaccount.blob.core.windows.net. By default that name resolves — through Azure's public DNS — to the service's public IP, the very door you just bricked up. The private endpoint gave you 10.0.1.4, but nothing is telling the hostname to point there.
The fix is a private DNS zone (for storage blobs, privatelink.blob.core.windows.net) linked to your VNet. With it in place, an internal lookup of the hostname returns the private IP, and everything connects — no code change, same connection string. When you wire the endpoint up in the portal it offers to create and link this zone for you; in infrastructure-as-code you must declare it yourself, which is exactly why it gets missed. If a private endpoint "isn't working," check DNS before you touch anything else.
When to reach for one
Use a private endpoint whenever a data-tier service should not be reachable from the internet at all: the database behind a web app, the Key Vault holding your secrets, the storage account behind an analytics pipeline. The pattern that makes a portfolio project look professional is exactly this — a public web front end whose backing storage and database are unreachable except through private endpoints, so you can point at a running URL and still prove the data tier has no public IP.
That is the whole idea. A private endpoint is not a firewall rule; it is a change of address. You move the service off the public street and into your own building, then decide, deliberately, whether the street door stays open at all.