Azure Private Link frequently asked questions (FAQ)

• Azure Private Endpoint: Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. You can use Private Endpoints to connect to an Azure PaaS service that supports Private Link or to your own Private Link Service.
• Azure Private Link Service: Azure Private Link service is a service created by a service provider. Currently, a Private Link service can be attached to the frontend IP configuration of a Standard Load Balancer.

Traffic is sent privately using Microsoft backbone. It doesn’t traverse the internet. Azure Private Link doesn't store customer data.

• Private Endpoints grant network access to specific resources behind a given service providing granular segmentation. Traffic can reach the service resource from on premises without using public endpoints.
• A Service Endpoint remains a publicly routable IP address. A Private Endpoint is a private IP in the address space of the virtual network where the private endpoint is configured.

Multiple private link resource types support access via Private Endpoints. Resources include Azure PaaS services and your own Private Link Service. It's a one-to-many relationship.

A Private Link service receives connections from multiple Private Endpoints. A private endpoint connects to one Private Link Service.

Yes. Private Link Service need to disable network policies to function properly.

Yes. To utilize policies like User-Defined Routes and Network Security Groups, you need to enable Network policies for a subnet in a virtual network for the Private Endpoint. This setting affects all the private endpoints within the subnet.

There are two steps to secure an Azure service resource through service endpoints:

1. Turn on service endpoints for the Azure service.
2. Set up virtual network access control lists (ACLs) on the Azure service.

The first step is a network-side operation, and the second step is a service resource-side operation. The same administrator or different administrators can perform the steps, based on the Azure role-based access control (RBAC) permissions granted to the administrator role.

We recommend that you turn on service endpoints for your virtual network before you set up virtual network ACLs on the Azure service side. To set up virtual network service endpoints, you must perform the steps in the preceding sequence.

Certain services (such as Azure SQL and Azure Cosmos DB) allow exceptions to the preceding sequence through the IgnoreMissingVnetServiceEndpoint flag. After you set the flag to True, you can set up virtual network ACLs on the Azure service side before turning on the service endpoints on the network side. Azure services provide this flag to help customers in cases where the specific IP firewalls are configured on Azure services.

Turning on the service endpoints on the network side can lead to a connectivity drop, because the source IP changes from a public IPv4 address to a private address. Setting up virtual network ACLs on the Azure service side before turning on service endpoints on the network side can help avoid a connectivity drop.

Not all Azure services reside in the customer's virtual network. Most Azure data services (such as Azure Storage, Azure SQL, and Azure Cosmos DB) are multitenant services that can be accessed over public IP addresses. For more information, see Deploy dedicated Azure services into virtual networks.

When you turn on virtual network service endpoints on the network side, and set up appropriate virtual network ACLs on the Azure service side, access to an Azure service is restricted to an allowed virtual network and subnet.

Virtual network service endpoints limit the Azure service's access to the allowed virtual network and subnet. In this way, they provide network-level security and isolation of the Azure service traffic.

All traffic that uses virtual network service endpoints flows over the Microsoft backbone to provide another layer of isolation from the public internet. Customers can also choose to fully remove public internet access to the Azure service resources and allow traffic only from their virtual network through a combination of IP firewall and virtual network ACLs. Removing internet access helps protect the Azure service resources from unauthorized access.

Virtual network service endpoints help protect Azure service resources. Virtual network resources are protected through network security groups.

No. There's no additional cost for using virtual network service endpoints.

Yes, it's possible. Virtual networks and Azure service resources can be in the same subscription or in different subscriptions. The only requirement is that both the virtual network and the Azure service resources must be under the same Microsoft Entra tenant.

Yes, it's possible when you're using service endpoints for Azure Storage and Azure Key Vault. For other services, virtual network service endpoints and virtual network ACLs are not supported across Microsoft Entra tenants.

By default, Azure service resources secured to virtual networks are not reachable from on-premises networks. If you want to allow traffic from on-premises, you must also allow public (typically, NAT) IP addresses from on-premises or ExpressRoute. You can add these IP addresses through the IP firewall configuration for the Azure service resources.

Alternatively, you can implement private endpoints for supported services.

To secure Azure services to multiple subnets within a virtual network or across multiple virtual networks, enable service endpoints on the network side on each of the subnets independently. Then, secure Azure service resources to all of the subnets by setting up appropriate virtual network ACLs on the Azure service side.

