## Allowing Atlan IPs in Databricks

URL: https://docs.atlan.com/apps/connectors/data-warehouses/databricks/how-tos/allowlist-atlan-ips-in-databricks

> Add Atlan's addresses to your Databricks workspace IP access list (or a corporate firewall in the path) so crawlers and miners can connect.

If your Databricks workspace restricts connections by IP (an IP access list), or a corporate firewall sits in the path, add Atlan's addresses so crawlers and miners can connect. GCP tenants can self-serve; AWS/Azure tenants get their tenant-specific IPs via one support ticket.

## Do I need this?

- **Yes**, if the workspace has IP access lists enabled (**Workspace settings → Security → IP access lists**), or your network team runs an egress/ingress firewall between the internet and Databricks.
- **No**, if there's no IP restriction anywhere in the path, Atlan connects without any allowlisting.
- **Different values** apply if you use Private Link, see the callout below.

## Steps

1. Find your Atlan tenant's hosting cloud and region: **Admin Center → Overview → Deployment** (or ask support).
2. Get your Atlan IPs. **GCP tenants**, copy your region's static IPs from the [network details page](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt). **AWS/Azure tenants**, raise a support ticket with your tenant URL; NAT IPs are provisioned per tenant and differ between tenants.
3. Have your Databricks admin add them to the workspace IP access list:

```bash
databricks ip-access-lists create --json '{
 "label": "atlan-egress",
 "list_type": "ALLOW",
 "ip_addresses": ["203.0.113.10", "203.0.113.11"]
}'
```

4. If a corporate firewall is in the path, give your network team the full rule: **source** = Atlan egress IPs, **destination** = workspace FQDN, **TCP 443**. The complete tuple is spelled out on the [network details page](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt).

:::caution The access list blocks Atlan the moment it's enabled
Enabling IP access lists on a workspace that Atlan already crawls breaks the connection immediately unless Atlan's IPs are in the initial list. If your security team is rolling out allowlisting, add Atlan's IPs *in the same change*, "connectivity stopped right after the whitelisting project went live" is one of the most common tickets support sees.
:::

:::danger Using Private Link?
Over a private link, connections arrive from Atlan's **private CIDR ranges**, the public IPs on this page are irrelevant. Ask support for your tenant's private range, or keep public access allowed on the PAS for non-private traffic. Covered in Phase 4 of the [AWS](https://docs.atlan.com/llms/connectors/databricks/aws-private-link-to-databricks/llms.txt) / [Azure](https://docs.atlan.com/llms/connectors/databricks/azure-private-link-to-databricks/llms.txt) guides.
:::

## GCP-hosted tenants

GCP tenants use **static dedicated NAT IPs**, published per region on the [network details page](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt), fully self-serve. (Prior to Feb 2026, GCP tenants used dynamically assigned IPs; if your access list predates that migration, refresh it against the published table.)

## When Atlan's IPs change

Rare and always announced: at least 30 days' notice by email to tenant admins, with old and new values overlapping through the change window. If workflows start failing with `Source IP address <ip> is blocked by Databricks IP ACL for workspace <id>`, compare the IP in the error against the current published values, see [network details](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt) and [troubleshooting](https://docs.atlan.com/llms/connectors/databricks/troubleshooting-databricks-connectivity/llms.txt).

---