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 that 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/Endpoints. These two services are both designed 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 will look at these services and try to make your decision clearer.
Overview of 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 IPs on your VNet to allow filtering.
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 (Microsoft.Storage😞 Generally available in all Azure regions.
- Azure Storage cross-region service endpoints (Microsoft.Storage.Global😞 Generally available in all Azure regions.
- Azure SQL Database (Microsoft.Sql😞 Generally available in all Azure regions.
- Azure Synapse Analytics (Microsoft.Sql😞 Generally available in all Azure regions for dedicated SQL pools (formerly SQL DW).
- Azure Database for PostgreSQL server (Microsoft.Sql😞 Generally available in Azure regions where database service is available.
- Azure Database for MySQL server (Microsoft.Sql😞 Generally available in Azure regions where database service is available.
- Azure Database for MariaDB (Microsoft.Sql😞 Generally available in Azure regions where database service is available.
- Azure Cosmos DB (Microsoft.AzureCosmosDB😞 Generally available in all Azure regions.
- Azure Key Vault (Microsoft.KeyVault😞 Generally available in all Azure regions.
- Azure Service Bus (Microsoft.ServiceBus😞 Generally available in all Azure regions.
- Azure Event Hubs (Microsoft.EventHub😞 Generally available in all Azure regions.
- Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory😞 Generally available in all Azure regions where ADLS Gen1 is available.
- Azure App Service (Microsoft.Web😞 Generally available in all Azure regions where App service is available.
- Azure Cognitive Services (Microsoft.CognitiveServices😞 Generally available in all Azure regions where Azure AI services are available.
- Azure Container Registry (Microsoft.ContainerRegistry): Public Preview available in limited Azure regions where Azure Container Registry is available.
Limitations of Service Endpoints
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, then you would need to whitelist their public IPs as well.
Overview of Private Link
Private Link is a newer solution than Service Endpoints, introduced few years ago. Thus far, we have referred to Azure’s Private Link as a service, so the idea of introducing a new concept Private Link Service may be a little confusing. Believe me, you’re not alone! 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.
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. The Private Link Service pairs your internal service or application with a Standard Load Balancer that allows access from parties outside your network. Access is restricted via RBAC (within the same tenant), subscription, or alias. The customer can then create a private endpoint and request access to the Private Link Service via an approval process. In this way, businesses can utilize completely private network components without the trouble or security considerations of maintaining VPN connectivity or peering to the consumers of their application.
DNS configuration for Private link
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 detailed information about recommendations to configure DNS for private endpoints, see Private endpoint DNS configuration.
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:
- 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 and many other services
- Azure Virtual desktop (in public preview)
You can check Private link availability of all the services on this page - https://learn.microsoft.com/en-us/azure/private-link/availability
Limitations of 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.
Benefits of Private Link
The primary benefit of the Azure Private Link is that it eliminates a huge hurdle for some organizations that are bound by compliance or governance requirements that traffic is privately secured throughout the organization. Now those organizations can connect to private endpoints via site-to-site VPN or ExpressRoute, fulfilling security requirements for available PaaS Services without having to traverse the public Internet.
Private Link also benefits from private DNS and IP addressing. This allows you to manage and maintain your private IP spaces and internal DNS systems without requiring public IP or DNS updates which are often are handled by external parties. This scenario also alleviates complex routing rules that would have internal apps sending PaaS services requests out to the Internet. Now those calls can be sent internally.
Each private endpoint is linked to the specific instance of the PaaS resource it represents to prevent data leakage. This means that each private endpoint only facilitates access to the SQL Server, storage account, or web app to which it is linked. In this manner, data leakage is greatly reduced as applications and resources must reference the specific service and instance combination, rather than the entire service.
Extending internal resources to other departments or customers is another key benefit of Private link. Using Private Link in parallel with Azure Standard Load Balancer enables you to make internal PaaS or IaaS services available via Private Endpoint to business units or external customers without allowing traffic to or from the Internet.
Pricing and limits
Private endpoint is charged for three things, you can also check this link for detailed information on pricing:
- Private endpoint service, which is consistent at around $0.01/hour for most of the regions.
- Inbound data processed, will vary based on the ingress data that your private endpoint is receiving.
- Outbound data processed, will also vary based on the egress data that your private endpoint is sending.
Logging and Monitoring using Private Link
As with many Azure resources, logging and monitoring strategies are an important consideration in Azure Private Link as well. However, in this case, we are not talking about monitoring the private endpoints as resources but rather, how we can use Private Link to facilitate monitoring within an existing Azure environment.
The Azure Monitor Private Link Scope (AMPLS) was designed to enable access to Azure monitor privately. This solution uses the Private Link Service to enable Azure monitoring for a specific scope of backend resources. The monitoring solution can send logging and diagnostic information directly to a private endpoint scoped to the designated Log Analytics Workspace (and other components) rather than the general Azure Monitor public endpoint, eliminating the need for many resources to have access to the public Internet. This has the added benefit of ensuring that logs for your application are only accessible via a private endpoint.
When designing the AMPLS, consider where it should live and what resources should be accessible via the private link scope. If you’re using a shared services model with a central hub network, consider placing the AMPLS in the hub network and scoping coverage to all monitoring infrastructure covered by the hub and spoke networks.
Comparison table between Service Endpoints/Private Endpoints
|
|
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 OnPrem integrations. Build mainly for Azure VNETs. |
Yes, ExpressRoute and VPN tunnels provide support to extend the private Azure PaaS connectivity to the OnPrem 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 |
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.
Conclusion
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.
Microsoft
