Skip to content

Service endpoints vs private endpoints in Azure

Compare Azure service and private endpoints, destination addresses, storage firewall rules and private DNS requirements.

Read the guide
Read, then practise

Compare the concepts, work through a scenario and check your answer.

AZ-104 guide · no account required

Compare the destination address

Both options can keep traffic on the Azure backbone. The destination address and access model distinguish them.

Compare the destination address
FeatureService endpointPrivate endpoint
DestinationService public IPPrivate IP in your VNet
Network controlAllow the subnet on the service firewallConnect to a specific service resource
DNSUses the public service endpointResolve the service name to the private IP

Match the connectivity requirement

A service endpoint identifies traffic from an enabled subnet to a supported service. Configure the service firewall too; enabling the endpoint alone does not restrict the resource.

A private endpoint connects to a service subresource, such as Blob storage, through a private IP. It can support on-premises access over VPN or ExpressRoute when routing and DNS are configured. Creating one does not automatically disable public access to the service.

Plan DNS before testing connectivity

Applications keep using the ordinary service hostname. For Blob storage, a private DNS zone such as privatelink.blob.core.windows.net supplies the private address. Link the zone to the relevant VNet.

On-premises clients need a DNS resolution path, for example forwarding through Azure DNS Private Resolver. A VNet zone link alone does not configure their DNS. If the requirement explicitly calls for a private destination IP, select a private endpoint and verify name resolution.

Check your understanding

Question 1Private endpoints and hybrid DNS

Contoso connects its on-premises network to VNet1 through an ExpressRoute circuit with private peering. Application servers in Subnet1 of VNet1 use Azure-provided DNS. On-premises analysts use Contoso’s on-premises DNS servers, which resolve internet names through public DNS. Both groups must read blobs from the storage account storage1 by using the URL https://storage1.blob.core.windows.net, which must not change. The storage team will set Public network access on storage1 to Disabled, and all traffic to storage1 must use private IP addresses and never cross the internet. Which configuration should you implement?

  1. Enable a Microsoft.Storage service endpoint on Subnet1, add Subnet1 to the virtual network rules of storage1, and add the public IP range of the on-premises network to the storage1 firewall
  2. Create a private endpoint for the blob subresource of storage1 in Subnet1, and link the privatelink.blob.core.windows.net private DNS zone to VNet1. Make no on-premises DNS changes, because ExpressRoute private peering already advertises Subnet1 to on-premises
  3. Create a private endpoint for the blob subresource of storage1 in Subnet1, link the privatelink.blob.core.windows.net private DNS zone to VNet1, deploy an Azure DNS Private Resolver inbound endpoint in VNet1, and add an on-premises conditional forwarder for blob.core.windows.net to the inbound endpoint’s IP address
  4. Create a private endpoint for the blob subresource of storage1 in Subnet1, link the privatelink.blob.core.windows.net private DNS zone to VNet1, and add an on-premises conditional forwarder for blob.core.windows.net to 168.63.129.16
Show answer and explanation

Correct answer: C · Create a private endpoint for the blob subresource of storage1 in Subnet1, link the privatelink.blob.core.windows.net private DNS zone to VNet1, deploy an Azure DNS Private Resolver inbound endpoint in VNet1, and add an on-premises conditional forwarder for blob.core.windows.net to the inbound endpoint’s IP address

Only a private endpoint gives storage1 a private IP address, and with public network access disabled only private endpoint traffic is accepted. The private DNS zone linked to VNet1 makes the unchanged URL resolve to that private IP for the application servers. On-premises DNS cannot query that zone directly: queries must come from inside a linked virtual network. A Private Resolver inbound endpoint accepts them there, and Microsoft recommends forwarding the public zone, blob.core.windows.net, not the privatelink zone. The analysts then get the private IP, and their traffic flows over ExpressRoute private peering.

Why the other choices do not fit

  • A service endpoint still targets storage1’s public endpoint, and it only applies to traffic that starts inside the subnet, not on-premises. With public network access disabled, virtual network and IP firewall rules no longer admit anything, and the on-premises path would cross the internet anyway.
  • The routing is there, but name resolution is not. On-premises DNS resolves storage1.blob.core.windows.net through public DNS to the public IP address, so the analysts’ traffic heads to the internet and is rejected because public access is disabled.
  • This forwards the right zone to the wrong place. 168.63.129.16 is a virtual IP that is reachable only from inside an Azure virtual network, never across ExpressRoute or VPN, so on-premises queries time out.
Private endpoint DNS integration scenariosUse private endpoints for Azure StorageAzure Storage firewall rules and network accessWhat is IP address 168.63.129.16?

Continue your preparation

Original practice scenarios adapted from the Pass104 question bank, not actual Microsoft exam questions. Consult Microsoft Learn for current service details. Pass104 is independent of Microsoft.