Inbound Private Link now supports account-level Genie One, the account console, and custom URLs

Enterprises adopting Databricks for their most sensitive data commonly rely on Inbound Private Link to keep user-to-Databricks traffic off the public internet, routing it privately through their own cloud network instead. As customers scale to many workspaces, multiple regions, and account-level products like Genie One, we've extended the capabilities for Inbound Private Link to meet them there.

What's new in Inbound Private Link

Inbound Private Link now supports account-level resources, including account-level Genie One, the account console, Governance Hub, and account-level APIs. Customers can put account-level Genie One behind Inbound Private Link with the same network guarantees they already apply everywhere else.

Inbound Private Link now supports Custom URLs and Managed Disaster Recovery stable URLs. Inbound Private Link now works end to end with custom URLs such as acme.databricks.com. This extends to managed disaster recovery stable URLs (e.g., acme.databricks.com/?c=stable-ws-id).

One endpoint, any region, for every UI + API resource. A single shared General Access endpoint in any region can now serve all workspace and account-level UIs + APIs. Customers no longer need to create one endpoint per region or workspace. Teams with hard network isolation requirements can still use multiple endpoints; but those endpoints are no longer constrained to serving resources in the same region. This reduces the manual toil and cost needed to maintain many endpoints. Note: service-direct endpoints (for performance-intensive services) and SCC relay endpoints (for classic-compute secure cluster connectivity) still need to be configured per region.

Built on context-based ingress

These new Inbound Private Link capabilities are baked into context-based ingress controls, which let account admins write fined-grained allow and deny rules based on who is calling (identity), from where (network source: public IP or registered endpoint), and what they're allowed to reach in the workspace or account-level resource (destination).

Policies for account-level resources like the account console can be defined in the new account-policy.

Existing workspace policies have a new “private access” section for context-based Inbound Private Link configuration.

Inbound Private Link policies for both general access and service-direct can be configured in context-based ingress. Combined with existing public access support, context-based ingress gives you a single policy engine to configure both public and private ingress for workspaces and account-level resources.

We recommend customers configure context-based ingress instead of all-or-nothing IP access lists or Private Access Settings to gain the most benefit from our platform’s latest capabilities.

Minimal setup, no disruption for existing customers

If you already use Inbound Private Link, this release is additive and non-disruptive. Non-custom workspace-specific URLs continue to work in parallel with custom URL access. Private access settings and IP access lists continue to work in parallel with context-based ingress (any policy deny leads to denial).

Enabling private access to account-level resources takes two steps:

1. Register and allowlist a General Access endpoint to your account-level resources using the context-based ingress account-policy.
2. DNS resolve your custom URL to that General Access endpoint.

Get started

• Configure inbound Private Link for account-level resources (AWS, Azure)
• Learn about context-based ingress control and managing ingress policies (AWS, Azure)
• Review inbound Private Link for workspaces (AWS, Azure) and service-direct Private Link (AWS, Azure)

All new Inbound Private Link capabilities described here are available now in Beta on AWS Enterprise tier and Azure Premium tier. Context-based ingress controls for public access are Generally Available. Try them both today!