Private endpoint vs service endpoint in Azure

A private endpoint puts a network interface with a private IP address from your subnet in front of an Azure service, so the service gets an address inside your network. A service endpoint keeps the service on its public address but tells it which subnet the traffic comes from, so the service can accept only that subnet. The decision rule: if the scenario needs a private IP, access from on-premises, or public access fully disabled, pick the private endpoint. If it needs a cheap, no-DNS restriction to certain VNet subnets, a service endpoint works. Microsoft itself recommends Private Link and private endpoints for secure and private access to platform services.

Follow one packet through each option

The difference is easiest to see by following a request from a VM to mystorage.blob.core.windows.net.

Without either. DNS returns a public IP. The VM’s traffic leaves with a public source address. The storage firewall can only filter by that public address.

With a service endpoint on the VM’s subnet. DNS is unchanged and still returns the public IP. The route to the service is more specific (next hop type VirtualNetworkServiceEndpoint), so traffic goes straight over the Azure backbone, bypassing any forced-tunnel route to an appliance. The source address the service sees switches from a public to the VM’s private address, and the service can now check the subnet identity. You add a virtual network rule on the storage account that names the subnet. Microsoft notes that existing firewall rules based on Azure public IPs stop working after the switch, and open connections to that service are dropped when you enable the endpoint.

With a private endpoint. A network interface appears in a subnet of your choice with a private IP. DNS must now return that private IP for the service name, normally through a private DNS zone linked to the VNet. The traffic stays entirely on private addresses. The service’s public endpoint is still there unless you disable public network access on the resource, which Microsoft’s documentation points out explicitly: a private endpoint gives a private address but does not by itself restrict public access.

Side by side

Two more details that matter. A private endpoint must be in the same region and subscription as its virtual network, but the target resource can be in another region. Each sub-resource needs its own endpoint: for storage, blob and file need separate private endpoints. Private endpoints can also be reached from peered VNets, which is how a hub-and-spoke design shares them; see VNets, subnets and peering.

Worked example: lock down a storage account

A reporting app in snet-app must read a storage account, and a finance analyst must reach it from the office over a site-to-site VPN. No access from the internet.

• A service endpoint on snet-app plus a virtual network rule would let the app in. The analyst cannot get in through the VPN, because service endpoints do not carry on-premises traffic, and the public endpoint would still exist.
• A private endpoint for the blob sub-resource in snet-app, a private DNS zone privatelink.blob.core.windows.net linked to the VNet (and a DNS forwarder for on-premises), and public network access disabled meets both needs. The analyst resolves the account name to the private IP and the traffic flows across the VPN.

The last step is the one exam writers like to hide. Without it, the storage account is still reachable from the internet, subject to its firewall.

Which exams test this

How exam questions are built around it

• “Private IP address”, “on-premises over VPN or ExpressRoute”, “disable public access”: private endpoint.
• “Restrict to a subnet”, “no DNS changes”, “no additional cost”: service endpoint.
• “Traffic must not traverse the internet”: both stay on the Microsoft backbone, so look for a second constraint to decide. Do not assume only the private endpoint qualifies.
• The missing DNS step: a private endpoint exists but clients still reach the public IP. The fix is the private DNS zone and its VNet link.
• The missing public-access step: the private endpoint works, yet the account is still reachable from outside. The fix is disabling public network access.
• A service endpoint on the wrong side: it is enabled on the subnet, and the rule is added on the service. Both are needed.

Practice questions

Go deeper

• What is a private endpoint? (properties, approval workflow, DNS)
• Virtual network service endpoints (limitations, on-premises access)
• Related guides: NSG rule evaluation, Azure Firewall vs NSG vs WAF, Storage redundancy explained, SAS tokens and stored access policies