Customer Managed VPC: Databricks IP Address Ranges

[tom_1]

Hello,

how often does Databricks change its public ip addresses (the ones that must be whitelisted in a customer managed vpc) and where can I find them?
I found this list, but it seems to be incomplete.

We moved from a managed vpc to a customer-managed vpc. 
The managed vpc contains a managed security-group that whitelists the following ips (ports):
- 18.159.44.32/28 (5555-5557,22), 18.159.32.64/32 (5555-5557), 18.158.203.57/32 (5555-5557,22).

The later two mentioned ip address are not mentioned in the official list, and port information is not given at all.
So why does Databricks whitelist the later two ips and what does it need port 22 (ssh) for?

[Louis_Frolio]

Greetings @tom_1 ,  you’re right to cross-check the published list—here’s how the IPs and ports fit together and where to get the authoritative values.

Where to find the current Databricks IPs

• The official source is the Databricks “IP addresses and domains for Databricks on AWS” page. It lists per‑region control plane domains, CIDR ranges, and outbound NAT IPs, plus guidance to prefer allowlisting FQDNs (especially for SCC relay) because IPs can change periodically with infra updates and multi‑AZ deployments.
• For eu‑central‑1 specifically, the docs list:
  • Control plane services: frankfurt.cloud.databricks.com with 18.159.44.32/28.
  • Control plane outbound NAT IPs: 18.159.44.32/28 and 18.159.32.64.

Why you’re seeing 18.159.32.64 and 18.158.203.57

• 18.159.32.64 is an AWS control plane NAT IP that Databricks uses for outbound connections from the control plane in eu‑central‑1; it’s explicitly published on the docs page.
• 18.158.203.57 is an additional control plane egress IP used by Databricks in eu‑central‑1 and is widely allowlisted across our internal LBs and IP ACLs. While it is not called out on the public page, it is part of our region configuration and appears in internal allowlists for cross‑environment control plane traffic.

Why ports 22, 5555–5557 are opened to control plane IPs

• Port 22 (SSH): Databricks uses SSH from the control plane to provision EC2 instances and perform routine product updates and lifecycle actions on cluster nodes. This control‑plane‑to‑data‑plane traffic is part of managed security group rules for classic/MT workspaces.
• Port 5557: The encrypted worker proxy channel that the control plane uses to reach data plane services (Spark UI, JDBC, TensorBoard, RStudio, etc.). Traffic is TLS‑encrypted.
• Ports 5555–5556: Historically used for worker proxy traffic; many managed security group templates still include them to cover legacy paths and avoid breakage, even though modern deployments primarily rely on 5557 and 22.

How often do these IPs change?

• There is no fixed, public cadence. IPs behind Databricks control plane domains (including SCC relay endpoints) can change periodically due to infrastructure updates, scaling events, and multi‑AZ operations. That’s why the official guidance is to allowlist FQDNs for SCC endpoints and automate DNS resolution rather than pinning individual IPs.

Practical guidance for customer‑managed VPCs

• Prefer allowlisting the SCC relay domains (for eu‑central‑1: tunnel.eu-central-1.cloud.databricks.com; for PrivateLink workspaces use the PrivateLink SCC relay domain) and workspace/control plane domains rather than individual IPs, to avoid breakage when IPs move.
• If you must allowlist IP addresses, use the official docs table for your region (for eu‑central‑1: 18.159.44.32/28 and 18.159.32.64), and plan for automation to refresh IP rules when changes occur. Avoid relying on ad‑hoc IPs not listed publicly unless you manage the allowlists centrally and monitor infra changes.
• Inbound rules for MT/managed SGs commonly allow TCP 22, 5555, 5556, 5557 from Databricks control plane IPs; if you are tightening security groups in a customer‑managed VPC, ensure the modern path (22 and 5557) is permitted from the published control plane IPs or FQDNs, and prefer PrivateLink endpoints where possible.

Let us know if this helps.

Cheers, Louis.