If you want to inspect or filter the traffic destined 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 through virtual network ACLs.

This scenario might also be helpful if you want to restrict Azure service access from your virtual network only to specific Azure resources by using network virtual appliance filtering. For more information, see Deploy highly available NVAs.

The service returns an HTTP 403 or HTTP 404 error.

Yes. For most of the Azure services, virtual networks created in different regions can access Azure services in another region through the virtual network service endpoints. For example, if an Azure Cosmos DB account is in the West US or East US region, and virtual networks are in multiple regions, the virtual networks can access Azure Cosmos DB.

Azure SQL is an exception and is regional in nature. Both the virtual network and the Azure service need to be in the same region.

Yes. A virtual network ACL and an IP firewall can coexist. The features complement each other to help ensure isolation and security.

Deletion of virtual networks and deletion of subnets are independent operations. They're supported even when you turn on service endpoints for Azure services.

If you set up virtual network ACLs for Azure services, the ACL information associated with those Azure services is disabled when you delete a virtual network or subnet that has virtual network service endpoints turned on.

The deletion of an Azure service account is an independent operation. It's supported even if you turned on the service endpoint on the network side and set up virtual network ACLs on the Azure service side.

When you turn on virtual network service endpoints, the source IP addresses of the resources in your virtual network's subnet switch from using public IPv4 addresses to using the Azure virtual network's private IP addresses for traffic to Azure services. This switch can cause specific IP firewalls that are set to a public IPv4 address earlier on the Azure services to fail.

Service endpoints add a system route that takes precedence over Border Gateway Protocol (BGP) routes and provides optimum routing for the service endpoint traffic. Service endpoints always take service traffic directly from your virtual network to the service on the Microsoft Azure backbone network.

For more information about how Azure selects a route, see Virtual network traffic routing.

No. ICMP traffic that's sourced from a subnet with service endpoints enabled won't take the service tunnel path to the desired endpoint. Service endpoints handle only TCP traffic. If you want to test latency or connectivity to an endpoint via service endpoints, tools like ping and tracert won't show the true path that the resources within the subnet will take.

To reach the Azure service, NSGs need to allow outbound connectivity. If your NSGs are opened to all internet outbound traffic, the service endpoint traffic should work. You can also limit the outbound traffic to only service IP addresses by using the service tags.

You can configure service endpoints on a virtual network independently if you have write access to that network.

To secure Azure service resources to a virtual network, you must have Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action permission for the subnets that you're adding. This permission is included in the built-in service administrator role by default and can be modified through the creation of custom roles.

For more information about built-in roles and assigning specific permissions to custom roles, see Azure custom roles.

You can use virtual network service endpoint policies to filter virtual network traffic to Azure services, allowing only specific Azure service resources over the service endpoints. Endpoint policies provide granular access control from the virtual network traffic to the Azure services.

To learn more, see Virtual network service endpoint policies for Azure Storage.

Microsoft Entra ID doesn't support service endpoints natively. For a complete list of Azure services that support virtual network service endpoints, see Virtual network service endpoints.

In that list, the Microsoft.AzureActiveDirectory tag listed under services that support service endpoints is used for supporting service endpoints to Azure Data Lake Storage Gen1. Virtual network integration for Data Lake Storage Gen1 makes use of the virtual network service endpoint security between your virtual network and Microsoft Entra ID to generate additional security claims in the access token. These claims are then used to authenticate your virtual network to your Data Lake Storage Gen1 account and allow access.

There is no limit on the total number of service endpoints in a virtual network. For an Azure service resource (such as an Azure Storage account), services might enforce limits on the number of subnets that you use for securing the resource. The following table shows some example limits:

To reach the Azure service, NSGs need to allow outbound connectivity. If your NSGs are opened to all internet outbound traffic, the service endpoint traffic should work. You can also limit the outbound traffic to only service IP addresses by using the service tags.

You can configure service endpoints on a virtual network independently if you have write access to that network.

To secure Azure service resources to a virtual network, you must have Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action permission for the subnets that you're adding. This permission is included in the built-in service administrator role by default and can be modified through the creation of custom roles.

For more information about built-in roles and assigning specific permissions to custom roles, see Azure custom roles.

