Databricks should run in a customer-managed virtual network

By default Azure Databricks places the compute for a workspace in a network that Databricks manages. You cannot see or shape the traffic rules in that network. When the workspace is deployed into your own virtual network (often called VNet injection), the cluster machines receive addresses from subnets you chose. That lets you apply your own network security groups, route traffic through a firewall, reach on-premises systems over private links and keep data sources off the public internet.

Microsoft documents the feature and its requirements in Deploy Azure Databricks in your Azure virtual network. Without it, you have fewer places to enforce network policy, and an analytics workspace that handles sensitive data sits outside the controls you apply to the rest of your estate.

In the Azure portal, open Azure Databricks, select the workspace, then go to Overview and look at the Virtual network field, or open Networking in the left menu. A workspace in your own network shows the VNet name and two subnets (a public host subnet and a private container subnet). A workspace that is not injected shows no virtual network of your own.

You can read the same value from the command line. This only reads configuration:

az databricks workspace show --resource-group <resource-group> --name <workspace-name> \
  --query "{vnet:parameters.customVirtualNetworkId.value, publicSubnet:parameters.customPublicSubnetName.value, privateSubnet:parameters.customPrivateSubnetName.value}" -o json

If the vnet value is empty or null, the workspace uses the managed network. To list every workspace in a subscription, run az databricks workspace list --query "[].{name:name, vnet:parameters.customVirtualNetworkId.value}" -o table.

Plan this carefully: the network is chosen when a workspace is created, and Microsoft Learn describes which existing workspaces can be moved and how, so read the page above before you start. In most cases the path is to build a new workspace in your network and migrate notebooks, jobs and data access to it.

Portal steps:

• Create or choose a virtual network with two empty subnets, delegated to Microsoft.Databricks/workspaces, each with a network security group attached.
• Go to Create a resource, then Azure Databricks. On the Networking tab choose Deploy Azure Databricks workspace in your own Virtual Network (VNet) and pick the VNet and both subnets.
• Review and create, then move your workloads across.

Script (this runs in your own session and changes your Azure; ConfigCobra never does):

az databricks workspace create --resource-group <resource-group> --name <new-workspace> \
  --location <region> --sku premium \
  --vnet <vnet-resource-id> --public-subnet <host-subnet-name> --private-subnet <container-subnet-name>

Data engineers and analysts keep using the same Databricks interface, but they work in a new workspace if the old one had to be replaced, so notebooks, jobs, cluster policies, secrets and access permissions need to be recreated or exported and imported. Scheduled jobs and any external tool that points at the old workspace address must be updated.

The network team gains ownership of the subnets: address space has to be large enough for the clusters you run, and outbound rules must still allow the Databricks control plane and your data sources. Rules that are too strict can stop clusters from starting, so test with one non-production workspace first. ConfigCobra's remediation impact view lists the affected resources before you change anything.