Azure Service Endpoint vs Private Endpoint

 

Service Endpoint vs Private Endpoint

By default, services like Azure Storage account will have public endpoint to interact with. That means it has an address that can be communicated from the internet as it has internet routable.

 

Service Endpoint

At the same time the service can be communicated from the internal Virtual network as well. But it uses the same internet connectivity to communicate. The communication to the storage account still can be controlled using AD integration or even Firewall by saying only certain IP addresses are allowed to access the storage account.

On other hand, let’s say a VNET with various subnets and one of the subnet need to access the Storage account service. In this case, we need to make this subnet a known entity to Storage account service by creating Service endpoint. Then we can add a rule in the Firewall to allow traffic to Storage account coming only from this specific subnet (service endpoint). But this is still having open public endpoint and communication is happening to Public IP of Storage account via Azure backbone instead of Internet.

 

 

Private Endpoint:

Unlike Service Endpoint, we can create a private endpoint for a specific subnet, a private NIC will be created on the subnet to have access to the storage account. This private endpoint NIC will represent a connection directly to a specific instance, a storage account in this case. Using private endpoint IP, the peered virtual network or even on-premises network(connect via S2S VPN or Express route) can connect the storage account(IP path must be established to private endpoint). Private endpoint requires special DNS configuration to resolve the storage account name to Private Endpoint IP address via Alias. This can be done using Azure private DNS. So, we can remove public endpoint on Storage account service to allow communication only via private endpoint. Private endpoint is recommended for PaaS service.

 Comparison Table:

  

	Service endpoints	Private endpoints
Scope	Per service	Per instance
Connectivity	Azure PaaS public IP is still used, the traffic between VNET and the public IP of Azure PaaS service goes over the Azure backbone network.	Azure PaaS service receives a private IP from your networks used for communication with your VNET
Data security	Traffic leaves virtual network to Azure backbone	No data exfiltration
On-premises connectivity	No native support for On-Prem integrations. Build mainly for Azure VNETs.	Yes, ExpressRoute and VPN tunnels provide support to extend the private Azure PaaS connectivity to the On-Prem networks.
UDRs and NSGs	No specific overlaps exist.	The traffic can bypass the Private Endpoint of you use UDRs and NSGs. Special configuration might be required.
Data protection	Needs to be integrated with a Network Virtual Appliance/Firewall of exfiltration protection is required.	Built-in data protection
Cost	No additional cost (free of use)	The cost is based on inbound, outbound traffic and number of endpoints. Depending on the total traffic, the total cost can grow easily.
Complexity	Easy to configure and setup from Azure Portal	Involves updates to DNS (Azure Private DNS) and where the service will attach to your VNET.
Cross-region support	No native support for cross-region support	Has full support for access resources across regions and across Azure AD tenants