You can use virtual network service endpoint policies to filter virtual network traffic to Azure services, allowing only specific Azure service resources over the service endpoints. Endpoint policies provide granular access control from the virtual network traffic to the Azure services.

To learn more, see Virtual network service endpoint policies for Azure Storage.

Microsoft Entra ID doesn't support service endpoints natively. For a complete list of Azure services that support virtual network service endpoints, see Virtual network service endpoints.

In that list, the Microsoft.AzureActiveDirectory tag listed under services that support service endpoints is used for supporting service endpoints to Azure Data Lake Storage Gen1. Virtual network integration for Data Lake Storage Gen1 makes use of the virtual network service endpoint security between your virtual network and Microsoft Entra ID to generate additional security claims in the access token. These claims are then used to authenticate your virtual network to your Data Lake Storage Gen1 account and allow access.

There is no limit on the total number of service endpoints in a virtual network. For an Azure service resource (such as an Azure Storage account), services might enforce limits on the number of subnets that you use for securing the resource. The following table shows some example limits:

Yes. You can have multiple Private Endpoints in same virtual network or subnet. They can connect to different services.

No, creating multiple zones with the same name for a single virtual network isn't supported.

No. You don't require a dedicated subnet for Private Endpoints. You can choose a Private Endpoint IP from any subnet from the virtual network where your service is deployed.

Yes. Private endpoints can connect to Private Link services or to an Azure PaaS across Microsoft Entra tenants. Private Endpoints across tenants require a manual request approval.

Yes. Private Endpoints can connect to Azure PaaS resources across Azure regions.

When a private endpoint is created, a read-only NIC is assigned. The NIC can't be modified and will remain for the life cycle of the Private endpoint.

Private Endpoints are highly available resources with an SLA as per SLA for Azure Private Link. However, since they're regional resources, any Azure region outage can affect the availability. To achieve availability if there are regional failures, multiple PEs connected to same destination resource could be deployed in different regions. This way if one region goes down, you can still route the traffic for your recovery scenarios through PE in different region to access the destination resource. For info on how the regional failures are handled on destination service side, review the service documentation on failover and recovery. Private Link traffic follows the Azure DNS resolution for the destination endpoint.

Private Endpoints are highly available resources with an SLA as per SLA for Azure Private Link. Private Endpoints are zone-agnostic: an availability zone failure in the region of the Private Endpoint won't affect the availability of the Private Endpoint.

TCP and UDP traffic are only supported for a private endpoint. For more information, see Private Link limitations.

Your service backends should be in a Virtual Network and behind a Standard Load Balancer.

You can scale your Private Link Service in a few different ways:

• Add Backend VMs to the pool behind your Standard Load Balancer
• Add an IP to the Private Link Service. We allow up to 8 IPs per Private Link Service.
• Add new Private Link Service to Standard Load Balancer. We allow up to eight Private Link Services per Standard Load Balancer.

• The NAT IP configuration ensures the source (consumer) and destination (service provider) address space don't have IP conflicts. The configuration provides source NAT for the private link traffic for the destination. The NAT IP address shows up as source IP for all packets received by your service and destination IP for all packets sent by your service. NAT IP can be chosen from any subnet in a service provider's Virtual Network.
• Each NAT IP provides 64k TCP connections (64k ports) per VM behind the Standard Load Balancer. In order to scale and add more connections, you can either add new NAT IPs or add more VMs behind the Standard Load Balancer. Doing so scales the port availability and allow for more connections. Connections are distributed across NAT IPs and VMs behind the Standard Load Balancer.

Yes. One Private Link Service can receive connections from multiple Private Endpoints. However one Private Endpoint can only connect to one Private Link Service.

You can control the exposure using the visibility configuration on Private Link service. Visibility supports three settings:

• None - Only subscriptions with role based access can locate the service.
• Restrictive - Only subscriptions that are approved and with role based access can locate the service.
• All - Everyone can locate the service.

No. Private Link Service over a Basic Load Balancer isn't supported.

No. A dedicated subnet isn't required for the Private Link Service. You can choose any subnet in your virtual network where your service is deployed.

No. Azure Private Link provides this functionality for you. You aren't required to have nonoverlapping address space with your customer's address space.

Next steps

• Learn about Azure Private Link