Service Endpoints and Private Link - What's the difference?

Azure, Networking

For a long time, if you were using the multi-tenant, PaaS version on many Azure services, then you had to access them over the internet with no way to restrict access just to your resources. This restriction was primarily down to the complexity of doing this sort of restrictions with a multi-tenant service. At this time, the only way to get this sort of restriction was to look at using single-tenant solutions like App Service Environment or running service yourself in a VM instead of using PaaS.

This public access was a concern for many, and so Microsoft implemented new services that allow you to limit access to these multi-tenant services. Today we have two solutions that on the face of it look quite similar, Service Endpoints and Private Link. These two services are both design to allow you to restrict who connects to your service, and how they do it. Because of this, it can be confusing to know which service to use and what the benefits are. In this article, we’ll take a look at these services and try and make this decision clearer.

Note that in this article we are purely looking at methods of exposing multi-tenant PaaS services, we are not discussing “Private Link Service”, which allow service providers to expose services to clients through Private Link.

Service Endpoints

Service Endpoints were the first service introduced to allow locking down of multi-tenant services. Service Endpoints allow you to restrict access to your PaaS resources to traffic coming from your Azure Virtual Network. With Service Endpoints, the PaaS service is still separate to your vNet and traffic is leaving your virtual network to access the PaaS service. However, the PaaS service is configured to be able to identify traffic coming from your virtual network and allow that, without the need to configure public IP’s on your vNet to allow filtering.

Service Endpoints

Service Endpoints work by enabling a subnet, or subnets, on your virtual network to support Service Endpoints. Once this is done, you can configure your PaaS resource to only accept traffic from those subnets. There is no requirement to do any IP filtering or NAT translation; you tell the PaaS resource which vNet and Subnet to allow traffic from. When Service Endpoints are enabled, the PaaS resource sees traffic coming from your vNets private IP, not its public IP.

Another advantage of using service endpoints is that traffic is routed to the Azure resources optimally. Even if you have UDRs on your vNet to route internet traffic back on-premises or through a firewall device, using a Service Endpoint means traffic is sent directly to the Azure Resource.

Service Endpoints are supported for the following services:

  • Azure Storage
  • Azure SQL Databases
  • Azure SQL Data Warehouse
  • Azure Database for PostgreSQL
  • Azure Database for MySQL & MariaDB
  • Azure Cosmos DB
  • Azure Key Vault
  • Azure Service Bus
  • Azure Event Hubs
  • Azure Data Lake Store (Gen 1 only)
  • Azure App Service
  • Azure Container Registry

Service Endpoints do have some limitations or downsides. Firstly it is key to remember that traffic to a Service Endpoint is still leaving your virtual network, and the Azure PaaS resource is still being accessed on its public address. Service Endpoints cannot be used by traffic originating on-premises, through VPN or Express Route, only for traffic coming from your Azure Virtual Network. If you want to allow, your on-premises resources access you would need to whitelist their public IPs as well.

More Details: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview

Private Link is a newer solution than Service Endpoints, introduced about a year ago. The key difference between Private Link and Service Endpoints is that with Private Link you are injecting the multi-tenant PaaS resource into your virtual network. With Service Endpoints, traffic still left you vNet and hit the public endpoint of the PaaS resource, with Private Link the PaaS resource sits within your vNet and gets a private IP on your vNet. When you send traffic to the PaaS resource, it does not leave the virtual network.

Private Link

Another key difference with Private Link is that when enabled, you are granting access to a specific PaaS resource in your virtual network. That means you can control egress to PaaS resources. For example, if you wanted to, you could use NSG’s to block access to all Azure SQL databases and then use Private Link to grant access only to your specific Azure SQL Server.

Unlike Service Endpoints, Private Link allows access from resources on your on-premises network through VPN or ExpressRoute, and from peered networks. You can also connect to resources across region.

Private Link supports the following services in GA:

  • Azure Storage
  • Azure Data Lake Storage Gen 2
  • Azure SQL
  • Azure Synapse
  • Azure Cosmos DB
  • Azure Database for PostgreSQL
  • Azure Database for MySQL & MariaDB
  • Azure Key Vault
  • Azure Kubernetes Services

The following services are also supported in preview:

  • Azure Search
  • Azure Container Registry
  • Azure App Configuration
  • Azure Backup
  • Azure Event Hub
  • Azure Service Bus
  • Azure Relay
  • Azure Event Grid
  • Azure Web Apps
  • Azure Machine Learning

As you can see, there are quite a few services that are in GA for Service Endpoints, that are in preview for Private Link.

One drawback with Private Link is that to support resolution of the PaaS resources using the same name you do need to implement DNS to resolve the private link zone for the particular resource. There is integration with Azure Private DNS to set this up for you, but this can be problematic if you have your DNS service already running, or don’t want to use Azure Private DNS with your virtual network.

More Details: https://docs.microsoft.com/en-us/azure/private-link/private-link-overview

Which to Pick?

Now that you’ve had a quick intro to each service, the question comes down to which one should you use? The answer is going to be based on several factors.

Firstly, look at the resource you want to access and see which service it is supported by. Some services will only be supported in one or the other, and so this will choose for you.

Assuming you can use either option for your service, then the decision is probably going to come down to complexity. Service Endpoints are more straightforward and easier to set up than Private Link. You can enable Service Endpoints with a couple of clicks in the portal, and there is no requirement for any additional services. Private Link, however, requires you to implement DNS changes and possibly use Azure Private DNS, it also requires deciding where the service will attach to your Virtual Network. So if you need some additional access restriction for your PaaS Services quickly, or don’t have the rights or knowledge to make changes to DNS, then Service Endpoints are probably the way to go.

Other than complexity, Private Link is superior to Service Endpoints in nearly every other way. If you can set this up, and your service supports it, then I would recommend you use Private Link over Service Endpoints. In particular with Private Link you can:

  • Join your PaaS resource to your vNet and give it a private IP
  • Ensure traffic stays within your virtual network
  • Limit your egress to only your specific PaaS services and prevent data leakage
  • Support access from on-premises and peered networks
  • Connect to resource across regions and even Azure AD tenants

For most people, whose primary concern is around the security and restriction of access to their PaaS resources, Private Link is going to be the better choice. At this point, I would be surprised to see the list of resource that support Service Endpoints increase beyond what is already available, with most PaaS resource looking to release a Private Link offering.