Private endpoints for Azure Data Explorer

You can use private endpoints for your cluster to allow clients on a virtual network (VNet) to securely access data over a private link. Private endpoints use private IP addresses from your VNet address space to connect you privately to your cluster. Network traffic between clients on the VNet and the cluster, traverses over the VNet and a private link on the Microsoft backbone network, eliminating exposure from the public internet.

Using private endpoints for your cluster enables you to:

  • Secure your cluster by configuring the firewall to block all connections on the public endpoint to the cluster.
  • Increase security for the VNet by enabling you to block exfiltration of data from the VNet.
  • Securely connect to clusters from on-premises networks that connect to the VNet using a VPN gateway or ExpressRoutes with private-peering.


A private endpoint is a special network interface for an Azure service in your VNet that is assigned IP addresses from the IP address range of your VNet. When you create a private endpoint for your cluster, it provides secure connectivity between clients on your VNet and your cluster. The connection between the private endpoint and the cluster uses a secure private link.

Diagram showing the schema of the private endpoint architecture.

Applications in the VNet can seamlessly connect to the cluster over the private endpoint. The connection strings and authorization mechanisms are the same as you'd use to connect to a public endpoint.

When you create a private endpoint for cluster in your VNet, a consent request is sent for approval to the cluster owner. If the user requesting the creation of the private endpoint is also an owner of the cluster, the request is automatically approved. Cluster owners can manage consent requests and private endpoints for the cluster in the Azure portal, under Private endpoints.

You can secure your cluster to only accept connections from your VNet by configuring the cluster firewall to deny access through its public endpoint by default. You don't need a firewall rule to allow traffic from a VNet that has a private endpoint because the cluster firewall only controls access for the public endpoint. In contrast, private endpoints rely on the consent flow for granting subnets access to the cluster.

Plan the size of subnet in your VNet

The size of the subnet used to host a private endpoint for a cluster can't be altered once the subnet is deployed. The private endpoint consumes multiple IP addresses in your virtual network. In extreme scenarios, such as high-end ingestion, the number of IP addresses consumed by the private endpoint may increase. This increase is caused by transient storage accounts required as staging accounts for ingesting into your cluster. If the scenario is relevant in your environment, you must plan for it when determining the size for the subnet.

Use the following information to help you determine the total number of IP addresses required by your private endpoint:

Use Number of IP addresses
Engine service 1
Data management service 1
Transient storage accounts 6
Azure reserved addresses 5
Total 13


The absolute minimum size for the subnet must be /28 (14 usable IP addresses). If you plan to create an Azure Data Explorer cluster for extreme ingestion workloads you are on the safe side with a /24 netmask.

If you created a subnet that is too small, you can delete it and create a new one with a larger address range. Once you've recreated the subnet, you can create a new private endpoint for the cluster.

Connect to a private endpoint

Clients on a VNet using a private endpoint should use the same connection string for the cluster as clients connecting to a public endpoint. DNS resolution automatically routes connections from the VNet to the cluster over a private link.


Use the same connection string to connect to the cluster using private endpoints as you'd use to connect to a public endpoint. Don't connect to the cluster using its private link subdomain URL.

By default, Azure Data Explorer creates a private DNS zone attached to the VNet with the necessary updates for the private endpoints. However, if you're using your own DNS server, you may need to make more changes to your DNS configuration.

Screenshot of the DNS configuration page, showing the DNS configuration of the private endpoint.

Azure Data Explorer creates multiple customer visible FQDNs as part of the private endpoint deployment. In addition to the query and ingestion FQDN it comes with several FQDNs for blob / table / queue endpoints (needed for ingestion scenarios)

Disable public access

To increase security, you also can disable public access to the cluster in the Azure portal.

Screenshot of the networking page, showing the disable public access option.

Managed private endpoints

You can use a managed private endpoint to either enable the cluster to securely access your ingestion- or query-related services via their private endpoint. This allows the Azure Data Explorer cluster to access your resources via a private IP address.

Diagram showing the schema of the managed private endpoint architecture.

Supported services

Azure Data Explorer supports creating managed private endpoints to the following services:


Private endpoints aren't supported for virtual network injected Azure Data Explorer clusters.

Next steps