Azure Databricks Private Link vs NCC choose the pattern by traffic flow
Private Link and Network Connectivity Configurations are not competing controls. The right design depends on who is connecting, which compute plane is involved and where the traffic needs to go.
User / BI / API
inbound access
Workspace
UI and APIs
Classic compute
cluster control traffic
Control plane
REST / SCC relay
Serverless compute
outbound data access
Azure resource
Storage / SQL / Key Vault
Classic compute
customer VNet path
Azure / on-prem
data sources and services
Start with the traffic path. Then choose the network control that protects that path.
Start with the flow
Private Link and NCC solve different parts of the network
Private Link creates private network paths. NCC is the Databricks account-level construct used to manage serverless connectivity. The distinction becomes clear once the origin and destination are explicit.
Inbound access corridor
Private access from the corporate network to Databricks.
Client
Corporate user
VPN / ExpressRoute
Transit
Private endpoint
databricks_ui_api
Destination
Workspace
UI · REST API
Browser authentication
Private browser sign-in needs the required authentication endpoint and DNS path.
Public access is separate
Creating a private endpoint does not by itself make the workspace private-only.
Inbound Private Link protects the path into Databricks. It does not define how compute reaches your data sources.
Inbound Private Link
Use Private Link when the workspace itself must be reached privately
Inbound Private Link secures user, API and application access to Azure Databricks. The private endpoint normally lives in a transit network that users can reach from the corporate network.
Protect the workspace entry point
Web UI and REST API traffic can stay on private networking.
Plan authentication and DNS together
The endpoint exists only if clients resolve and route to it correctly.
Decide whether public access remains available
Private connectivity and public-access policy are separate design choices.
Classic compute
Classic compute has two different private paths
VNet injection places classic compute in your network. From there, one path goes to the Databricks control plane and another goes to storage, databases or on-premises systems.
Control-plane path
Classic compute plane Private Link keeps REST and secure-cluster-connectivity relay traffic on private networking.
Data path
Private endpoints, routes, peering and VPN or ExpressRoute control access from the customer VNet to data sources.
Do not combine the two mentally
A private control-plane path does not automatically create a private path to ADLS, SQL or an on-premises ERP.
Classic compute path split
One cluster, two network responsibilities.
Customer VNet
Classic compute
Path A
To Databricks control plane
REST API and SCC relay traffic.
Path B
To customer resources
ADLS, SQL, services and on-premises sources.
VNet injection gives classic compute customer-managed networking. It does not apply to serverless compute.
Serverless networking
NCC is the serverless network boundary, not a replacement for Private Link
A Network Connectivity Configuration is an account-level regional object. Workspaces attach to it so serverless compute can use the network controls defined for that NCC.
Attached workspaces
Regional control
NCC
Private destinations
10 NCCs
current maximum per region per account
100 private endpoints
per region, distributed across NCCs
50 workspaces
current maximum attachments per NCC
Scope
Regional and account-level
The NCC can be attached to several workspaces in the same region.
Isolation
Separate where the boundary differs
Dev, test, prod or business units often deserve separate NCCs when their network policy differs.
Direction
Outbound only
NCC does not secure inbound access from users to the Databricks workspace.
Serverless egress
NCC is only one part of serverless egress control
The network pattern depends on whether the destination needs a private endpoint, a controlled Azure service path or a restricted external destination.
Private path
Azure PaaS
Use NCC private endpoint rules for supported Azure resources when traffic must stay on private connectivity.
NCC + PEPrivate VNet path
Internal service
Serverless compute can privately reach supported resources in a customer VNet through the Databricks private connectivity pattern and a Standard Load Balancer.
NCC + LBAzure firewall path
Storage
Service-endpoint access and Azure Network Security Perimeter rules can control storage access without a private endpoint.
NSP / service tagExternal egress
FQDN / IP
Serverless network policies restrict outbound destinations and apply even when the path uses a private endpoint.
Network policyPrivate connectivity and egress authorization are separate layers. A private endpoint does not automatically allow the destination.
Decision guide
Choose the networking pattern in three questions
Do not start with a product name. Start with direction, compute plane and destination.
Question 1
Is the traffic going into Databricks or out from compute?
Into Databricks
User, BI client or API
Use inbound Private Link when the workspace entry path must be private.
Out from compute
Question 2: classic or serverless?
Classic
Use VNet controls for customer resources and back-end Private Link for control-plane isolation.
Serverless
Question 3: does the destination require a private path?
Serverless + private destination
Use NCC private endpoint rules
Serverless + controlled non-private path
Use the appropriate firewall, NSP and network-policy controls
Hybrid manufacturing network
Two compute planes, two private connectivity patterns.
Plant
ERP / MES
on-premises
Classic path
VNet compute
VPN / ExpressRoute
Landing
ADLS
private endpoint
Analytics
Serverless
SQL / jobs
Serverless path
NCC
private endpoint rule
Serving
ADLS / Azure SQL
private data access
Food manufacturing example
A hybrid factory can need both classic VNet networking and NCC
A common manufacturing design combines private plant connectivity with serverless analytics. The mistake is assuming one network pattern covers both compute planes.
Operational ingestion
Classic compute can use the customer VNet to reach ERP, MES or file services over VPN or ExpressRoute.
Serverless analytics
Serverless SQL and jobs use NCC-managed connectivity to private Azure destinations.
One platform, separate paths
The data platform can be unified while the network controls remain compute-plane specific.
Validation
Validate the private path layer by layer
A private endpoint can exist while the workload still fails. Test name resolution, routing, endpoint state and identity separately.
01
Resolve
Does the hostname resolve to the expected private destination?
02
Route
Can the actual workload reach that network path?
03
Establish
Is the private endpoint approved and established on the target resource?
04
Authorize
Does the Databricks identity have permission on the data or service?
Test from the same compute plane that will run in production. A successful laptop test or classic-cluster test does not prove serverless connectivity.
Automation
Automate NCC after the network boundary is clear
This guide focuses on architecture. Once the serverless path is decided, the NCC, private endpoint rules and workspace binding can be automated with the Databricks Terraform provider.
Read the NCC Terraform guideTerraform implementation
Three Databricks account resources
Keep the implementation guide separate so architecture decisions and Terraform mechanics do not compete on the same page.
Common mistakes
Avoid networking designs that mix compute planes and traffic directions
Most failures come from applying the right control to the wrong path, or validating the design from a different workload than the one that will run in production.
Avoid
Treating NCC as a replacement for Private Link
Better default
Classify the traffic direction first
Avoid
Reusing classic VNet assumptions for serverless
Better default
Design serverless egress as its own network plane
Avoid
Creating a private endpoint and assuming public access is disabled
Better default
Configure private connectivity and public-access policy separately
Avoid
Testing from a laptop or classic cluster only
Better default
Validate from the actual production compute plane
Avoid
Sharing one NCC across unrelated security boundaries
Better default
Separate NCCs when environments or business units require isolation
Avoid
Troubleshooting RBAC before DNS and routing
Better default
Validate resolve, route, endpoint state and identity in order
How Food For Analytics implements it
We design the network around the workload path, not around one connectivity feature
In Titan, classic and serverless compute can coexist. We define the network boundary for each workload, automate the required controls and validate the path from the compute that will actually use it.
01 · Map
Classify every traffic path
Inbound, classic control-plane, classic data-plane and serverless egress are treated separately.
02 · Implement
Apply the right control
03 · Validate
Prove the end-to-end path
DNS, routing, private endpoint state and data permissions are tested from the real workload.
FAQ
Frequently asked questions
Practical answers about Azure Databricks Private Link, NCC and serverless networking.
Is Databricks NCC the same as Azure Private Link?
No. Azure Private Link is the private connectivity technology. A Databricks Network Connectivity Configuration is an account-level regional construct used to manage serverless network connectivity, including private endpoint rules.
When do I need an NCC?
Use an NCC when Azure Databricks serverless compute needs controlled connectivity to customer resources. Private endpoint rules inside the NCC provide private connectivity to supported Azure resources, while other serverless controls can govern service-endpoint, firewall and external egress paths.
Does NCC replace VNet injection?
No. VNet injection applies to classic compute and places classic compute resources in a customer-managed VNet. Serverless compute runs in a Databricks-managed network and uses serverless networking controls such as NCC.
Does configuring Private Link automatically disable public access?
No. Private connectivity and public network access are separate controls. If the security requirement is private-only access, configure the relevant public-access or ingress restrictions as part of the design.
What is the difference between classic compute plane Private Link and a private endpoint to ADLS?
Classic compute plane Private Link secures traffic from classic compute to Azure Databricks control-plane services. A private endpoint to ADLS secures the data path from the compute plane to the storage account. They protect different flows.
Can serverless compute privately reach resources inside a VNet?
Yes, for supported patterns. Azure Databricks can establish serverless private connectivity to resources exposed behind a supported Standard Load Balancer in the customer VNet.
Can one NCC be shared across workspaces?
Yes. An NCC can be attached to multiple workspaces in the same region, subject to current service limits. Separate NCCs are usually clearer when dev, test, prod or business units require distinct isolation boundaries.
How many private endpoints can an NCC design use?
Current Azure Databricks limits allow up to 10 NCCs per region per account, 100 private endpoints per region distributed across those NCCs, and up to 50 workspace attachments per NCC. Verify current limits before production rollout.
Practical next step
Validate your Databricks network path before production
We can review the traffic flows, compute planes, private endpoints, DNS, routing and serverless egress controls before they become part of the production platform.