When it comes to Cloud security, one of our main focuses is to ensure we follow the best solutions for routing our network. Microsoft provides multiple options and solutions to secure our Azure resources. Private Endpoint and Service Endpoint are the two options available for routing connections between azure resources securely.

I have been often asked about the difference between a Private Endpoint and a Service Endpoint. The other question I get asked is which option should you use? In this article, I answer a few questions regarding Private Endpoint and Service Endpoint.

What is a Service Endpoint?

A service endpoint provides secure and direct connectivity to Azure services using the Azure backbone network. When you enable a service endpoint for a subnet, it allows private IP addresses in the VNet to communicate or reach that particular resource type using the public IP of a resource.

For example in the below diagram you enable the service endpoint for Azure storage,

  • The virtual machine will use its private IP to communicate with the public endpoint of the storage account. The storage account will see the private IP of the VM.
  • And when you enable this service, it will be enabled for all the storage accounts\resource types in that region.
  • It essentially exposes the resources in that region and exposes only private IP of the resources within VNET.


  • Improved security for your Azure service resources: VNet private address spaces can overlap. You can’t use overlapping spaces to uniquely identify traffic that originates from your VNet. Service endpoints provide the ability to secure Azure service resources to your virtual network by extending VNet identity to the service. Once you enable service endpoints in your virtual network, you can add a virtual network rule to 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.
  • Optimal routing for Azure service traffic from your virtual network: Today, any routes in your virtual network that force internet traffic to your on-premises and/or virtual appliances also force Azure service traffic to take the same route as the internet traffic. Service endpoints provide optimal routing for Azure traffic. Endpoints always take service traffic directly from your virtual network to the service on the Microsoft Azure backbone network. Keeping traffic on the Azure backbone network allows you to continue auditing and monitoring outbound Internet traffic from your virtual networks, through forced-tunneling, without impacting service traffic.
  • Simple to set up with less management overhead: You no longer need reserved, public IP addresses in your virtual networks to secure Azure resources through IP firewall. There are no Network Address Translation (NAT) or gateway devices required to set up the service endpoints. You can configure service endpoints through a simple click on a subnet. There’s no additional overhead to maintaining the endpoints.


  • Peered, connected, or multiple virtual networks: To secure Azure services to multiple subnets within a virtual network or across multiple virtual networks, you can enable service endpoints on each of the subnets independently, and secure Azure service resources to all of the subnets.
  • Filtering outbound traffic from a virtual network to Azure services: If you want to inspect or filter the traffic sent to an Azure service from a virtual network, you can deploy a network virtual appliance within the virtual network. You can then apply service endpoints to the subnet where the network virtual appliance is deployed, and secure Azure service resources only to this subnet. This scenario might be helpful if you want use network virtual appliance filtering to restrict Azure service access from your virtual network only to specific Azure resources.
  • Securing Azure resources to services deployed directly into virtual networks: You can directly deploy various Azure services into specific subnets in a virtual network. You can secure Azure service resources to managed service subnets by setting up a service endpoint on the managed service subnet.

Pricing and limits

There’s no additional charge for using service endpoints. Certain Azure services, such as Azure Storage Accounts, may enforce limits on the number of subnets used for securing the resource.

What is a Private Endpoint?

Unlike a service endpoint, a private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that’s powered by Azure Private Link. By enabling a private endpoint, you’re bringing the service into your virtual network. If you noticed service endpoint only enables the communication by using private IP within VNET whereas the Private Endpoint will attach a network interface to the resource and the resource will be part of this VNET. This will ensure no traffic leaves the virtual network and all the communication is private. This also means you need to use VPN or ExpressRoute to connect these resources from on-premises.

When you use private endpoints, traffic is secured to a private-link resource. The platform validates network connections, allowing only those that reach the specified private-link resource. To access additional sub-resources within the same Azure service, additional private endpoints with corresponding targets are required. In the case of Azure Storage, for instance, you would need separate private endpoints to access the file and blob sub-resources.

DNS configuration

The DNS settings that you use to connect to a private-link resource are important. Existing Azure services might already have a DNS configuration you can use when you’re connecting over a public endpoint. To connect to the same service over private endpoint, separate DNS settings, often configured via private DNS zones, are required. Ensure that your DNS settings are correct when you use the fully qualified domain name (FQDN) for the connection. The settings must resolve to the private IP address of the private endpoint.

The network interface associated with the private endpoint contains the information that’s required to configure your DNS. The information includes the FQDN and private IP address for a private-link resource.

For complete, detailed information about recommendations to configure DNS for private endpoints, see Private endpoint DNS configuration.

Pricing and limits

Private endpoint is charged for three things, you can also check this link for detailed information on pricing:

  1. Private endpoint service, which is consistent at around $0.01/hour for most of the regions.
  2. Inbound data processed, will vary based on the ingress data that your private endpoint is receiving.
  3. Outbound data processed, will also vary based on the egress data that your private endpoint is sending.

Benefits and Scenarios:

These are some benefits of using a private endpoint for your resources:

  • It eliminates public exposure and makes your resources more secure.
  • It enables you to create high-security connections from on-premises networks that connect to the virtual network by using a virtual private network (VPN) or Azure ExpressRoute private peering.
  • It helps prevent data exfiltration since all the internet access to the resources is blocked unless explicitly allowed by using routes.


If you only need a secure connection between the virtual network and another resource, you should use a service endpoint, which means your resources will still have public exposure and you will be accessing those resources using the public endpoint of the resource.

However, if you need to access your azure resources from on-premises through an Azure gateway, a regionally peered virtual network, or a globally peered virtual network, use a private endpoint. The private endpoint will allow connection using the private IP of the resources, eliminating the public exposure completely.