Databricks can connect to network restricted sql server using serverless compute

Question

Databricks can connect to network restricted sql server using serverless compute

Daniel Ferreira 0

I have a databricks workspace that has both classic compute with a vnet and serverless compute that connects to a sql server database that has a private link to the classic compute vnet and has restricted access (ip allow list) for public IPs.

When using the classic compute dns resolves to the private IP and it works normaly.

What I don't understand is when I use serverless it resolves to the public IP and also works. My expectation would be that it would fail.

I can't figure out why this is working. If I try a failover server in a different region it fails as expected so can only speculate that something about the existing service connections is passing through to the serverless compute?

I have no Network Connection Configuration.

Manoj Kumar Boyini 18,595 Reputation points Microsoft External Staff Moderator

2026-06-24T15:30:09.0433333+00:00

Hi @Daniel Ferreira

What you're observing is expected behavior if the Azure SQL Server still allows public network access.

Classic compute uses your VNet and private endpoint configuration, which is why the SQL Server resolves to the private IP address.

Serverless compute uses a separate Databricks-managed networking path. Since the SQL Server resolves to its public endpoint from serverless compute, the connection will still succeed as long as public connectivity is permitted by the SQL Server networking configuration and firewall settings.

Therefore, the successful connection from serverless compute does not necessarily indicate that traffic is traversing the private endpoint or inheriting connectivity from the classic compute VNet.

In this scenario, the most likely explanation is that public network access to the SQL Server is still allowed. If public access were blocked, the serverless connection would be expected to fail when resolving to the public endpoint.

Please let us know if you have any questions.
Manoj Kumar Boyini 18,595 Reputation points Microsoft External Staff Moderator

2026-06-25T06:57:50.2233333+00:00

Hi @Daniel Ferreira

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Daniel Ferreira 0 Reputation points

2026-06-25T07:50:28.4033333+00:00

Serverless compute uses a separate Databricks-managed networking path. Since the SQL Server resolves to its public endpoint from serverless compute, the connection will still succeed as long as public connectivity is permitted by the SQL Server networking configuration and firewall settings.

Like I said our SQL server is restricted by IP and we never explicitly allowed the serverless connection, yet it works on the primary SQL server. However the identically configured failover geo replica does not.

Both servers have the exact same network rules applied by terraform, so why does it work in the primary?
Manoj Kumar Boyini 18,595 Reputation points Microsoft External Staff Moderator

2026-06-26T10:46:19.0966667+00:00

Hi @Daniel Ferreira

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.

2 answers

Your answer

Manoj Kumar Boyini 18,595 Reputation points Microsoft External Staff Moderator

2026-06-24T15:30:09.0433333+00:00

Hi @Daniel Ferreira

What you're observing is expected behavior if the Azure SQL Server still allows public network access.

Classic compute uses your VNet and private endpoint configuration, which is why the SQL Server resolves to the private IP address.

Serverless compute uses a separate Databricks-managed networking path. Since the SQL Server resolves to its public endpoint from serverless compute, the connection will still succeed as long as public connectivity is permitted by the SQL Server networking configuration and firewall settings.

Therefore, the successful connection from serverless compute does not necessarily indicate that traffic is traversing the private endpoint or inheriting connectivity from the classic compute VNet.

In this scenario, the most likely explanation is that public network access to the SQL Server is still allowed. If public access were blocked, the serverless connection would be expected to fail when resolving to the public endpoint.

Please let us know if you have any questions.
Manoj Kumar Boyini 18,595 Reputation points Microsoft External Staff Moderator

2026-06-25T06:57:50.2233333+00:00

Hi @Daniel Ferreira

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Daniel Ferreira 0 Reputation points

2026-06-25T07:50:28.4033333+00:00

Serverless compute uses a separate Databricks-managed networking path. Since the SQL Server resolves to its public endpoint from serverless compute, the connection will still succeed as long as public connectivity is permitted by the SQL Server networking configuration and firewall settings.

Like I said our SQL server is restricted by IP and we never explicitly allowed the serverless connection, yet it works on the primary SQL server. However the identically configured failover geo replica does not.

Both servers have the exact same network rules applied by terraform, so why does it work in the primary?
Manoj Kumar Boyini 18,595 Reputation points Microsoft External Staff Moderator

2026-06-26T10:46:19.0966667+00:00

Hi @Daniel Ferreira

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.

Answer 1

Hello @Daniel Ferreira

When no Network Connectivity Configuration (NCC) private endpoint is configured, serverless compute uses Databricks-managed networking and can connect to resources using NAT IPs and service endpoints rather than the VNet path.

Azure Databricks also documents support for the AzureDatabricksServerless service tag through Azure Network Security Perimeter (NSP) configurations, and publishes outbound IP information for serverless compute for firewall allow-list scenarios.

Given that the primary SQL Server accepts the connection while the geo-replica does not, Azure Databricks documentation does not describe any behavior where serverless compute inherits the private endpoint connectivity of classic compute. Therefore, the successful connection is being allowed through the networking controls applicable to the primary SQL Server.

References:
https://learn.microsoft.com/en-us/azure/databricks/resources/ip-domain-region#azure-serverless-outbound-ips
https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/serverless-nsp-firewall

Please let us know if you have any questions.

Answer 2

hi Daniel Ferreira, thx for sharing urs issue here at Q&A portal,

serverless is reaching SQL over the public endpoint, and the SQL firewall is allowing that source somehow.

Private Link from ur classic compute VNet won’t automatically apply to Databricks serverless. Serverless doesn’t sit in ur classic VNet unless u configure serverless network connectivity/NCC. So if DNS resolves to the public IP from serverless, that path is public, not private. If it still works, I’d check the SQL server firewall and networking settings. Common reason is Allow Azure services and resources to access this server being enabled. That can allow traffic from Azure services even when u didn’t explicitly add a public IP. Another possibility is a broad firewall rule/range that includes the serverless egress IPs.

Quick way to prove it is checking SQL auditing / connection logs and see the client IP for the serverless session. Compare that IP against SQL firewall rules and any Azure service access setting.

https://learn.microsoft.com/en-us/azure/azure-sql/database/firewall-configure

https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/serverless-network-connectivity

If u want serverless to use private access, set up Network Connectivity Configuration for serverless and route it thru private endpoints as supported. Without NCC, don’t assume private DNS/private link from classic compute applies to serverless.

My guess is nothing magic is being passed from classic compute. Serverless is just allowed by SQL firewall/public Azure access. The failed region case prob means the failover server has diff firewall/private endpoint/DNS settings, so it behaves the way u expected.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal