Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Use private endpoints for your cluster to let clients on a virtual network securely access data over a private link. Private endpoints use private IP addresses from your virtual network address space to connect to your cluster securely. Network traffic between clients on the virtual network and the cluster traverses the virtual network and a private link on the Microsoft backbone network, avoiding exposure to the public internet.
Private endpoints for your cluster let you:
- Secure the cluster by setting the firewall to block all connections on the public endpoint.
- Increase virtual network security by blocking data exfiltration.
- Securely connect to clusters from on-premises networks through a VPN gateway or ExpressRoutes with private peering.
Overview
A private endpoint is a special network interface for an Azure service in your virtual network. It's assigned IP addresses from the IP address range of your virtual network. Creating a private endpoint for your cluster provides secure connectivity between clients on your virtual network and your cluster. The private endpoint and the cluster connect using a secure private link.
Applications in the virtual network connect to the cluster over the private endpoint. The connection strings and authorization mechanisms are the same as those used to connect to a public endpoint.
Creating a private endpoint for a cluster in your virtual network sends a consent request to the cluster owner for approval. 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.
Secure your cluster to accept connections only from your virtual network 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 virtual network 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 the subnet in your virtual network
The size of the subnet that hosts a private endpoint for a cluster can't be changed after the subnet is deployed. The private endpoint consumes multiple IP addresses in your virtual network. In extreme scenarios, like high-end ingestion, the number of IP addresses used by the private endpoint can increase. The cause of this increase is due an increased number of transient storage accounts required as staging accounts for ingesting into your cluster. If this scenario applies to your environment, plan for it when determining the subnet size.
Note
The relevant ingestion scenarios that would be responsible for scaling out the transient storage accounts are ingestion from a local file and async ingestion from a blob.
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 |
Note
The absolute minimum size for the subnet is /28 (14 usable IP addresses). If you plan to create an Azure Data Explorer cluster for extreme ingestion workloads, use a /24 netmask to stay on the safe side.
If you created a subnet that is too small, you can delete it and create a new one with a larger address range. After recreating the subnet, create a new private endpoint for the cluster.
Connect to a private endpoint
Clients on a virtual network 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 virtual network to the cluster over a private link.
Important
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 virtual network with the necessary updates for the private endpoints. However, if you're using your own DNS server, you might need to make more changes to your DNS configuration.
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.
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. The Azure Data Explorer cluster can then access your resources via a private IP address.
Note
We recommend using Managed Identity connect to Azure Storage and Azure Event Hubs instead of managed private endpoints. To connect using managed identities, configure the Azure Storage or Event Hubs resources to recognize Azure Data Explorer as a trusted service. Then, use Managed Identity to grant access by creating a network rule exception for trusted Azure services.```
Supported services
Azure Data Explorer supports creating managed private endpoints to the following services:
Limitations
Private endpoints aren't supported for virtual network injected Azure Data Explorer clusters.
Implications on cost
Private endpoints or managed private endpoints are resources that incur extra costs. The cost varies depending on the selected solution architecture. For more information, see Azure Private Link pricing.