Share via

Deploy Azure Databricks in your Azure virtual network (VNet injection)

Deploy Azure Databricks in your Azure VNet to enable network customization, secure connectivity to Azure services and on-premises data sources, and traffic inspection capabilities.

Why use VNet injection

VNet injection deploys Azure Databricks classic compute plane resources in your own VNet, enabling:

  • Private connectivity to Azure services using service endpoints or private endpoints
  • On-premises access through user-defined routes
  • Traffic inspection with network virtual appliances
  • Custom DNS configuration
  • Egress traffic control with additional NSG rules
  • Flexible CIDR ranges (VNet: /16 to /24, subnets: up to /26)

Permissions requirements

Azure permissions: The workspace creator must have the Network contributor role on the VNet, or a custom role with Microsoft.Network/virtualNetworks/subnets/join/action and Microsoft.Network/virtualNetworks/subnets/write permissions.

VNet configuration

  1. You must configure a VNet to deploy the Azure Databricks workspace. You can use an existing VNet or create a new one. The VNet must meet the following requirements:
    • Region: The VNet must reside in the same region as the Azure Databricks workspace.
    • Subscription: The VNet must be in the same subscription as the Azure Databricks workspace.
    • Address space: A CIDR block between /16 and /24 for the VNet. For guidance about maximum cluster nodes based on VNet size, see Address space guidance.
    • Subnets: The VNet must include two subnets dedicated to your Azure Databricks workspace:
      • A container subnet (sometimes called the private subnet)
      • A host subnet (sometimes called the public subnet)
      • Each subnet should use a CIDR block that is at least /26. Databricks doesn't recommend a subnet smaller than /26.
      • You can't share subnets across workspaces or deploy other Azure resources on the subnets used by your Azure Databricks workspace.
      • We recommend the size of the subnets match.
    • Outbound connectivity for egress traffic: Databricks recommends using an Azure NAT gateway to both subnets for stable egress IPs. After March 31, 2026, new VNets require explicit outbound connectivity methods. See secure cluster connectivity.
    • Network security group rules: See Network security group rules

Note

When you deploy a workspace using secure cluster connectivity, both the container subnet and host subnet use private IPs.

Address space guidance

An Azure Databricks workspace requires two subnets in the VNet: a container subnet and a host subnet. Azure reserves five IPs in each subnet. Azure Databricks requires two IP addresses for each cluster node: one IP address for the host in the host subnet and one IP address for the container in the container subnet.

Consider the following when planning your address space:

  • You might want to create multiple workspaces within a single VNet. Because you can't share subnets across workspaces, plan subnets that don't use the total VNet address space.
  • Allocate address space for two new subnets that are within the VNet's address space and don't overlap the address space of current or future subnets in that VNet.

A workspace with a smaller virtual network can run out of IP addresses (network space) more quickly than a workspace with a larger virtual network. Use a CIDR block between /16 and /24 for the VNet and a CIDR block up to /26 for the two subnets (the container subnet and the host subnet). You can create a CIDR block up to /28 for your subnets, however, Azure Databricks does not recommend a subnet smaller than /26.

Step 1: Create a workspace

Create a workspace in the Azure portal and deploy it to your VNet.

  1. In the Azure portal, select + Create a resource > Analytics > Azure Databricks or search for Azure Databricks.

  2. In the Networking tab, select your VNet.

    Important

    If the VNet doesn't appear, verify that the workspace and VNet are in the same Azure region.

  3. Configure subnets with CIDR ranges up to /26 (maximum 80 characters for names):

    • Existing subnets: Enter exact subnet names and matching IP ranges
    • New subnets: Enter new names and IP ranges within your VNet's address space

    Note

    Subnet CIDR ranges cannot be changed after deployment. Azure Databricks automatically configures NSG rules and subnet delegation to Microsoft.Databricks/workspaces.

  4. Click Create to deploy the workspace.

Step 2: Verify workspace deployment

  1. Go to the Azure portal and navigate to your Azure Databricks workspace resource.

  2. On the Overview page, verify the following:

    • The workspace is in a healthy state (not failed).
    • The resource group and managed resource group are listed.
    • Virtual network peering is disabled (this is expected for VNet injection).

The managed resource group isn't modifiable, and can't be used to create virtual machines. Create virtual machines in the resource group you manage.

