Azure · · 5 min read

Service Endpoints vs. Private Links

When I started to dive into the Azure world I found the difference between Service Endpoints and Private Links confusing. In this post I'd like to clear things up a bit and give a quick overview

Service Endpoints vs. Private Links


When I started to dive into the Azure world, I found the difference between Service Endpoints and Private Link confusing.

That's why I wrote this short article, where I'd like to clear things up, and give a quick overview of the core features.


I gave a presentation on this topic at the Azure Zurich User Group. You can find the slides with more details on A recording is also available.

Service Endpoint

A service endpoint provides direct connectivity to an Azure service by using the Azure backbone. They enable private IP addresses in a VNet to reach an endpoint of an Azure service without the need of a public IP address on a VNet. So in general service endpoints have to be enabled on a subnet for a specific Azure service.

Let's have a look at the following diagram provided by Microsoft.


As you can see we have a VM on the left side that uses it's private IP address ( to connect to an Azure storage account. There is no need for the VM to have a public IP address anymore to connect to the storage account.

This works by applying several additional system routes with a next hop type of VirtualNetworkServiceEndpoint. We don't have to worry about this, because ARM takes care of adding this routes when enabling a service endpoint. attached to


If we would run a packet capture on the backbone we would see a packet flow like src: -> dst: So the destination remains a public IP. But still this provides us some benefits which are:


Now private links are a bit more complex. Basically a private link is made up of three components which are Private Endpoint, Private Link Service and Private Endpoint DNS Integration.

Again let's first have a look at the diagram which Microsoft's documentation provides.


On the left side of the image (Service Consumer side) we can see several VMs. Some of them residing in spoke networks and one being in the hub network.

Private Endpoint

Now what's special about private endpoints is that they act as virtual network interfaces being plugged into subnets having a private IP address ( in this case).

This provides a subtle difference when compared to service endpoints in that a packet flow coming from a VM to that private endpoint would look like src: -> dst: as opposed to a service endpoint packet flow src: -> dst: Note the destination IP being a public one.

Private Endpoint DNS Integration

Now you don't want to mess around with IPs, you'd like to use DNS names. This is where the Private Endpoint DNS Integration component comes into play. It allows the registration of the private IP within a private DNS zone which is optional, but recommended.

So when configuring a private endpoint for a storage account (file share) the private DNS zone will be named or for a SQL database private endpoint.

Okay, now what does the resolving process look like?


In the diagram above a VM likes to access a SQL database hosted on (which is it's public resolvable host A record). So the client queries the Azure provided DNS server and asks for the IP of, which results in a reply pointing to and the private IP address.

Let's now focus on the right side of the diagram and the Private Link Service component. First off please note that the creation of a Private Link Service is only required if you'd like to provide your own service via Private Link.


As we can see from the diagram the provider network contains a Standard Load Balancer which acts on Layer 4. This needs to be created first. Later we would attach the private link service to the frontend IP configuration of the load balancer.

Whats special about the private link service, is that it offers a way to approve or reject a consumers initial connection requests to the provided service. This mechanism makes sense when we keep in mind that a private link service allows us to provide services to semi-trusted customers from foreign tenants.


As we saw from this quick run-through both service endpoints and private links offer a somewhat similar feature set. However there are a couple of main differences which are:


Service Endpoints are free of charge, whereas the usage of private endpoints is charged hourly and also by the amount of inbound and outbound data processed. Although the creation of a private link service is free charges apply for the required load balancer and VMs hosting the application.


When using Service Endpoints the providing Azure service still uses a public IP address which requires care when it comes to firewalling. The usage of the private link offering entirely eliminates the need for public exposure.


As both services transfer the user data over the Azure backbone the latency and bandwidth limits should both be alike.

Service accessibility

I think this is the most important difference between both. With service endpoints we are only able to access a handful of Azure services privately, but I'd say the most important ones are covered. Currently this are:

For the private link service we are not bound to the list above. Anything service a load balancer can talk to can be provided. But still a couple of limitations apply. These are:

So that's it for today. Thanks for making it through! 😎

Read next