cancel
Showing results for 
Search instead for 
Did you mean: 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

Understanding Azure frontend private link endpoints

mzs
New Contributor II

Hi,

I've been reading up on private link (https://learn.microsoft.com/en-us/azure/databricks/security/network/classic/private-link) and have some questions:

  1. In the standard deployment, do the transit VNet (frontend private endpoint) and Databricks workspace need to be in the same Azure subscription?
  2. Does each workspace need its own frontend private endpoint in the transit VNet? If yes, can multiple workspaces deploy frontend private endpoints into the same subnet, or do they each need their own subnet?
  3. If the clients have outbound Internet access, is a browser_authentication endpoint needed? The docs say you don't need a browser_authentication endpoint if the transit VNet has outbound Internet access. I'm not sure how to interpret that if the clients (browsers) have Internet access and are connecting to the transit VNet by VPN. It doesn't seem like connectivity outbound from the transit VNet would matter there, because the authentication happens in the browser.
  4. It sounds like the backend and frontend private link endpoints need to be in different private DNS zones. Is it best to put the frontend private link endpoint in privatelink.azuredatabricks.net and use a different zone for the backend endpoint?

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions

Zubisid
New Contributor

Below are the answers to your questions -

1) No, they don’t have to be in the same subscription. You can have the transit VNet (with the front-end Private Endpoint) in one subscription and the Databricks workspace in another, as long as you set up the networking (like VNet peering) and DNS properly.

2) Yes, each workspace needs its own front-end Private Endpoint.Yes, you can put all those Private Endpoints in the same subnet in the transit VNet, as long as the subnet has enough IPs. Separate subnets are optional but not necessary.

3) If your clients’ browsers can reach the internet directly (not relying on the transit VNet as their internet gateway), you don’t need the browser_authentication endpoint, regardless of the transit VNet’s outbound access.The transit VNet’s outbound internet access only matters if your VPN setup routes the browser’s authentication traffic through it.

4) They don’t have to be in different private DNS zones.It’s usually best to use privatelink.azuredatabricks.net for the front-end and stick with the same (or a regional variant) for the back-end, unless you have a specific reason (like regional or policy needs) to separate them.

View solution in original post

1 REPLY 1

Zubisid
New Contributor

Below are the answers to your questions -

1) No, they don’t have to be in the same subscription. You can have the transit VNet (with the front-end Private Endpoint) in one subscription and the Databricks workspace in another, as long as you set up the networking (like VNet peering) and DNS properly.

2) Yes, each workspace needs its own front-end Private Endpoint.Yes, you can put all those Private Endpoints in the same subnet in the transit VNet, as long as the subnet has enough IPs. Separate subnets are optional but not necessary.

3) If your clients’ browsers can reach the internet directly (not relying on the transit VNet as their internet gateway), you don’t need the browser_authentication endpoint, regardless of the transit VNet’s outbound access.The transit VNet’s outbound internet access only matters if your VPN setup routes the browser’s authentication traffic through it.

4) They don’t have to be in different private DNS zones.It’s usually best to use privatelink.azuredatabricks.net for the front-end and stick with the same (or a regional variant) for the back-end, unless you have a specific reason (like regional or policy needs) to separate them.

Join Us as a Local Community Builder!

Passionate about hosting events and connecting people? Help us grow a vibrant local community—sign up today to get started!

Sign Up Now