You want a storage account (or a SQL database, or a key vault) to be reachable only from your own virtual network. Azure gives you two ways to do it: a service endpoint or a private endpoint. The names are nearly identical; the way they work is not, and exam questions are built on the difference.
The one-sentence difference
- A service endpoint makes your subnet trusted by the service’s public endpoint.
- A private endpoint brings one specific resource into your network, on a private IP address from your own range.
Everything else follows from that.
How a service endpoint works
You switch a service endpoint on per subnet, per service: for example Microsoft.Storage on Subnet A. From then on:
- Traffic from that subnet to the service travels over the Microsoft backbone, and the service sees the subnet’s private IP address as the source instead of a public one.
- So the service’s firewall can allow exactly that subnet (“VNet1 / Subnet A”) and block everything else.
- The service still has its public endpoint, and its name still resolves to a public IP address. Nothing changes in DNS.
- It’s free.
How a private endpoint works
A private endpoint is a network interface in your subnet with a private IP address, say 10.0.1.5, connected through Azure Private Link to one resource: this storage account, not every storage account in Azure.
- DNS does the redirection. A private DNS zone such as
privatelink.blob.core.windows.net makes the account’s normal name resolve to 10.0.1.5 instead of the public address, so applications don’t change their connection strings.
- Public access can be switched off completely, because nothing needs it any more.
- It isn’t free: there’s an hourly charge per endpoint plus a charge per GB of data processed.
The trap: on-premises access
Service endpoints only work for traffic that starts in an Azure subnet that has them switched on. Traffic arriving from on-premises over a VPN or ExpressRoute can’t use them. If on-premises clients must reach the service, the only service-endpoint answer is to allow your on-premises public (NAT) IP addresses in the service’s firewall, which is no longer private access.
A private endpoint is just an IP address in your virtual network, so anything that can route to the virtual network can reach it: on-premises networks over VPN or ExpressRoute, and peered virtual networks.
So when a requirement says “on-premises users must reach the storage account privately” or “over ExpressRoute private peering”, the answer is a private endpoint.
Three more traps
- DNS decides whether the private endpoint is used. If a client still resolves the public address, it goes the public way and the private endpoint does nothing. Azure clients get the answer from the private DNS zone linked to their virtual network. On-premises DNS servers should conditionally forward the public zone (for example
blob.core.windows.net, not the privatelink zone) to an Azure DNS Private Resolver inbound endpoint.
- Data exfiltration. A service endpoint trusts the whole service: a compromised VM in the subnet could still copy data to a storage account that belongs to someone else. A private endpoint maps to your resource only, which is why Microsoft describes it as having built-in exfiltration protection. (For storage, service endpoint policies can narrow a service endpoint down to named accounts.)
- Service endpoints are per subnet. Every subnet that needs access needs its own service endpoint and its own rule in the service’s firewall.
Pick it in five seconds
| Free and simple, and only Azure subnets need access |
Service endpoint |
| Private access from on-premises or peered networks |
Private endpoint |
| Public network access switched off completely |
Private endpoint |
| Protection against data being copied to other accounts |
Private endpoint |
| …and whenever you choose a private endpoint |
check the DNS |
Microsoft’s own guidance leans towards Private Link for new designs, because of the on-premises and exfiltration advantages, but service endpoints remain a valid, free answer when the requirements are simple.
Go deeper
Private access has a chapter of its own in the AZ-700 study guide (chapter 12, with private endpoint DNS covered again in the DNS chapter). It’s in chapter 12 of the AZ-104 study guide, the networking chapter of the AZ-305 study guide and chapter 8 of the SC-500 study guide, each with the traps called out like these. Facts checked against Microsoft Learn on 4 October 2026.
