How Atlan connects to Databricks
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:
| Variable | Where to find it |
|---|---|
| Cloud and region of your Atlan tenant | Admin 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 workspace | Workspace 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 connect | URL 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 allowlisting | Private Link | Site-to-site VPN | |
|---|---|---|---|
| Traffic path | Public internet, TLS-encrypted | Never leaves the cloud provider's private network | Encrypted tunnel between Atlan's network and yours |
| Databricks tier | Any | Enterprise (AWS) / Premium (Azure) | Any |
| Atlan tenant cloud | AWS, Azure, or GCP | AWS or Azure—follows the workspace's cloud. Cross-region and cross-cloud supported. GCP tenants use IP allowlisting. | Any |
| Use when | Security policy permits TLS from known IPs | Organization requires no public path, or workspace already enforces private-only access | Databricks is private-only and Private Link isn't available |
| Start here | Allowlist Atlan IPs | AWS guide · Azure guide | Contact 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 setup | Allowlist this | Where to get it |
|---|---|---|
| Public connectivity | Public egress (NAT) IPs for your tenant | GCP: Atlan network details · AWS/Azure: support ticket |
| Private Link, with IP access list or NSG on the path | Private CIDR ranges for your tenant—not the public IPs | Support ticket (shared during Private Link setup) |
| Corporate firewall | Source: Atlan egress IPs → Destination: workspace FQDNs → TCP 443 | Ask 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.):
| Field | Value |
|---|---|
| Source | Atlan egress/NAT IPs for your tenant's region—see Atlan network details or support ticket |
| Destination | Your Databricks workspace FQDNs, for example your-ws.cloud.databricks.com. Use FQDN rules; workspace IPs aren't stable. |
| Port / protocol | TCP 443 only |
| Direction | Atlan → Databricks (crawling and mining). Reverse direction applies only to lakehouse and MCP integrations. |