Skip to main content
Community Hub

How Atlan connects to Databricks

TL;DR

Understand the three connectivity paths between Atlan and Databricks—public, Private Link, and site-to-site VPN—and what determines which one applies to your workspace.

Your AI can read this via Docs MCPcurl -fsSL "https://docs.atlan.com/install-docs-mcp" | bashConnect

Atlan reaches Databricks over one of three paths: the public internet, a cloud-provider-internal private link, or an encrypted site-to-site VPN tunnel. The right path isn't a preference—it's shaped by your Databricks tier, which cloud your Atlan tenant runs on, and your organization's security policy. Understanding those constraints before touching any configuration saves significant re-work if you later discover your workspace enforces private-only access.

What determines your connectivity method​

Three variables constrain the choice:

VariableWhere to find it
Cloud and region of your Atlan tenantAdmin Center → Overview → Deployment. If you can't see it, ask your Atlan admin or raise a support request.
Cloud, region, and pricing tier of your Databricks workspaceWorkspace URL tells you the cloud: *.cloud.databricks.com = AWS, adb-*.azuredatabricks.net = Azure, *.gcp.databricks.com = GCP. Your Databricks account admin can confirm region and tier. Front-end Private Link requires Enterprise on AWS and Premium on Azure.
URL and workspace ID of every workspace you plan to connectURL is what you open in a browser. Workspace ID is the number after ?o= in the URL, or in the Databricks Account Console. Private connectivity is configured per workspace—list all of them before you start.

Three connectivity methods​

Public + IP allowlistingPrivate LinkSite-to-site VPN
Traffic pathPublic internet, TLS-encryptedNever leaves the cloud provider's private networkEncrypted tunnel between Atlan's network and yours
Databricks tierAnyEnterprise (AWS) / Premium (Azure)Any
Atlan tenant cloudAWS, Azure, or GCPAWS or Azure—follows the workspace's cloud. Cross-region and cross-cloud supported. GCP tenants use IP allowlisting.Any
Use whenSecurity policy permits TLS from known IPsOrganization requires no public path, or workspace already enforces private-only accessDatabricks is private-only and Private Link isn't available
Start hereAllowlist Atlan IPsAWS guide · Azure guideContact your account team

Private Link involves your Databricks account admin, cloud/network team, and Atlan support—engage them before starting. For AWS, the workspace must be on the E2 platform version and in an E2-supported region; state both clouds and regions in your first support ticket. Site-to-site VPN requires a scheduled change window with both network teams.

Many organizations run Private Link and an IP access list on the workspace. Over a private link the access list must permit Atlan's private CIDR ranges, not the public egress IPs—this is the most common misconfiguration in practice.

Which values to allowlist​

Your setupAllowlist thisWhere to get it
Public connectivityPublic egress (NAT) IPs for your tenantGCP: Atlan network details · AWS/Azure: support ticket
Private Link, with IP access list or NSG on the pathPrivate CIDR ranges for your tenant—not the public IPsSupport ticket (shared during Private Link setup)
Corporate firewallSource: Atlan egress IPs → Destination: workspace FQDNs → TCP 443Ask support to confirm the exact tuple for your tenant

Over a private link, allowlisting only part of a CIDR block causes intermittent failures as traffic rotates within the block. Always copy the full range.

Firewall rule​

For network teams implementing on a corporate firewall (Palo Alto, Fortinet, etc.):

FieldValue
SourceAtlan egress/NAT IPs for your tenant's region—see Atlan network details or support ticket
DestinationYour Databricks workspace FQDNs, for example your-ws.cloud.databricks.com. Use FQDN rules; workspace IPs aren't stable.
Port / protocolTCP 443 only
DirectionAtlan → Databricks (crawling and mining). Reverse direction applies only to lakehouse and MCP integrations.