Databricks Private Network Gateway: Egress, Not Workspace Access

Serverless adoption often stops at the network boundary. Private databases, package repositories and internal APIs need approved connectivity, while endpoint-by-endpoint provisioning creates coordination work.

Private Network Gateway (PNG) introduces a network-level path from Databricks serverless compute into a customer network. That changes outbound connectivity, not how users access a workspace.

A simpler connection model still needs explicit ownership of routes, DNS and security controls. To address serverless connectivity delays, we recommend treating PNG as an egress boundary, retaining Private Link, and adopting it through tested, reversible stages.

What Changed

PNG adds that outbound path and is in Public Preview on Azure, according to the Azure gateway documentation. It connects serverless compute to resources in a customer VNet and transitively connected networks through a managed gateway.

The Azure configuration guide requires subnet delegation to Microsoft.Databricks/workspaces. Use an unused, dedicated subnet with a /28 CIDR block or larger. Databricks operates the gateway without customer-managed gateway VMs.

Configuration belongs inside a Network Connectivity Configuration (NCC), the account-level object for serverless networking. Workspaces use the gateway through their attached NCC.

Prerequisites and preview scope

PNG requires Azure Databricks Premium. Account administrators can manage feature access from the account console Previews page. The gateway, its subnet and attached workspaces must share the NCC region. The VNet subscription and workspace subscriptions must belong to the same Microsoft Entra ID tenant.

The documentation lists support for serverless Azure Databricks Runtime products and AI services. Preview limits include two gateways per NCC, two DNS resolvers per gateway and 100 destinations per gateway.

A new outbound path, not new workspace access

PNG addresses connections initiated by supported serverless workloads. It does not replace workspace access connectivity or compute-to-control-plane connectivity. Do not confuse it with Unity Gateway, which governs coding-agent access to models and tools.

It also complements serverless Private Link. The Databricks announcement positions PNG around customer networks, including private databases, internal services and on-premises destinations.

Azure Databricks evaluates outbound connections in this order:

Private endpoint rules retain precedence over PNG. Where no private endpoint rule matches, Azure Blob storage follows the service-endpoint path, which PNG cannot override.

Two traffic modes

SPECIFIC_DESTINATIONS routes the DNS names listed in destinations through PNG. Other traffic follows existing routing rules. The documentation recommends this mode for most use cases.

ALL_TRAFFIC routes remaining outbound traffic through PNG after higher-priority paths apply. It supports customer-controlled firewall inspection and customer-owned outbound IP addresses.

Serverless egress policy behaves differently between these modes. Gateway destinations receive automatic allowance in SPECIFIC_DESTINATIONS; ALL_TRAFFIC requires explicit destination allowances in the egress network policy.

Why It Matters for Platform Teams

PNG changes the unit of connectivity from an individual resource to a network boundary. That can reduce repeated infrastructure work, but it makes the reachable network behind that boundary more important.

We treat an NCC attachment as a security-relevant platform change. A shared NCC can connect several workspaces to the same gateway, so its reach becomes part of each workspace's network design.

Assign responsibility across the full connection path. The gateway manages one part of that path, not destination authorisation or the customer network.

Private reachability does not grant database privileges or API permissions. Network access and application authorisation remain separate controls.

Use Case: Hybrid Logistics Ingestion

Starting situation. Consider a hypothetical logistics organisation with operational databases on-premises and private services in Azure. Its platform team wants serverless ingestion, while central security teams approve network changes.

Why the usual approach breaks. Teams request separate connectivity arrangements for each source. Each addition needs coordination across database owners, Azure networking and Databricks administration, so onboarding waits behind infrastructure changes.

Applying the change. A pilot connects a supported serverless ingestion workload through PNG to a dedicated Azure subnet. Existing routed connectivity carries database traffic over ExpressRoute to the on-premises network.

A private package repository supplies dependencies. Established NCC private endpoints continue to serve Azure Storage.

The network team permits only the pilot destinations and required ports. The database owner authorises an environment-specific workload identity with read-only access.

What to measure. Compare onboarding effort and operational behaviour against the existing approach. Treat these measures as evaluation criteria, not promised benefits.

Implementation

Turn the pilot criteria into a deployment contract before creating the gateway. We use that contract to control network scope and promotion.

1. Build a workload-to-destination contract

1. Inventory each serverless workload proposed for the pilot.
2. Record its workspace, product, destination FQDN, port, protocol and service owner.
3. Record the expected DNS answers and selected network path.
4. Record the workload identity, processing purpose, data owner, classification and required application permission.
5. Define retention and protection controls for sensitive data.
6. Add denied destinations and unauthorised workspace cases.
7. Capture existing NCC attachments, private endpoint rules, egress policy, routes and DNS settings.

Keep this contract in the deployment repository. Include the expected path, not only whether a connection must succeed.

Storage through an NCC private endpoint and an internal API through PNG need separate assertions. A successful request alone cannot distinguish those paths.

2. Prepare the customer-owned network boundary

1. Define network infrastructure in version-pinned NexOps-managed Terraform modules.
2. Define groups, grants and NCC attachments in Terraform.
3. Verify downstream connectivity from the gateway subnet.
4. Verify the return path from each destination.
5. Configure private DNS resolution for Azure and on-premises names.
6. Restrict destination ports and address ranges to the approved contract.
7. Disable public access on destination PaaS services.
8. Connect those services through private endpoints.

