Azure Private Endpoints Vs Service Endpoints

Following a deep dive into the world of Azure endpoints, I found it interesting that there is a misconception of the primary uses (and any secondary uses) of Azure Private Endpoints. It seems that they are being used when a Service Endpoint is perfectly suitable (and free) to use. I have lightly written this up as a reminder for me in future and if its of use for anyone else.

The following is broken up between Public, Private and Service endpoints. I'll try and capture the primary use case for each, pros and cons and anything further of interest. As this topic is vast, there are bound to be a few things not covered but I shall intent to keep this topic updated as and when its useful to do so.

Public Endpoint

Public Endpoint
Figure: #1 Public Endpoint

Traffic is routed over the internet, using the public IP endpoints.

When to use Public Endpoints:
When secure but public internet routing  isn't an issue for either direct to Storage account or via VNET components.


1.Simple solution

2.Storage account options to control networking connection type (TLS version) and source access via Firewalls and virtual networks (public internet, VNETs)

3.No additional costs


1.Traffic routed over public internet (if this is an issue)

Private Endpoint

Private Endpoint
Figure: #2 Private Endpoint

Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Private Endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet. You can think of this as a new virtual network card on the PaaS component (e.g. Storage account) which is then assigned to the VNET/Subnet. This addresses the main exam question of accessing an Azure PaaS component DIRECTLY via Express Route or Site-To-Site VPN and not having to target the public IP endpoint. A service endpoint doesn't solve this problem.

When to use Private Endpoints:
When non-public internet access is required to an Azure PaaS component via express route or S2S VPN. Other uses are possible, but a standard Service Endpoint should be considered as a Private Endpoint is likely to be overkill for a non-express route or S2S VPN use case.


1.Private address used

2.No public internet traffic or public IP is present

3.Optional data exfiltration, locking private access directly to the storage account instance, preventing communications with other instances


1.Dependant on scenario, the set-up can be significantly more involved than service endpoints*

2.Charges per hour, inbound traffic and outbound traffic

3.NSG is not supported on private endpoints

4.Targets a specific use case

5.Each storage account (and type) needs its own private endpoint

*It's important to correctly configure your DNS settings to resolve the private endpoint IP address to the fully qualified domain name (FQDN) of the connection string. Existing Microsoft Azure services might already have a DNS configuration for a public endpoint. This configuration must be overridden to connect using your private endpoint.


Service Endpoint

Service Endpoint
Figure: #4 Service Endpoint

Virtual network rule(s) can secure the Azure service resources to your virtual network. The rule addition provides improved security by fully removing public internet access to resources and allowing traffic only from your virtual network.

When service endpoint is enabled for storage accounts, the identity of the virtual network  will be made available to the storage account(s). All source IPs from the 
VNET/Subnet(s) will be private IPs.

When the VM connects to the storage account, the storage account knows which virtual network and which subnet the request has come from. The VM IP visibile to the storage account will be the private IP address and not the public IP. The VM still believes it is connecting to the storage account public IP, but the traffic never leave the Azure  backbone. i.e. private IP is used

When to use Service Endpoint:
When restricted or non-public internet access is required to an Azure PaaS component from an existing VNET


1.Simple set-up

   a.create service end point on VNET/Subnet(s)

   b.Limit storage account network access to same VNET/subnet(s)

2.No additional costs

3.Public address continued to be used, although Azure routing uses internal backbone*

4.No public internet traffic, by configuring PaaS service firewall rules


1.Public address exists although unusable

2.Any existing public IP firewall rules will need to be reconfigured

*Please note that no changes are required to the requesting PaaS component as this continues to use the public endpoint FQDN. Azure returns the private IP rather than the public IP, knowing that a service endpoint is in use.