| purpose | direction | IPv4 | IPv6 |
|---|---|---|---|
databricks/all | both | · | · |
databricks/aws-egress | egress | · | · |
databricks/aws-ingress | ingress | · | · |
databricks/azure-egress | egress | · | · |
databricks/azure-ingress | ingress | · | · |
databricks/gcp-egress | egress | · | · |
databricks/gcp-ingress | ingress | · | · |
databricks/all
Direction: both. Databricks publishes these ranges for traffic in either direction; use them in the rule direction your integration needs. The example below shows egress.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_egress" "databricks_all" {
service = "databricks"
purpose = "all"
}
resource "aws_security_group_rule" "databricks_all" {
type = "egress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_egress.databricks_all.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
databricks/aws-egress
Direction: egress. Ranges your workloads connect out to; use them in security group egress rules.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_egress" "databricks_aws_egress" {
service = "databricks"
purpose = "aws-egress"
}
resource "aws_security_group_rule" "databricks_aws_egress" {
type = "egress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_egress.databricks_aws_egress.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
databricks/aws-ingress
Direction: ingress. Ranges Databricks connects from (webhook delivery); use them in security group ingress rules on your receiving endpoints.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_ingress" "databricks_aws_ingress" {
service = "databricks"
purpose = "aws-ingress"
}
resource "aws_security_group_rule" "databricks_aws_ingress" {
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_ingress.databricks_aws_ingress.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
databricks/azure-egress
Direction: egress. Ranges your workloads connect out to; use them in security group egress rules.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_egress" "databricks_azure_egress" {
service = "databricks"
purpose = "azure-egress"
}
resource "aws_security_group_rule" "databricks_azure_egress" {
type = "egress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_egress.databricks_azure_egress.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
databricks/azure-ingress
Direction: ingress. Ranges Databricks connects from (webhook delivery); use them in security group ingress rules on your receiving endpoints.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_ingress" "databricks_azure_ingress" {
service = "databricks"
purpose = "azure-ingress"
}
resource "aws_security_group_rule" "databricks_azure_ingress" {
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_ingress.databricks_azure_ingress.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
databricks/gcp-egress
Direction: egress. Ranges your workloads connect out to; use them in security group egress rules.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_egress" "databricks_gcp_egress" {
service = "databricks"
purpose = "gcp-egress"
}
resource "aws_security_group_rule" "databricks_gcp_egress" {
type = "egress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_egress.databricks_gcp_egress.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
databricks/gcp-ingress
Direction: ingress. Ranges Databricks connects from (webhook delivery); use them in security group ingress rules on your receiving endpoints.
loading ranges from the feed…
This purpose currently publishes more IPv4 ranges than the default rules-per-SG quota (60). Each CIDR consumes one rule; the hosted prefix list spends quota once per list instead. Details in the FAQ.
Terraform
data "ipranges_ingress" "databricks_gcp_ingress" {
service = "databricks"
purpose = "gcp-ingress"
}
resource "aws_security_group_rule" "databricks_gcp_ingress" {
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = data.ipranges_ingress.databricks_gcp_ingress.ipv4_cidrs
security_group_id = aws_security_group.app.id
}
keep rules current automatically
Terraform data sources refresh only when you run an apply. The hosted tier publishes the same data via AWS managed prefix lists (slash0.databricks.all.v4 and so on), shared into your account via AWS RAM: rules reference one pl-… id and update within a minute of a vendor change, with removals held through a 72 hour grace window. Request early access or read how it works.
provenance
Ranges come from Databricks's official publication: https://docs.databricks.com/aws/en/resources/ip-domain-region. Fetched sources:
Every publish is signed (ECDSA P-256 over the feed index, each service document hash-chained to it) and every range change is recorded in the changelog. Verification steps: security. Provider setup: quickstart.