Set up Azure private network link to Databricks

||Connect docs via MCP

Connect Atlan to an Azure Databricks workspace over Azure Private Link. Same five phases as the AWS guide, plus the endpoint approval handshake and the NSG rule, explained in full, because they're the steps most setups stall on.

New to private links?

Read How private connectivity works first. In particular the pending → approved lifecycle and the "approved ≠ working" caution below are introduced there.

Prerequisites

• Azure Databricks Premium tier, with front-end Private Link supported on the workspace.
• Your Atlan tenant hosted on Azure. The Private Link method follows the workspace's cloud, but Atlan supports cross-region and cross-cloud connectivity, see Special cases for how those scenarios are handled.
• Someone with Azure portal access to the Databricks workspace resource, able to approve private endpoint connections (Phase 3) and edit NSGs if needed (Phase 4).

Azure Private Link is strictly per-workspace

Atlan's private endpoint targets one workspace's Resource ID. An approved Private Link to your dev workspace does nothing for your prod workspace, each workspace needs its own endpoint, its own approval, and its own DNS record. "The Private Link is approved but this workspace still fails" is, most of the time, a link that covers a different workspace.

Five phases at glance

Who does what: Databricks admin · Atlan support · Your cloud/network team · You, in Atlan

Phase	What happens	Owner	Typical time
1. Gather	Share workspace URL + Resource ID	Databricks admin	10 minutes
2. Build	Atlan creates a Private Endpoint targeting the workspace	Atlan support	1-2 business days
3. Approve	Approve the pending endpoint in the Azure portal (the critical handshake)	Your cloud/network team	15 minutes
4. DNS and NSG	Atlan maps DNS; your NSG must permit Atlan's CIDR on 443	Atlan support + Your cloud/network team	Same day
5. Connect and verify	Point Atlan at the workspace URL and test	You, in Atlan	30 minutes

Phase 1: Gather your workspace details (Databricks admin)

Raise a support request from within Atlan with your tenant URL and, for each workspace:

• Workspace URL, for example adb-1234567890123456.7.azuredatabricks.net
• Workspace Resource ID, from the Azure portal, workspace resource → Overview → JSON view. It looks like:

/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Databricks/workspaces/<workspace-name>

Connecting several workspaces (dev, stage, prod)? Paste all URLs and Resource IDs into one ticket, clearly labeled, each gets its own endpoint.

Phase 2: Atlan builds private endpoint (Atlan support)

Atlan creates a Private Endpoint in its network targeting your workspace's Resource ID with sub-target databricks_ui_api (the workspace's web UI and REST API front end). Support replies, typically within 1-2 business days, with:

• The name of the private endpoint that appears as a pending connection on your workspace
• The private CIDR range Atlan's traffic originates from on the private path (needed for Phase 4's NSG rule)

Phase 3: Approve pending endpoint (your cloud/network team)

Until approved, the endpoint exists but carries no traffic. Here's the full lifecycle:

1. Created, Atlan builds the endpoint (Phase 2). Automatically moves to:
2. Pending, waiting for your approval. Connections time out in this state. After you approve in the portal:
3. Approved, control plane accepts. Atlan sees the status flip too. After DNS and NSG:
4. Working, verified end-to-end in Phases 4-5.

Approve in the Azure portal: open the Databricks workspace resource → Networking → Private endpoint connections, find the pending connection whose name matches Phase 2, and click Approve.

Approved ≠ working

Approval is a control-plane state change. Packets can still be dropped by an NSG, a missing DNS record, or a workspace-side network control. Don't skip Phases 4-5 because the portal shows Approved / Succeeded, the hardest connectivity cases seen are exactly this state.

Phase 4: DNS mapping and NSG rule (Atlan support + your cloud/network team)

Two halves, one on each side:

• Atlan's half, DNS. Atlan links the privatelink.azuredatabricks.net private DNS zone in its network and creates an A-record so adb-….azuredatabricks.net resolves to the endpoint's private IP. This is per hostname, confirm the exact workspace URLs on the ticket.
• Your half, NSG. Any network security group on the Private Link path must permit inbound HTTPS from Atlan's private CIDR range (from Phase 2) to the workspace on TCP 443. Approval doesn't open this; it's a separate rule.

# Allow Atlan's private range to reach the Databricks Private Link path
Source:      10.238.68.0/22   # your tenant's CIDR - from your support ticket
Destination: VirtualNetwork (the PE subnet)
Port:        443  Protocol: TCP  Action: Allow

Once both halves are in place, Atlan validates DNS resolution and TCP 443 reachability from the tenant and confirms on the ticket.

Phase 5: Connect and verify (You)

1. In the crawler setup, enter the normal workspace URL (adb-….azuredatabricks.net) in the Host field, the DNS mapping routes it privately.
2. Click Test connection.

Success checklist

• Test connection passes
• SQL warehouses are listed in the crawler setup
• Preflight checks pass
• A crawl scoped to one small catalog completes
• A full crawl or miner run completes

If it still times out after all five phases

When the Atlan-side path is verified clean (DNS resolves to the endpoint IP, NSGs permit the traffic, endpoint shows Approved / Succeeded) and port 443 still times out, the drop is on the destination side of the Private Link. This is the point to bring Databricks support and Microsoft support into a joint call, Atlan shares its network-path evidence on the ticket to accelerate that conversation. Don't burn days re-checking the approved endpoint; escalate with the evidence.