Service endpoints vs private endpoints: restrict the public door, or build a private one
Two Azure features with confusingly similar names both promise to keep a service off the open internet. They do it in opposite ways — one locks the public door, the other builds a private one — and the difference decides which is right.
You want your storage account or database reachable from your network but not from the whole internet. Azure hands you two tools with almost identical names: service endpoints and private endpoints. People reach for whichever they heard first and sometimes get the weaker protection by accident. The clean way to tell them apart is to ask one question: does the service keep its public address, or get a private one?
Service endpoint: a bouncer on the public door
A virtual network service endpoint, in Microsoft's words, provides "secure and direct connectivity to Azure services over an optimized route through the Azure backbone network," letting "private IP addresses reach Azure services without requiring public IP addresses." Here is the key: the service keeps its public endpoint. What changes is that you add a virtual-network rule so the service accepts traffic only from your subnet, and your subnet's traffic reaches it over the Azure backbone using its private source IP instead of a public one.
Think of it as putting a bouncer on the existing public door: the door is still there, but it only lets in people from your network. It is free, it is a single checkbox on a subnet, and it keeps traffic on Azure's backbone. Two things it does not do: it does not work from on-premises (the docs are explicit — "Endpoints can't be used for traffic from your on-premises services to Azure services"), and DNS still resolves the service name to its public IP.
Private endpoint: a private door with its own address
A private endpoint is a different animal. It is a network interface with a private IP from your own subnet, put in front of the service via Azure Private Link — the service is brought into your virtual network with a private address. Now the service has a private door, and you can brick up the public one entirely. Because it is a real private IP, it works across peered networks and from on-premises over VPN or ExpressRoute, and the service's name resolves to that private IP (with a private DNS zone). It costs money, and it is the option auditors mean when they say "no public access, full stop." (I wrote a whole note on how private endpoints work, including the DNS gotcha.)
| Service endpoint | Private endpoint | |
|---|---|---|
| The service's IP | Stays public | Gets a private IP in your subnet |
| Protection | Restricts the public door to your subnet | Builds a private door; public can be off |
| Reaches from on-premises | No | Yes (VPN / ExpressRoute) |
| DNS resolves to | The public IP | The private IP (private DNS zone) |
| Cost | Free | Paid |
| Setup | A checkbox on a subnet | A resource + DNS wiring |
A service endpoint locks the public door to your subnet. A private endpoint moves the service into your building and lets you wall the street off entirely.
The service-endpoints documentation opens with a note: Microsoft recommends Azure Private Link and private endpoints for secure and private access to services. Service endpoints are still useful — free, simple, backbone-routed — but when the requirement is genuinely private access, especially from on-premises, private endpoints are the intended tool.
So which do you use?
- Cheap, quick, everything is inside Azure, and "off the public internet from other networks" is enough? A service endpoint. One checkbox, no cost, and the service only answers your subnet.
- You need true private access — a private IP, reachability from on-premises, or the public endpoint fully disabled? A private endpoint. It is what security reviews are looking for.
The mistake to avoid is assuming they are interchangeable because the names rhyme. One is a firewall rule that keeps the public address; the other is a change of address. Say that distinction out loud in an interview — "a service endpoint restricts the public endpoint to my subnet; a private endpoint gives the service a private IP and can remove the public one" — and you have shown you understand Azure networking, not just its vocabulary.