## Set up Azure private network link to Databricks

URL: https://docs.atlan.com/apps/connectors/data-warehouses/databricks/how-tos/azure-private-link-to-databricks

> Connect Atlan to an Azure Databricks workspace over Azure Private Link, including the endpoint approval handshake and the NSG rule.

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.

:::note New to private links?
Read [How private connectivity works](https://docs.atlan.com/llms/connectors/databricks/how-private-connectivity-works/llms.txt) 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](https://docs.atlan.com/llms/governance/administration/cross-region-private-network-connectivity/llms.txt), see [Special cases](https://docs.atlan.com/llms/connectors/databricks/databricks-connectivity-special-cases/llms.txt) 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).

:::danger 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**.

:::caution 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

:::info 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.
:::

---