# Azure Databricks private network gateway for serverless compute

> Azure Databricks private network gateway gives serverless one path into your VNet and on-premises network. How we'd pilot it, and what we'd wait on.

Published: 2026-10-17
Author: Andrey Taran
Tags: Databricks, Azure
Canonical: https://www.techfabric.com/blog/azure-databricks-private-network-gateway-serverless

---

If your Azure Databricks estate sits behind a private network, you probably still run classic clusters whose main job is to live inside the VNet. Serverless would spare you sizing and patching those clusters, but it can't see the SQL Server on a VM or the Oracle database in the data centre unless someone builds a load balancer, a Private Link service and a private endpoint rule for that one source, then approves the connection in the Azure portal. Repeat that for every source and the classic cluster starts to look like less work.

The private network gateway, now in Public Preview on Azure, replaces that per-source stack with one delegated subnet. Serverless reaches whatever the subnet can reach, including on-premises systems over ExpressRoute or a VPN, so for VNet and on-premises sources most of the reason those clusters exist goes away.

We'd pilot it on one non-critical source before billing starts on 1 December 2026, and we wouldn't make it the only route to anything in production yet. The rest of this post is the routing order a security review will care about, a Terraform pilot you can copy, and the limits and costs that decide whether it goes further.

## Who the gateway is for

The gateway is for teams whose classic compute exists mostly to reach private sources, and whose security team already accepts serverless for the rest. That's common in estates with ERP or finance databases still on VMs or on premises, where every new source has meant another ticket to the network team and another Private Link setup to maintain.

If your data already lands in cloud storage and your other sources are SaaS APIs, you can mostly ignore it. Blob storage has its own path that the gateway never touches (more on that below). A SaaS source only brings you back here if the vendor wants to allowlist a fixed source IP. Traffic through the gateway leaves from your own network's egress addresses, so those are what the vendor allowlists.

Databricks names three more uses we'd test once the path exists. [Lakeflow Connect](/databricks/data-integration) ingestion from databases in your VNet or on premises, which is where we'd expect most of the demand from ERP and line-of-business sources. Serverless installing Python libraries from a private PyPI, Artifactory or Nexus repository. And an [agent](/ai/agents) built on Databricks calling an MCP server you host privately.

## What it replaces: the per-resource Private Link stack

Today, connecting serverless to a single resource in your VNet takes four pieces of Azure and Databricks work, per resource. Microsoft's [page for private connectivity to VNet resources](https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/pl-to-internal-network) has you create an internal Azure load balancer (frontend IP, backend pool, health probe, rules), a Private Link service in the same region, and a private endpoint rule in your network connectivity configuration (NCC) listing the resource's domain names. Then someone approves the pending connection in the Azure portal, and it can take ten minutes to establish.

That's fine for two or three databases. At twenty it becomes a small infrastructure estate of its own, with limits to plan around: 100 private endpoints per region and 100 domain names per endpoint rule. Each endpoint also bills Private Connectivity by the hour (the per-GB charge is waived until further notice), so the stack costs money even when nothing runs.

The gateway works per network instead. You delegate one subnet, and serverless reaches whatever that subnet can reach. Private Link doesn't go away. Microsoft's [gateway overview](https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/private-network-gateway) still recommends a private endpoint rule for a specific cloud-managed resource such as object storage, and the gateway for resources in your VNet or a connected network.

## How serverless traffic is routed

Every outbound serverless connection is matched against four paths in a fixed order, and the first match wins. It's the first thing we'd walk a security reviewer through.

```mermaid
%% caption: Serverless outbound traffic is matched against four paths in order, and the private network gateway is the third.
flowchart TD
  A["Serverless outbound connection"] --> B["Private endpoint rule matches?"]
  B -->|"Yes"| B1["Private Link endpoint"]
  B -->|"No"| C["Azure service endpoint matches?"]
  C -->|"Yes"| C1["Cloud backbone path"]
  C -->|"No"| D["Gateway destination or all traffic?"]
  D -->|"Yes"| D1["Private network gateway into VNet"]
  D -->|"No"| E["Default serverless egress"]
  class D1 accent
```

