If you’ve spent any time in Azure networking docs, you’ve hit the same wall: “Private Endpoint” and “Azure Private Link” get used almost interchangeably, and Service Endpoints sit next to both looking like a cheaper version of the same thing. It isn’t. Short version: Azure Private Link is the underlying platform. A Private Endpoint is the actual resource you create — a network interface with a private IP — that uses Private Link to reach a service. A Service Endpoint is a completely different, older mechanism that doesn’t create any interface at all. Mixing these up causes real production mistakes: people assume a service endpoint fully isolates a storage account, or that a private endpoint automatically blocks the public path. Neither is true by default.
What Azure Service Endpoints Actually Do
A service endpoint extends your virtual network’s identity to an Azure service so that traffic from a specific subnet reaches that service over the Microsoft Azure backbone network instead of a generic internet route. You turn it on per subnet, per service (Microsoft.Storage, Microsoft.Sql, Microsoft.KeyVault, and so on), and the source IP of traffic leaving that subnet switches from public to the VM’s private VNet IP. You then add a VNet rule on the resource’s firewall that only allows traffic from that subnet’s identity.
Real example: a storage account’s firewall currently allows “all networks.” You enable the Microsoft.Storage service endpoint on the subnet your app VMs sit in, then flip the storage firewall to allow only that subnet. Requests from those VMs now carry the private IP as their source, and the firewall recognizes and allows them while refusing anonymous internet traffic.
The limitation that trips people up: the storage account still has a public IP and public DNS name the whole time. Microsoft’s docs are explicit that “DNS entries for Azure services remain as-is today and continue to resolve to public IP addresses.” You’re gating the resource with a VNet-aware firewall rule, not hiding it. Service endpoints also flatly don’t work from on-premises — the feature only applies to traffic originating inside an Azure VNet. A server in your datacenter still needs its NAT IP allowed directly in the resource firewall; the service endpoint identity doesn’t extend that far.
What a Private Endpoint Actually Does
A private endpoint is a network interface that gets a real private IP from your subnet and maps to one specific instance of a resource — not the whole service. Microsoft’s docs put it plainly: “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.” That clause is the terminology answer everyone’s searching for — a private endpoint is a resource; Private Link is the technology that makes it work.
Real example: you create a private endpoint targeting the blob subresource of a storage account, deployed into a subnet. Azure provisions a NIC with an address like 10.0.1.4. Need file-share access on that same account too? That’s a second private endpoint for the file subresource — they’re scoped per subresource, not per service.
The limitation nobody mentions until it bites: creating the private endpoint doesn’t automatically block the public one. The resource stays reachable over the internet unless you separately set Public network access to Disabled on the resource itself. Most “I set up a private endpoint and my data’s still exposed” incidents trace back to skipping that step. You also need DNS pointed at the private IP — its own setup step, covered below.
What Azure Private Link Actually Is
Private Link is the platform underneath both private endpoints (the consumer side) and Private Link Service (the provider side, for publishing your own service behind a standard load balancer to other people’s private endpoints). Per Microsoft: “Azure Private Link enables you to access Azure PaaS Services… over a private endpoint in your virtual network. Traffic between your virtual network and the service travels the Microsoft backbone network.” It’s why private endpoints reach across peered VNets, across regions, and across on-premises networks over VPN or ExpressRoute without touching the public internet or needing ExpressRoute Microsoft peering.
Real example: your VNet sits in East US, but the SQL Managed Instance you need to reach privately lives in West Europe. Private Link explicitly supports this — the private-link resource can live in a different region than the VNet and the private endpoint, which is Microsoft’s own “global reach” use case. A service endpoint can’t do that for region-locked services, and it can’t reach on-premises connections at all.
The limitation: Private Link isn’t free, and every PaaS service onboards to it on its own schedule — not everything supports a private endpoint yet, so you sometimes end up running both mechanisms side by side out of necessity, not preference.
The Backbone Myth You Should Drop
Service endpoints are not “public internet” traffic that private endpoints magically fix. Microsoft’s docs state service endpoints “always take service traffic directly from your virtual network to the service on the Microsoft Azure backbone network” — the same backbone claim Private Link makes. The real difference isn’t the wire path, it’s the destination’s identity. A service endpoint leaves the resource’s public IP and FQDN in place, relying on a VNet-aware firewall rule to gate who gets through. A private endpoint pulls the resource into your VNet with its own private IP, and you can kill the public path entirely by disabling public network access.
The DNS Problem Nobody Warns You About
Service endpoints need zero DNS changes — part of why they’re simple. Private endpoints need a working private DNS setup, or traffic quietly keeps going to the public IP even though you built the whole private endpoint. Azure’s pattern is a CNAME chain: a public record like mystorageaccount.blob.core.windows.net gets a CNAME to mystorageaccount.privatelink.blob.core.windows.net, and you need a private DNS zone named exactly privatelink.blob.core.windows.net, linked to your VNet, holding the A record that resolves to the private endpoint’s actual IP.
The counterintuitive part, straight from Microsoft’s docs: that public privatelink.* CNAME is deliberately resolvable from anywhere on the internet, on purpose, for hybrid migration scenarios. A successful public lookup doesn’t mean anything leaked — it confirms a resource with that name exists in Azure’s namespace, nothing about whether a private endpoint is attached or what its IP is. Access control and DNS resolution are separate concerns by design; don’t treat a resolvable name as a finding. Two other documented mistakes to avoid: overriding a zone still resolving public traffic for other clients without DNS forwarding configured, and putting two different services’ records in the same private DNS zone, which causes silent A-record collisions.
Which One Should You Use
Pick based on what you’re actually protecting against, not which one sounds more “secure” on paper.
| Factor | Service Endpoint | Private Endpoint / Private Link |
|---|---|---|
| Cost | Free | ~$0.01/hour per endpoint (~$7.30/month) + per-GB data processing — confirm current rates in the Azure Pricing Calculator |
| DNS setup | None — existing public DNS keeps working | Required — private DNS zone per service, linked to the VNet |
| Resource still has a public IP | Yes, always | Only if Public network access is left enabled |
| Granularity | Whole service, per subnet | Per subresource (e.g., blob vs. file) on a specific instance |
| Cross-region | Yes for most services; Azure SQL is same-region only | Yes — the private-link resource can sit in a different region than the VNet |
| Cross-VNet (peered) | Must be enabled on every subnet independently | Works across regionally and globally peered VNets |
| On-premises via VPN/ExpressRoute | Not supported | Fully supported, including ExpressRoute private peering |
| Setup effort | One checkbox plus a firewall rule | Create endpoint, approve connection, configure DNS |
Use a service endpoint when traffic originates entirely inside Azure, cost has to stay at zero, and you don’t need on-premises access or true network isolation — just a tighter firewall rule than “allow my office IP.” Use a private endpoint when on-premises access over VPN/ExpressRoute is a requirement, when you need to fully remove the public endpoint instead of just gating it, when compliance wants a demonstrable private IP path instead of a firewall allow-list, or when a service endpoint’s region restrictions get in the way of a cross-region or peered-VNet design.
⚠️ Note: don’t assume “I added a private endpoint” means “the public endpoint is gone.” Check Public network access on the resource explicitly — leaving it enabled next to a private endpoint is one of the most common half-finished migrations in Azure networking reviews.
Frequently Asked Questions
Q: Is Azure Private Link the same thing as a Private Endpoint?
A: No. Private Link is the underlying platform; a Private Endpoint is the network interface resource you create that uses Private Link to reach a service privately. Private Link also covers Private Link Service, the provider-side piece for publishing your own service to other people’s private endpoints.
Q: Do Service Endpoints send traffic over the public internet?
A: No — Microsoft’s docs state service endpoint traffic always routes over the Azure backbone network, same as Private Link traffic. The real difference is that the destination keeps a public IP and DNS name with a service endpoint, while a private endpoint gives it a private IP you can fully isolate.
Q: Can I reach a resource secured with a Service Endpoint from on-premises?
A: Not through the service endpoint itself — it only covers traffic originating inside an Azure VNet. You’d separately allow your VPN or ExpressRoute NAT IP in the resource’s firewall, or switch to a private endpoint, which supports on-premises access over VPN and ExpressRoute natively.
Q: Does a Private Endpoint automatically block public internet access to the resource?
A: No. You have to explicitly set Public network access to Disabled on the resource. Creating the private endpoint alone just adds a private path — it doesn’t remove the public one.
Q: How much does a Private Endpoint cost?
A: Roughly $0.01 per hour per endpoint (about $7.30/month) plus roughly $0.01 per GB processed in each direction at the standard tier, per Azure’s published pricing structure — rates vary by region, so check current numbers before budgeting at scale.
Quick Summary
- Private Link is the technology; a Private Endpoint is the network interface resource that uses it — platform vs. implementation, not interchangeable terms.
- Service Endpoints are free and need zero DNS changes, but the resource keeps its public IP and DNS name throughout — you’re gating access with a firewall rule, not hiding the resource.
- Private Endpoints cost roughly $7.30/month per endpoint plus per-GB data processing, and need a private DNS zone to actually route traffic to the private IP instead of the public one.
- Only Private Endpoints support on-premises access over VPN or ExpressRoute — Service Endpoints are Azure-VNet-only, full stop.
- A Private Endpoint doesn’t block the public endpoint by itself — you must explicitly disable Public network access on the resource.