Step 3: Verify network security group configuration

  1. In the Azure portal, navigate to your VNet.

  2. Click Subnets under Settings.

  3. Verify both the container subnet and host subnet have:

    • A network security group attached
    • Delegation to Microsoft.Databricks/workspaces

  4. Click the network security group and verify that the required inbound and outbound rules are configured. For the expected rules, see Network security group rules reference.

Step 4: Create a cluster

After you create your workspace, create a classic compute cluster to verify that your VNet injection is working properly.

  1. Go to your Azure Databricks workspace and click Launch Workspace on the Overview page.

  2. Click compute icon Compute in the sidebar.

  3. On the Compute page, click Create Cluster.

  4. Enter a cluster name, leave the remaining values in their default state, and click Create Cluster.

Once the cluster runs, the managed resource group contains new virtual machines, disks, IP addresses, and network interfaces. A network interface is created in each of the public and private subnets with IP addresses.

Step 5: Verify cluster network configuration

  1. In your Azure Databricks workspace, go to the managed resource group in the Azure portal.

  2. Verify the following resources exist:

    • Virtual machines for the cluster nodes
    • Disks attached to the virtual machines
    • IP addresses for the cluster nodes
    • Network interfaces in both the public and private subnets

  3. In your Azure Databricks workspace, click the cluster you created.

  4. Navigate to the Spark UI and click the Executors tab.

  5. Verify that the addresses for the driver and the executors are in the private subnet range. For example, if your private subnet is 10.179.0.0/18, the driver might be 10.179.0.6 and executors might be 10.179.0.4 and 10.179.0.5. Your IP addresses might be different.

Stable egress IP addresses

For workspaces with secure cluster connectivity and VNet injection, Databricks recommends configuring a stable egress public IP. Stable IPs enable external allow lists for services like Salesforce and IP access lists.

Warning

After March 31, 2026, new Azure VNets default to private configurations without outbound internet access. New Azure Databricks workspaces require explicit outbound connectivity methods such as a NAT Gateway. Existing workspaces are not affected. See Microsoft's announcement.

To configure a stable egress IP, see Egress with VNet injection.

Network security group rules

Azure Databricks auto-provisions and manages the NSG rules listed below through subnet delegation to the Microsoft.Databricks/workspaces service. These rules are required for workspace operation. Do not modify or delete these rules.

Note

Some rules use VirtualNetwork as both source and destination. Internal network policies prevent cross-cluster communication, including between workspaces in the same VNet.

Databricks recommends using a unique NSG for each workspace.

Important

Add Deny rules to NSGs attached to other networks and subnets in the same or peered VNets. Apply Deny rules for both inbound and outbound connections to limit traffic to and from Azure Databricks compute resources. Allow only the minimum access required for your clusters to reach necessary resources.

Network security group rules for workspaces

This table lists the network security group rules for workspaces and includes two inbound security group rules that are added only if secure cluster connectivity (SCC) is disabled.

Direction Protocol Source Source Port Destination Dest Port Used
Inbound Any VirtualNetwork Any VirtualNetwork Any Default
Inbound TCP AzureDatabricks (service tag)
Only if SCC is disabled		 Any VirtualNetwork 22 Public IP
Inbound TCP AzureDatabricks (service tag)
Only if SCC is disabled		 Any VirtualNetwork 5557 Public IP
Outbound TCP VirtualNetwork Any AzureDatabricks (service tag) 443, 3306, 8443-8451 Default
Outbound TCP VirtualNetwork Any SQL 3306 Default
Outbound TCP VirtualNetwork Any Storage 443 Default
Outbound Any VirtualNetwork Any VirtualNetwork Any Default
Outbound TCP VirtualNetwork Any EventHub 9093 Default

Note

If you restrict outbound rules, Databricks recommends that you open ports 111 and 2049 to enable certain library installs.

Important

Azure Databricks is a Microsoft Azure first-party service that is deployed on the Global Azure Public Cloud infrastructure. All communications between components of the service, including between the public IPs in the control plane and the customer compute plane, remain within the Microsoft Azure network backbone. See also Microsoft global network.

Expand VNet capacity

If your workspace's VNet has insufficient capacity for active cluster nodes, you have two options:

  • Update VNet configuration: This feature is in Public Preview. See Update workspace network configuration.
  • Expand your current CIDR range: Contact your Azure Databricks account team to request an increase to the workspace subnet CIDR range.
  • Last updated on