Two consequences sit in the [setup guide's troubleshooting table](https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/private-network-gateway/configure-private-network-gateway) rather than the overview, and we'd raise both early. Blob storage always takes the Azure service endpoint path, and the gateway can't override it, so if your auditors expect every byte of egress to cross your firewall, storage traffic won't. And a gateway destination whose DNS name matches an Azure service endpoint suffix, such as an Azure SQL Database or a Key Vault, takes the service endpoint path too. For a private-only resource the fix is a more specific DNS name on the gateway.

A serverless egress control policy is evaluated before the gateway as well. If a destination is configured on the gateway and traffic is still dropped, the egress policy is the first place we'd look.

## Setting up a pilot in Terraform

We'd pick one source that currently has the load balancer and Private Link service stack in front of it, and rebuild its path through the gateway. The prerequisites are short. You need the Premium plan, account admin rights, and a dedicated `/28` or larger subnet that nothing else uses, delegated to `Microsoft.Databricks/workspaces`, in the same region as the NCC and the workspaces. The VNet's subscription has to sit in the same Microsoft Entra ID tenant as the workspaces, and the region has to be one of the 25 on the preview list (`eastus2`, `westeurope`, `uksouth` and `centralus` among them).

We'd write the gateway in Terraform from the first day, because a pilot that lives in code is reviewable and easy to remove. The [`databricks_private_network_gateway` resource](https://registry.terraform.io/providers/databricks/databricks/latest/docs/resources/private_network_gateway) is Azure-only and needs an account-level provider. This matches the provider's documented example as of October 2026:

```hcl
provider "databricks" {
  alias      = "account"
  host       = "https://accounts.azuredatabricks.net"
  account_id = var.databricks_account_id
}

resource "databricks_private_network_gateway" "pilot" {
  provider = databricks.account

  parent                             = "accounts/${var.databricks_account_id}/network-connectivity-configs/${var.ncc_id}"
  display_name                       = "png-pilot"
  bandwidth_tier_gigabits_per_second = 10
  traffic_mode                       = "SPECIFIC_DESTINATIONS"

  azure_cloud_connection = {
    gateway_subnet = {
      resource_id = var.gateway_subnet_id
    }
  }

  destinations = [{
    destination_type = "DNS_NAME"
    value            = "erp-sql.corp.contoso.com"
  }]
}
```

There's no default bandwidth tier, so you choose 10, 30, 50 or 100 Gbps yourself; the account console preselects 30. We'd start a pilot at 10. We'd leave `private_dns_resolvers` out so the gateway uses Azure-provided DNS, link any private DNS zone to the gateway's VNet, and add a custom resolver only if zone names overlap.

A few details change how we'd run it. Destinations match by suffix, so `mydb.contoso.com` also covers `sub.mydb.contoso.com`, and we'd list exact hostnames to keep the pilot narrow. Changing the subnet deletes and recreates the gateway, cutting every source behind it, so any Terraform plan that replaces it gets a manual hold. A gateway in `FAILED` state stays failed, which puts a delete-and-recreate step in the runbook. Bandwidth changes apply asynchronously with no signal for when the new capacity arrives, so we'd size up ahead of a big backfill, never during one. The last step is attaching the NCC to the workspace, after which serverless products in that workspace use the gateway with no change to the job itself.

## Specific destinations or all traffic

`SPECIFIC_DESTINATIONS` sends only the DNS names you list through the gateway, and Databricks adds those names to your serverless egress controls automatically. It's the mode Databricks recommends, and the only one we'd pilot with.

`ALL_TRAFFIC` routes every remaining outbound connection through your network, except anything a private endpoint rule already covers. That's the answer when security wants content inspection on everything serverless does. It also changes who decides whether a job runs. In this mode you have to add every destination yourself to the egress network policy, and from then on the firewall team's rules gate every serverless workload. We'd treat it as a second phase, with that team in the design meeting and the full destination list written down before the switch. One request flips the mode back, since a PATCH with `update_mask=destinations,traffic_mode` changes both at once.

## Preview limits and billing

The preview limits are generous for a pilot and worth knowing before a design depends on them. An NCC holds at most two gateways, and each gateway takes at most 100 destinations and two DNS resolvers. On the Terraform side, the provider's own page still marks the resource as Private Preview, so we'd pin the provider version the pilot was written against and read the changelog before every upgrade.

Billing for the gateway begins on or after 1 December 2026, according to the [Azure Databricks release notes](https://learn.microsoft.com/en-us/azure/databricks/release-notes/whats-coming#billing-for-private-network-gateway). Microsoft's documentation gives the start date but no rate, so we'd ask the account team for one before promising anybody savings. Then we'd model it against what it replaces, which is the hourly Private Connectivity charge on each private endpoint, the load balancers, and the engineering time to keep a dozen of those stacks working. Every week a pilot runs before 1 December is a week of traffic measured before the gateway bills anything.

## Where it fits poorly

If your security team refuses serverless altogether, a gateway won't change that conversation, and it's a policy question before it's a networking one. If you have two or three sources already working over Private Link, there's little reason to migrate them. If you need every byte, storage included, to cross your own firewall, the service endpoint path for blob storage rules that out. And if the source is in a region outside the preview list, you're waiting regardless.

Databricks' [announcement](https://databricks.com/blog/introducing-private-network-gateway) puts the AWS version in Private Preview through the account team and Google Cloud support still in development, so a multi-cloud estate can't standardise on it yet.

## Our recommendation

Run the pilot in `SPECIFIC_DESTINATIONS` mode with the existing Private Link path left in place, and judge it on two numbers. The first is how many load balancer and Private Link stacks it would retire across your sources, which you can count today. The second is the gateway's first billing line set against those stacks' hourly charges, which you can only read after 1 December. If the first number is three or fewer, we'd keep Private Link and stop there. If it's ten or more and the bill holds up, we'd plan the move to production for when the feature leaves preview.

## Frequently asked questions

### What is the Azure Databricks private network gateway?

It's a Databricks-managed gateway that connects serverless compute to resources in your VNet and transitively connected networks through one delegated subnet. You create it inside a network connectivity configuration, and you don't deploy or patch any gateway machines yourself.

### Does the private network gateway replace Private Link?

No, Microsoft describes it as a complement to Private Link. Private endpoint rules still take priority and remain the recommended path to specific cloud-managed resources such as object storage, while the gateway covers resources in your VNet or a connected network.

### Can serverless reach on-premises systems through it?

Yes, if your VNet already routes to them, for example over ExpressRoute or a VPN. The gateway reaches whatever the delegated subnet can reach, so on-premises firewalls and NSGs have to allow the gateway subnet's address range.

### How much does the private network gateway cost?

There's no gateway charge until billing starts on or after 1 December 2026, though the usual serverless networking charges still apply. Microsoft hasn't published a rate in its documentation, so ask your Databricks account team before you plan around it.