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.
New to cloud? CAMPUX is a free, build-first course. Start here →
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.
Questions people also ask
What is the difference between a service endpoint and a private endpoint in Azure?
A service endpoint restricts a service's existing public address to traffic from your subnet — the service keeps its public IP, and you add a rule that tells it to accept only your virtual network. A private endpoint gives the service a private IP inside your subnet, so the service itself moves into your network instead of staying reachable at a public address.
Is a private endpoint more secure than a service endpoint?
Yes, for genuinely private access. A private endpoint lets you disable the service's public endpoint entirely, so nothing on the internet can reach it, even with stolen credentials. A service endpoint still leaves a public address standing behind a subnet rule — good enough for many cases, but not what a security review means by "no public access."
Can I use a service endpoint from on-premises?
No. A service endpoint only works for traffic originating inside the virtual network where you enabled it; Microsoft's documentation states outright that endpoints cannot carry traffic from on-premises services to Azure services. If you connect over VPN or ExpressRoute and need that traffic protected, you need a private endpoint instead, not a service endpoint.
Do private endpoints cost money?
Yes. A private endpoint is a billed resource — a network interface with its own private IP, plus the private DNS zone you wire up alongside it. A service endpoint costs nothing; it is a checkbox on a subnet. That price difference is part of why teams default to service endpoints unless a requirement forces the private option.
Which DNS record does a private endpoint use?
A service behind a private endpoint resolves to its private IP address inside your subnet, through a private DNS zone you attach to your virtual network. A service endpoint changes nothing about DNS — the service's name still resolves to its public IP, and only the routing and access rule change underneath it.