Databricks workspace inside VNet still accessible externally – possible VNet misconfiguration?

Question

Hi all,

We’re testing Azure Databricks under a VNet setup and noticed something odd — despite the workspace being deployed inside a VNet (VNet injection enabled), we’re still able to mirror Fabric data from Databricks Catalog without any network restriction issues. My understanding is that this shouldn’t work unless proper Fabric network access is configured.

Here’s what we did step by step:

1. Created a custom VNet and subnets for Databricks workspace (private and public).
2. Enabled VNet injection while creating the Databricks workspace.
3. Added NSG rules to allow only necessary outbound ports (e.g., 443) and limited inbound access. Also tried to block all outbound access, still able to mirror catalog.
4. Verified that the workspace has private endpoint access for storage and other services.
5. Expected Fabric Mirroring to fail if Databricks was truly isolated in the VNet — but mirroring still works perfectly.

This makes me think either:

• The VNet is not fully enforced (e.g., workspace might still use managed public endpoints), or
• Fabric Mirroring connects through an internal Microsoft backbone that bypasses VNet boundaries.

Question: What might be wrong or missing in the VNet setup that allows Fabric to still access Databricks catalog successfully? How can I confirm if my Databricks workspace is truly operating within the VNet and not using public endpoints?

Thanks,

Bharath Kumar S

Answer 1

Hi BharathKumarS-1759,

Welcome to Microsoft Q&A and thank you for posting your query here!

It's a great observation and an important security consideration to verify that your Azure Databricks workspace with VNet injection is truly isolated as expected. Here are some important points and checks for your scenario:

Why Fabric Mirroring Works Despite VNet Injection:

1. Databricks Managed Public Endpoints Even with VNet injection enabled, by default the Databricks control plane and some services may still use managed public endpoints for certain traffic paths. This means some access bypasses your VNet, especially for control and metadata plane operations, including Fabric data mirroring. Azure Databricks documentation confirms: Azure Databricks workspaces can’t be fully private by default; some public communication is necessary unless specific private endpoints are configured. (See Configure private connectivity to Azure Databricks)
2. Internal Microsoft Backbone for Fabric: Microsoft Fabric’s integration with Databricks often leverages internal Microsoft network backbones that allow secure, high-performance access between services behind the scenes, which are independent of your VNet boundaries. This means Fabric can reach the Databricks Catalog via internal routes even if network restrictions on your VNet seem configured correctly.

How to Confirm Full VNet Isolation:

• **Check for Private Endpoints:**Make sure your workspace uses Private Endpoints (private link) not only for storage but also for the control plane and user-facing APIs. Without private front-end connectivity configured, public endpoints might still be accessible. Learn about Private Link here: Configure Azure Databricks private connectivity
• Verify NSG Rules and UDRs: Confirm Network Security Groups (NSGs) and User Defined Routes (UDRs) are fully blocking all unapproved outbound/inbound traffic, especially to public IP ranges used by Databricks services.
• Control Plane and Cluster Plane Differences: Remember, VNet injection isolates the "classic compute plane" but does not automatically block control plane communications which may still use public traffic paths or Microsoft backbone networks.

Further Steps & Recommendations:

• If you want to enforce end-to-end private connectivity, consider using all private endpoints for your Databricks workspace including the front end and storage accounts, combined with strict NSG and routing policies.
• Use Azure NAT Gateway or firewall appliances to filter egress traffic if you need more control on outbound access from your Databricks clusters.
• Monitor Azure network logs and Databricks diagnostic logs to identify traffic paths.
• Refer to these official steps for deploying Databricks in a VNet with detailed subnet and NSG guidance:Deploy Azure Databricks in VNet.

So, What you’re seeing is expected behavior because the Fabric integration uses Microsoft’s internal backbone and Databricks still uses some public endpoints unless fully configured with private links. For complete network isolation, verify all private endpoint configs and enforce strict network rules. Microsoft documentation and product updates also highlight this evolving networking model.

i hope this helps, if not please do let me know if you have any questions on this!

Thanks,

Harish.