TL;DR
- A service endpoint sends traffic from a subnet to an Azure service over the Microsoft backbone. The service keeps its public IP, and you lock it down with firewall rules.
- A private endpoint is a network interface with a private IP in your VNet. It maps to one specific resource, such as one storage account, through Azure Private Link.
- Security: service endpoints secure the path. Private endpoints secure the destination, which closes the data-exfiltration gap.
- Reach: private endpoints work from peered VNets and from on-premises over VPN or ExpressRoute. Service endpoints do not work from on-premises.
- Cost and effort: service endpoints are free and take one subnet setting. Private endpoints are billed per hour and per GB and need private DNS. Microsoft recommends private endpoints for secure, private access.
If you need to keep Azure PaaS traffic off the internet, use a private endpoint for production and sensitive data. Use a service endpoint when you only need a cheap, quick lockdown from inside one VNet. That is the answer. The rest of this post explains why, and what it costs to get it wrong.
Both features exist to stop your VMs, containers, and apps from talking to storage accounts, databases, and key vaults over the open internet. Most engineers treat them as two flavors of the same thing: "private connectivity, pick one." The Azure portal does not help, because both live under a "Networking" blade and both make a firewall rule say Selected networks.
What is a service endpoint, and where does it stop?
A service endpoint is a subnet setting that extends your virtual network's identity to an Azure PaaS service and routes traffic to it over the Microsoft backbone. The service keeps its public IP and its public DNS name. You then add a virtual network rule to the service's firewall, so only that subnet gets in.
How it works
You enable it with one checkbox per service on a subnet, for example Microsoft.Storage or Microsoft.Sql. From then on, traffic from that subnet to the service carries your VMs' private source IPs instead of public ones. That lets the storage account or SQL server recognize "this request came from subnet X" and allow it. There is no extra charge, no NAT, and no gateway.
Two details trip people up during rollout:
- Open connections drop. When you enable the endpoint, the source IP switch closes existing TCP connections to that service. Do it in a maintenance window.
- Your firewall stops seeing that traffic. Service endpoint routes override user-defined routes and BGP routes for the service's address prefixes. If you force-tunnel everything through Azure Firewall, storage traffic from that subnet now skips it.
Where it stops
The service endpoint makes the path private. But the destination is still a public service that any Azure customer can reach. That has two consequences.
First, on-premises traffic is out of scope. Microsoft's documentation says service endpoints cannot carry traffic from on-premises to Azure services. To let your data center in, you have to allowlist its public NAT IPs on the resource firewall. Your private resource is then open to the public internet, filtered by IP.
Second, and more important, access is scoped to the whole service, not your resource. Your VNet rule protects your storage account from strangers. It does not stop a compromised VM in your subnet from uploading data to a storage account an attacker owns. Both accounts live behind the same Microsoft.Storage endpoint.
The partial fix is service endpoint policies. They are free allowlists that limit a subnet to named storage accounts, resource groups, or subscriptions.
A service endpoint guards your resource's front door. It does nothing about which doors your own workloads walk through. That is the gap a private endpoint closes.
What is a private endpoint, and why does it change your threat model?
A private endpoint is a network interface that takes a private IP from your subnet and maps it to one specific PaaS resource through Azure Private Link. Clients connect to that IP instead of the public endpoint. That works from the same VNet, from peered VNets, and from on-premises over VPN or ExpressRoute.
How it works
When you create a private endpoint for, say, the blob service of contosodata, Azure drops a NIC into your subnet with an IP like 10.1.2.5. That IP stays the same for the endpoint's whole life. Traffic to it rides the Microsoft backbone to that one storage account.
The key word is one. Microsoft's Private Link overview states that a private endpoint maps to a single resource instance, not the whole service: "Access to any other resource in the service is blocked".
That changes the exfiltration math. With service endpoints, a compromised VM can still push data to any storage account in Azure. With private endpoints and outbound internet locked down, the only storage it can reach is the one you mapped.
What else you get
- Hybrid reach. On-premises servers reach the service over ExpressRoute private peering or VPN. No Microsoft peering, no public NAT IPs on an allowlist.
- Cross-region and cross-tenant access. The endpoint must sit in the same region as its VNet, but the target resource can be in another region. A manual approval workflow lets a resource owner in another tenant accept or reject your connection.
- NSG and UDR support. Private endpoints support network security groups, route tables, and application security groups once you enable network policies on the subnet. Two limits remain: NSG flow logs do not capture inbound traffic to the endpoint, and the portal does not show effective routes on its NIC.
The trap most people miss
Creating a private endpoint does not close the public door. Microsoft's docs say plainly that a private endpoint does not necessarily restrict public network access. Until you set the resource's public network access to Disabled, it is still reachable from the internet, with whatever firewall rules it had before.
So a private endpoint wins on security and reach. But it hands you two new bills: one in dollars, one in DNS. Before those, here are the two options side by side.
Private endpoint vs service endpoint: side-by-side comparison
The core difference is where the private IP lives. With a service endpoint, your VMs keep private source IPs and the service stays public. With a private endpoint, the service itself gets a private IP inside your VNet. Every other row in this table follows from that.
On the left, the service endpoint opens the subnet's path to the whole Storage service, so any account stays reachable and on-premises traffic is left out. On the right, the private endpoint maps to one account and also accepts traffic from on-premises.
| Criterion | Service endpoint | Private endpoint |
|---|---|---|
| Who gets the private IP | Your clients (source IP). The service keeps its public IP | The service, through a NIC in your subnet |
| Access scope | The whole service (every storage account in Azure), unless you add a service endpoint policy (Storage only) | One resource instance and one subresource, such as blob or file |
| Data-exfiltration protection | No | Yes |
| Public endpoint | Stays on, restricted by VNet rules | Can be disabled entirely |
| DNS changes | None. The name still resolves to a public IP | Required: a privatelink.* private DNS zone or equivalent |
| Access from on-premises | No. You must allowlist public NAT IPs | Yes, over VPN or ExpressRoute private peering |
| Access from peered VNets | Only if you enable it on each subnet | Yes, regional and global peering |
| Routing through your firewall | Bypasses user-defined routes for the service's prefixes | Can be routed through an NVA or Azure Firewall |
| Service coverage | About 10 services | 70+ services |
| Price | Free | Per endpoint-hour plus per GB processed |
| Setup effort | One checkbox per subnet | Endpoint, DNS zone, VNet links, and sometimes approval |
Why do private endpoints break? The DNS problem
A private endpoint only works if the service's normal hostname resolves to the endpoint's private IP. Azure adds a CNAME from the public name to a privatelink name. A private DNS zone linked to your VNet answers that name with the private IP. Any client whose DNS can't see that zone gets the public IP instead. It either fails or quietly goes over the public path.
What the resolution chain looks like
Your apps keep using the same connection string. The redirection happens in DNS:
contosodata.blob.core.windows.net
CNAME contosodata.privatelink.blob.core.windows.net
inside your VNet (zone linked): A 10.1.2.5 <- private endpoint
anywhere else: A <public IP> <- public endpoint
Test it from the client that matters, not from your laptop. Run nslookup contosodata.blob.core.windows.net and check that the answer is a 10.x, 172.16–31.x, or 192.168.x address.
Five DNS mistakes to check first
-
The zone isn't linked where the queries land. In hub-and-spoke, clients often use DNS servers in the hub. Link
privatelink.blob.core.windows.netto the VNet those servers live in, not only to the spoke. -
Custom or on-premises DNS doesn't forward to Azure. Your DNS servers need a conditional forwarder for the public zone, such as
blob.core.windows.net, pointing at Azure DNS. Azure DNS Private Resolver is Microsoft's managed option for this. Without it, on-prem clients resolve the public IP, and your "private" setup is private for VMs only. -
Other people's storage accounts stop resolving. Once your VNet uses a
privatelink.blobzone, lookups for any other account that has its own private endpoint can return NXDOMAIN. Enable fallback to internet on the zone's VNet link to fix this. -
Duplicate zones per spoke. Creating a separate
privatelink.blobzone in every spoke VNet splits your records. Keep one zone per service type, centrally, and link it everywhere. Microsoft also warns against mixing records for different services in one zone. - Hosts-file fixes that never leave. Microsoft recommends the hosts file for testing only. A hard-coded IP survives long after the endpoint changes.
One security point that confuses people: the public CNAME chain is resolvable from anywhere by design. That only proves a resource with that name exists. It does not expose your private IP or grant access. Microsoft's docs sum it up: "Resource existence is enumerable; resource access is not."
Once DNS is right, the choice between the two features comes down to five questions.
Which should you choose? A 5-step decision framework
Default to a private endpoint, and pick a service endpoint only when every one of the first four questions below is a "no." That matches Microsoft's own position. The service endpoint documentation now opens by saying Microsoft "recommends use of Azure Private Link and private endpoints for secure and private access."
Work through the questions in order. The first "yes" decides.
- Does anything outside this VNet need access? That includes on-premises servers, other tenants, or partners. Yes → private endpoint. Service endpoints cannot carry on-premises traffic.
- Is the data sensitive, regulated, or a likely exfiltration target? Yes → private endpoint. Only private endpoints lock a client to one resource instance. If you must stay on service endpoints for now, add a service endpoint policy.
- Must the resource have public network access fully disabled? That might be an audit requirement or an Azure Policy assignment. Yes → private endpoint. With service endpoints, the public endpoint always exists.
- Does the service lack service endpoint support? Service endpoints cover about 10 services. Private Link covers 70+. Not supported → private endpoint.
- None of the above? For a dev/test environment, a single-VNet workload, or non-sensitive data where cost and simplicity win → service endpoint.
A common result is private endpoints for production data stores and key vaults, with service endpoints kept for sandboxes and for subnets where an NVA already filters traffic.
Conclusion: secure the destination, not just the road
Service endpoints and private endpoints are not two flavors of the same feature. A service endpoint is a free, one-checkbox way to make one VNet's path to a public service private. A private endpoint brings one specific resource into your network, where on-premises clients can reach it, attackers can't redirect your traffic to their own accounts, and the public door can close for good.
For production and sensitive data, that difference is worth roughly $7 per endpoint per month and a careful DNS design. For a sandbox, it often isn't.
FAQ
Is a private endpoint more secure than a service endpoint?
Yes, in two ways. A private endpoint maps to one resource instance, so a compromised client cannot use it to reach other accounts in the same service. It also lets you disable the resource's public endpoint entirely. A service endpoint secures the network path, but the service stays publicly addressable.
Do service endpoints work from on-premises?
No. Microsoft's documentation states that service endpoints cannot carry traffic from on-premises networks to Azure services. To allow on-premises access, you must add your public NAT IPs to the resource's IP firewall. Private endpoints, by contrast, are reachable over site-to-site VPN and ExpressRoute private peering.
Are service endpoints free?
Yes. Service endpoints and service endpoint policies carry no extra charge; you pay only the normal price of the target service. Private endpoints bill per hour, with partial hours billed as full hours, plus a per-GB processing fee. Microsoft's AI Landing Zones cost guide estimates about $7.30 per endpoint per month in East US.
Is Azure Private Link the same as a private endpoint?
Not quite. Azure Private Link is the platform technology. A private endpoint is the network interface you create in your VNet to consume a service over Private Link. A Private Link service is the provider side, used to expose your own app behind a Standard Load Balancer to other VNets or tenants.
Do I still need to disable public network access after creating a private endpoint?
Yes. Microsoft notes that a private endpoint does not necessarily restrict public network access. Until you set public network access to Disabled on the resource, it remains reachable through its public endpoint and existing firewall rules. Validate DNS and connectivity from all clients first, then disable it.
*Originally published on Techworld of Florian.
Author
Florian Lenz · Freelance Cloud & Security Architect · Microsoft MVP
Florian fixes clouds that are too complex to run, too locked-in to leave and too messy to audit – on Azure and STACKIT, for regulated industries across Germany and Europe. Migrations like this one are part of the job: version upgrades, hosting plan moves and the unglamorous cleanup that follows. Planning one yourself? Let's talk
Top comments (0)