topic Re: Understanding Azure frontend private link endpoints in Administration & Architecture

Understanding Azure frontend private link endpoints

mzs — Sat, 22 Mar 2025 20:21:57 GMT

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:

In the standard deployment, do the transit VNet (frontend private endpoint) and Databricks workspace need to be in the same Azure subscription?
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?
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.
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!

Re: Understanding Azure frontend private link endpoints

Zubisid — Sun, 23 Mar 2025 00:28:43 GMT

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.