Use of vnet service endpoint with Azure Databricks delegated subnet

Question

Hello, I am trying to use a Microsoft.Storage vnet service endpoint on a subnet delegated to Azure Databricks (Microsoft.Databricks/workspaces) as part of a workspace deployed with VNet injection. The service endpoint is enabled on the delegated subnet, and the storage account firewall is configured to allow access from virtual networks. However, Databricks clusters are still blocked by the firewall, as if the traffic is not routed through the service endpoint. Is the use of service endpoints officially supported on subnets delegated to Azure Databricks? If not, what is the recommended approach to securely access Azure Storage without using private endpoints? Thank you in advance.

Answer 1

Hello Nassim Cherifi,

Thank you for posting your question on Microsoft Q&A!

You're encountering an issue where Azure Databricks clusters in a VNet-injected workspace aren’t able to access a storage account through a Microsoft.Storage service endpoint, even though the delegated subnet has the service endpoint enabled and the storage firewall permits the subnet.

Official Microsoft documentation confirms that VNet service endpoints are supported for connecting Azure Databricks to Azure Storage when using VNet injection. However, in practice, some users have observed that Databricks cluster traffic may not always originate from the delegated subnet as expected, especially in public preview or legacy workspace configurations, which can result in firewall blocks.

One key detail to verify: for service endpoints to work reliably with Databricks, your workspace must be deployed as a VNet-injected workspace with public access disabled (i.e., no reliance on public IPs for cluster-to-storage communication). Additionally, ensure the storage account’s “Allow trusted Microsoft services” option is not solely relied upon—explicit VNet rules must include the exact delegated subnet.

If you’re still blocked despite correct configuration, it’s worth confirming whether your clusters are actually using the workspace’s managed VNet route. A common troubleshooting step is to inspect the effective routes or outbound IPs from a running cluster node.

To help narrow this down further:

• Is your Databricks workspace deployed with public access disabled (i.e., “EnableNoPublicIP = true”)?
• Are you using a standard Databricks workspace or a secure workspace with additional isolation features?

For reference, Microsoft’s guidance on securely connecting Databricks to storage explicitly lists both service endpoints and private endpoints as valid options, though private endpoints are increasingly recommended for stricter network controls.

Reference documentation: https://learn.microsoft.com/en-us/azure/databricks/administration-guide/cloud-configurations/azure/vnet-inject

Let me know the answers to the probing questions above, I’m happy to refine the recommendation based on your exact setup.

---

Please "Accept as Answer" or click 'Thumbs Up YES' if the answer provided is useful, so that you can help others in the community looking for remediation for similar issues.

Thanks

Pratyush