Transitive connectivity means reaching a destination through an intermediate network. VNet peering alone does not establish every required transit path. Verify each route through the hub, security appliance and ExpressRoute or VPN connection.

Use managed identities or service principals for workloads. Manage human access through account-synchronised Entra ID security groups, with privileged access eligible through PIM.

Use workload identity federation for deployment pipelines. Store unavoidable secrets in the environment's Key Vault, with private access and group-based permissions.

The provider v1.137.0 resource documentation confirms Azure support for databricks_private_network_gateway. The resource requires an Azure account-level Databricks provider with access to the Private Network Gateway V1 API. Define it inside a NexOps-managed Terraform module.

The required arguments are display_name, parent and traffic_mode. Set parent to accounts/ACCOUNT_ID/network-connectivity-configs/NCC_ID, replacing both identifiers with the existing account and NCC IDs. For Azure creation, supply the full delegated subnet resource ID in azure_cloud_connection.gateway_subnet.resource_id and select bandwidth_tier_gigabits_per_second explicitly.

These Azure creation fields are mandatory despite their optional general-schema labels. Supported Azure bandwidth tiers are 10, 30, 50 and 100 Gbps.

Provide approved DNS names in destinations for SPECIFIC_DESTINATIONS. Gateway creation returns a long-running operation; require an established gateway before running connectivity tests. Pin the tested provider version and commit the lock file.

3. Test from the intended serverless workload

1. Deploy the connectivity test as a bundle-managed workload.
2. Run it with the intended workload identity.
3. Resolve each approved destination by its configured hostname.
4. Check the DNS answers against the contract.
5. Connect through the workload's normal client and protocol.
6. Verify TLS and application authorisation.
7. Correlate the request with network and destination logs.
8. Test the denied destinations and unauthorised workspace cases.
9. Confirm that existing Private Link connections retain their expected paths.

Use synthetic, masked or anonymised data outside production. Use read-only application operations where possible.

A VM test in the destination VNet does not prove the serverless path. Connect by hostname rather than substituting an IP address, because destination selection uses configured DNS names.

A certificate error does not prove network isolation. Require the expected firewall or policy evidence for blocked connections.

4. Promote one artefact through DTAP

1. Use separate workspaces, NCCs, gateway subnets, identities, Key Vaults and Terraform state for each environment.
2. Build the deployment artefact once.
3. Start with SPECIFIC_DESTINATIONS.
4. Deploy infrastructure through Terraform pipelines.
5. Deploy jobs and other workload resources through Databricks Asset Bundles.
6. Promote through each branch using a pull request.
7. Run smoke tests after each deployment.

Use shared modules, bundle includes and pipeline templates. Configure bundle targets for dev, test, acc and prd, with jobs running as service principals.

Run linting, tests, Terraform validation and plans, and bundle validation on every pull request. Run infrastructure security scans, SAST, dependency and licence checks, and secret scanning. Require deployment approval in acc and prd.

Stop promotion if a smoke test fails. Assess ALL_TRAFFIC as a separate change with its own evidence.

We describe reusable controls in our Terraform platform practices and our Databricks bundles guide.

5. Define rollback before enabling the gateway

1. Agree connectivity error, latency and recovery thresholds with the workload owner.
2. Record the rollback decision owner in the runbook.
3. Preserve existing private endpoint rules throughout the pilot.
4. Keep the previously approved execution path available.
5. Rehearse restoration through the deployment pipeline.
6. Run baseline tests after restoration.
7. Record recovery time and compare it with the agreed objective.

Stop promotion if an approved destination resolves outside its contract. Also stop if a denied destination succeeds or required inspection evidence is absent.

If the workload breaches an agreed threshold, trigger rollback. Restore the last approved gateway configuration without changing unrelated private endpoint rules.

Pitfalls and When Not to Use It

Public Preview is not a production commitment. Verify regional and workload eligibility before scheduling delivery. Do not infer PNG support from the separate NCC private-endpoint product list.

Destination matching includes suffixes. A configured name such as mydb.contoso.com also matches sub.mydb.contoso.com. Review that scope before approving a destination.

ALL_TRAFFIC does not guarantee universal inspection. Higher-priority paths remain outside PNG. Do not promise that a central firewall observes every serverless connection.

Shared connectivity creates shared failure domains. A resolver outage, firewall rule error or unavailable transit path can affect several workloads together. Separate materially different trust boundaries instead of maximising NCC reuse.

Automatic allowance is not destination authorisation. SPECIFIC_DESTINATIONS changes serverless egress allowances. Customer-network controls and application permissions must still enforce least privilege.

Preview economics need a future cost model. Microsoft states that PNG billing begins on or after 1 December 2026. Do not treat temporary preview economics as the steady-state cost.

We would not make PNG the default production dependency during this preview. Keep evaluation separate from production commitments, and require documented risk ownership for any production exception.

Retain established connectivity when it already meets requirements without substantial onboarding work. PNG is most relevant when repeated private-resource onboarding creates a measurable delivery constraint.

Key Takeaways

Use these actions to keep the egress redesign bounded and reversible. Begin with the connection contract before approving gateway deployment.

1. Document the permitted connection paths before choosing a gateway scope.
2. Retain separate designs for workspace access and resource-specific Private Link.
3. Allocate responsibility across the gateway, customer network and destination service.
4. Prove both access and isolation with workload-level tests and route evidence.
5. Stage adoption across all four environments with a rehearsed recovery path.
6. Separate preview evaluation from production risk and future cost decisions.