Service Endpoints vs. Private Links

Matthias Güntert -

Introduction

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.

Update

I gave a presentation on this topic at the Azure Zurich User Group. You can find the slides with more details on speakerdeck.com. 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 (10.1.1.4) 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:10.1.1.4 -> dst:13.69.40.17. So the destination remains a public IP. But still this provides us some benefits which are:

Benefits

  • Traffic from a service consumer to an Azure service provider does not cross the internet anymore and resides on the Azure backbone
  • We can lock down the subnet the VM resides in
  • We can lock down public access to the provided Azure resource (storage account in this case)
  • We can benefit from a very low network latency
  • We can save money as no additional public IPs are required
  • The use of service endpoints is free!

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 (10.1.1.5 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:10.1.1.4 -> dst:10.1.1.5 as opposed to a service endpoint packet flow src:10.1.1.4 -> dst:13.69.40.17. 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 privatelink.file.core.windows.net or privatelink.database.windows.net 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 azsql1.database.windows.net (which is it's public resolvable host A record). So the client queries the Azure provided DNS server and asks for the IP of azsql1.database.windows.net, which results in a reply pointing to azsql1.privatelink.database.windows.net 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.

Conclusion

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:

Pricing

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.

Security

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.

Performance

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:

  • Azure Storage
  • Azure SQL Database / PostgreSQL / MySQL / MariaDB / Cosmos DB
  • Azure Key Vault
  • Azure Service Bus
  • Azure Event Hubs
  • Azure App Service
  • ... and more

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:

  • Only IPv4 and TCP traffic is supported
  • Supported only on Standard Load Balancer

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