Deploy Azure Data Explorer cluster into your Virtual Network
This article explains the resources that are present when you deploy an Azure Data Explorer cluster into a custom Azure Virtual Network. This information will help you deploy a cluster into a subnet in your Virtual Network (VNet). For more information on Azure Virtual Networks, see What is Azure Virtual Network?
Azure Data Explorer supports deploying a cluster into a subnet in your Virtual Network (VNet). This capability enables you to:
- Enforce Network Security Group (NSG) rules on your Azure Data Explorer cluster traffic.
- Connect your on-premises network to Azure Data Explorer cluster's subnet.
- Secure your data connection sources (Event Hub and Event Grid) with service endpoints.
Access your Azure Data Explorer cluster in your VNet
You can access your Azure Data Explorer cluster using the following IP addresses for each service (engine and data management services):
- Private IP: Used for accessing the cluster inside the VNet.
- Public IP: Used for accessing the cluster from outside the VNet for management and monitoring, and as a source address for outbound connections started from the cluster.
The following DNS records are created to access the service:
ingest-[clustername].[geo-region].kusto.windows.net(data management) are mapped to the public IP for each service.
private-ingest-[clustername].[geo-region].kusto.windows.net(data management) are mapped to the private IP for each service.
Plan subnet size in your VNet
The size of the subnet used to host an Azure Data Explorer cluster can't be altered after the subnet is deployed. In your VNet, Azure Data Explorer uses one private IP address for each VM and two private IP addresses for the internal load balancers (engine and data management). Azure networking also uses five IP addresses for each subnet. Azure Data Explorer provisions two VMs for the data management service. Engine service VMs are provisioned per user configuration scale capacity.
The total number of IP addresses:
|Use||Number of addresses|
|Engine service||1 per instance|
|Data management service||2|
|Internal load balancers||2|
|Azure reserved addresses||5|
|Total||#engine_instances + 9|
Subnet size must be planned in advance since it can't be changed after Azure Data Explorer is deployed. Therefore, reserve needed subnet size accordingly.
Service endpoints for connecting to Azure Data Explorer
Azure Service Endpoints enables you to secure your Azure multi-tenant resources to your virtual network. Deploying Azure Data Explorer cluster into your subnet allows you to setup data connections with Event Hub or Event Grid while restricting the underlying resources for Azure Data Explorer subnet.
When using EventGrid setup with Storage and Event Hub, the storage account used in the subscription can be locked with service endpoints to Azure Data Explorer's subnet while allowing trusted Azure platform services in the firewall configuration, but the Event Hub can't enable Service Endpoint since it doesn't support trusted Azure platform services.
Private Endpoints allow private access to Azure resources (such as Storage/Event Hub/Data Lake Gen 2), and use private IP from your Virtual Network, effectively bringing the resource into your VNet. Create a Private Endpoint to resources used by data connections, such as Event Hub and Storage, and external tables such as Storage, Data Lake Gen 2, and SQL Database from your VNet to access the underlying resources privately.
Dependencies for VNet deployment
Network Security Groups configuration
Network Security Groups (NSG) provide the ability to control network access within a VNet. Azure Data Explorer automatically applies the following required network security rules. For Azure Data Explorer to operate using the subnet delegation mechanism, before creating the cluster in the subnet, you must delegate the subnet to Microsoft.Kusto/clusters .
Inbound NSG configuration
|Management||ADX management addresses/AzureDataExplorerManagement(ServiceTag)||ADX subnet:443||TCP|
|Health monitoring||ADX health monitoring addresses||ADX subnet:443||TCP|
|ADX internal communication||ADX subnet: All ports||ADX subnet:All ports||All|
|Allow Azure load balancer inbound (health probe)||AzureLoadBalancer||ADX subnet:80,443||TCP|
Outbound NSG configuration
|Dependency on Azure Storage||ADX subnet||Storage:443||TCP|
|Dependency on Azure Data Lake||ADX subnet||AzureDataLake:443||TCP|
|EventHub ingestion and service monitoring||ADX subnet||EventHub:443,5671||TCP|
|Publish Metrics||ADX subnet||AzureMonitor:443||TCP|
|Active Directory (if applicable)||ADX subnet||AzureActiveDirectory:443||TCP|
|Certificate authority||ADX subnet||Internet:80||TCP|
|Internal communication||ADX subnet||ADX Subnet:All Ports||All|
|Ports that are used for
Relevant IP addresses
Azure Data Explorer management IP addresses
For future deployments, use AzureDataExplorer Service Tag
|Central India||18.104.22.168, 22.214.171.124|
|Central US EUAP||126.96.36.199|
|China East 2||188.8.131.52|
|China North 2||184.108.40.206|
|East US2 EUAP||220.127.116.11|
|North Central US||18.104.22.168|
|South Africa North||22.214.171.124|
|South Africa West||126.96.36.199|
|South Central US||188.8.131.52|
|South India||184.108.40.206, 220.127.116.11|
|West Central US||18.104.22.168|
|West India||22.214.171.124, 126.96.36.199|
Health monitoring addresses
|Australia Central 2||188.8.131.52|
|Canada East||184.108.40.206, 220.127.116.11|
|Central US||18.104.22.168, 22.214.171.124|
|Central US EUAP||126.96.36.199, 188.8.131.52|
|China East 2||184.108.40.206|
|China North 2||220.127.116.11|
|East US||18.104.22.168, 22.214.171.124|
|East US 2||126.96.36.199, 188.8.131.52|
|East US 2 EUAP||184.108.40.206, 220.127.116.11|
|North Central US||18.104.22.168|
|North Europe||22.214.171.124, 126.96.36.199|
|South Africa North||188.8.131.52|
|South Africa West||184.108.40.206|
|South Central US||220.127.116.11, 18.104.22.168|
|West Central US||22.214.171.124, 126.96.36.199|
|West Europe||188.8.131.52, 184.108.40.206|
|West US||220.127.116.11, 18.104.22.168, 22.214.171.124|
|West US 2||126.96.36.199, 188.8.131.52, 184.108.40.206|
Disable access to Azure Data Explorer from the public IP
If you want to completely disable access to Azure Data Explorer via the public IP address, create another inbound rule in the NSG. This rule has to have a lower priority (a higher number).
|Use||Source||Source service tag||Source port ranges||Destination||Destination port ranges||Protocol||Action||Priority|
|Disable access from the internet||Service Tag||Internet||*||VirtualNetwork||*||Any||Deny||higher number than the rules above|
This rule will allow you to connect to the Azure Data Explorer cluster only via the following DNS records (mapped to the private IP for each service):
Use ExpressRoute to connect on premises network to the Azure Virtual Network. A common setup is to advertise the default route (0.0.0.0/0) through the Border Gateway Protocol (BGP) session. This forces traffic coming out of the Virtual Network to be forwarded to the customer's premise network that may drop the traffic, causing outbound flows to break. To overcome this default, User Defined Route (UDR) (0.0.0.0/0) can be configured and next hop will be Internet. Since the UDR takes precedence over BGP, the traffic will be destined to the Internet.
Securing outbound traffic with firewall
If you want to secure outbound traffic using Azure Firewall or any virtual appliance to limit domain names, the following Fully Qualified Domain Names (FQDN) must be allowed in the firewall.
prod.warmpath.msftcloudes.com:443 gcs.prod.monitoring.core.windows.net:443 production.diagnostics.monitoring.core.windows.net:443 graph.windows.net:443 *.update.microsoft.com:443 login.live.com:443 wdcp.microsoft.com:443 login.microsoftonline.com:443 azureprofilerfrontdoor.cloudapp.net:443 *.core.windows.net:443 *.servicebus.windows.net:443,5671 shoebox2.metrics.nsatc.net:443 prod-dsts.dsts.core.windows.net:443 ocsp.msocsp.com:80 *.windowsupdate.com:80 ocsp.digicert.com:80 go.microsoft.com:80 dmd.metaservices.microsoft.com:80 www.msftconnecttest.com:80 crl.microsoft.com:80 www.microsoft.com:80 adl.windows.com:80 crl3.digicert.com:80
If you're using Azure Firewall, add Network Rule with the following properties:
Source Type: IP Address
Service Tags: AzureMonitor
Destination Ports: 443
For example, for West US region, the following UDRs must be defined:
|Name||Address Prefix||Next Hop|
Deploy Azure Data Explorer cluster into your VNet using an Azure Resource Manager template
To deploy Azure Data Explorer cluster into your virtual network, use the Deploy Azure Data Explorer cluster into your VNet Azure Resource Manager template.
This template creates the cluster, virtual network, subnet, network security group, and public IP addresses.