Grab a spot →
Skip to main content

Special cases in Databricks connectivity

Connect docs via MCP

Common questions about Databricks connectivity scenarios that fall outside the standard single-workspace setup.

What if I need to connect multiple Databricks workspaces?​

Private connectivity is per workspace. To connect several (dev, stage, prod, regional):

  • List every workspace, URL, ID, and (Azure) Resource ID, in one support ticket, clearly labeled.
  • AWS: workspaces sharing a regional endpoint service can share one Atlan-side endpoint, but each needs its own registration in the Account Console and its own DNS mapping.
  • Azure: each workspace needs its own private endpoint, its own approval, and its own DNS record, no sharing.
  • Adding a workspace later is quick if the plumbing exists: often just a new DNS mapping to the existing endpoint (AWS), a same-day change. Say "add this workspace to the existing PrivateLink" in the ticket.

Can I map extra hostnames or custom ports?​

The DNS mapping inside Atlan's network is per hostname, and it can carry more than the default:

  • A second URL for the same workspace (for example a vanity or migration hostname) can be mapped to the same private endpoint; request it on your ticket with the exact FQDN.
  • Non-standard ports can be mapped where your setup requires them; the default and overwhelmingly common case is 443.
Renaming a workspace?

A renamed or re-created workspace gets a new URL, and the old DNS mapping keeps pointing at the old name until you tell Atlan. If crawls break right after a workspace migration, this is the first thing to check.

What if my Databricks workspace is on different cloud or region from my Atlan tenant?​

Your Databricks workspace doesn't have to sit in the same region, or even the same cloud, as your Atlan tenant. Atlan supports cross-region and cross-cloud private connectivity by deploying region-specific endpoint VPCs that it peers internally with your tenant's network, so all traffic stays on private cloud networks.

  • The Private Link method still follows the workspace's cloud: AWS PrivateLink for an AWS workspace, Azure Private Link for an Azure workspace.
  • For AWS, the workspace must be on the E2 version of the platform and in an E2-supported region.
  • From your side, the setup process is the same as a standard PrivateLink connection; Atlan handles the cross-region and cross-cloud routing internally.

If a private path still isn't an option for your environment, IP allowlisting over the public internet works from anywhere, or, where policy demands private-only and nothing else fits, a site-to-site VPN.

What is site-to-site VPN and when do I need it?​

For environments where Databricks is reachable only inside your network and no private link is possible, Atlan can establish a site-to-site VPN tunnel between its tenant network and yours. Know what you're signing up for:

  • It's a bespoke, jointly executed change: Atlan shares its subnet details, both network teams agree a configuration, and the cutover happens in a scheduled window with both teams on a call.
  • Routing typically goes via an agreed proxy subnet; your firewall must permit the tunnel and the Databricks-bound traffic through it.
  • Plan for lead time (weeks, not days) and a verification crawl at the end of the window before the ticket closes.

How does Atlan Metadata Lakehouse integration connect?​

With the Atlan metadata lakehouse integration, your Databricks reads data from Atlan's S3 bucket—the reverse of everything described in the connectivity guides—and it's an identity handshake rather than a network link:

  • Your Databricks environment assumes an Atlan-side read-only IAM role; Atlan whitelists your role against it with an ExternalId.
  • Request it via support with: which environment (dev/ITG/prod) the access is for, the IAM role or principal on your side, and your Atlan tenant URL. Atlan replies with the role ARN, bucket path, and ExternalId.
  • The ExternalId is per credential. Reusing an ExternalId copied from an old connection can make AssumeRole fail silently. If lakehouse reads stop working after credentials were recreated, verify the ExternalId matches what Atlan currently expects.

Why does Databricks MCP traffic go in the opposite direction, and what do I need to configure?​

Connecting Databricks (external MCP / Unity Catalog HTTP connections) to Atlan's MCP server means Databricks initiates the traffic. Two rules cover nearly every failure:

  • Use your tenant's endpoints, never the shared proxy. The URL is https://<your-tenant>.atlan.com/mcp, with OAuth endpoints on the same tenant hostname. Pointing Databricks at mcp.atlan.com can't route machine-to-machine authentication and fails with "Client not found" or a tenant-selection page.
  • If your Atlan tenant restricts inbound IPs, you must allowlist the IPs Databricks calls out from, and those are the serverless compute plane egress IPs—not your cluster's NAT IP or the workspace URL's addresses. Your Databricks admin (or Databricks support) can enumerate them; a single IP read off one screenshot is usually not the whole range. Atlan can't see or control these IPs from its side.

Private connectivity for the Atlan REST API and MCP endpoints is on the roadmap; ask your account team for current status.