Serverless Networking

5.1 · Serverless architecture & why networking differs

Same control plane; the difference is where the compute lives. Switch the diagram between classic (your VNet) and serverless (Databricks' account) and click any box to see what it is and why the classic controls do — or don't — apply.

Classic vs serverless

Illustrative config — the constructs that replace the classic toolkit

There is nothing to provision for the serverless plane itself. Full builds are 5.2 (NCC) and 5.3 (egress policy).

resource "databricks_mws_network_connectivity_config" "this" {
  name   = "ncc-eastus2-prod"
  region = "eastus2"          # MUST equal the workspace region (serverless plane is co-regional)
}
resource "databricks_mws_ncc_binding" "this" {
  network_connectivity_config_id = databricks_mws_network_connectivity_config.this.id
  workspace_id                   = var.workspace_id   # bind so this workspace's serverless uses it
}

Account Console: Settings → Feature enablement → enable Serverless compute (Premium). Create a SQL Warehouse → Type = Serverless — no VNet/subnet/CIDR is ever requested.

5.2 · Network Connectivity Configuration (NCC)

An account-level, regional object bound to workspaces — the single control point for how serverless reaches your private resources. Switch the diagram between the service-tag (backbone) model and the private-endpoint model; click any box for the "what + why."

Service tag vs private endpoint

Illustrative config — NCC + private endpoint + binding

resource "databricks_mws_network_connectivity_config" "this" {
  name   = "ncc-eastus-bu1"
  region = "eastus"                       # regional object; workspaces must match this region
}
resource "databricks_mws_ncc_private_endpoint_rule" "adls_dfs" {
  network_connectivity_config_id = databricks_mws_network_connectivity_config.this.id
  resource_id                    = azurerm_storage_account.data.id
  group_id                       = "dfs"  # "blob" for blob-path access (e.g. model-serving artifacts)
}
resource "databricks_mws_ncc_binding" "bind" {
  network_connectivity_config_id = databricks_mws_network_connectivity_config.this.id
  workspace_id                   = var.workspace_id   # ≤ 50 workspaces per NCC, same region
}

Account Console: Security → Network connectivity configurations → Add → bind to workspace (wait ~10 min + restart serverless). Private endpoint rule → status PENDING → approve on the storage account (Networking → Private endpoint connections) → refresh until ESTABLISHED.

5.3 · Serverless egress control / network policies

The deny-by-default egress firewall for the serverless plane. Switch the diagram between Full access (open, with optional block-list) and Restricted access (deny-by-default); click a box to see what is allowed, what is denied, and why.

Illustrative config — deny-by-default + audit

resource "databricks_account_network_policy" "restricted" {
  network_policy_id = "serverless-restricted"
  egress = {
    network_access = {
      restriction_mode = "RESTRICTED_ACCESS"   # deny-by-default; FULL_ACCESS = open
      allowed_internet_destinations = [
        { destination = "partner-api.example.com", internet_destination_type = "DNS_NAME" }
      ]                                          # max 100 FQDNs; 2,500 total destinations
      allowed_storage_destinations = [
        { azure_storage_account = "mydatalake", azure_storage_service = "dfs" }
      ]
    }
  }
}

-- Audit what got denied (or would have, in dry-run):
SELECT event_time, workspace_id, access_type, network_source_type, destination
FROM system.access.outbound_network
WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
ORDER BY event_time DESC;
-- access_type = 'DROP' = blocked;  'DRY_RUN_DENIAL' = would have been blocked.

Account Console: Security → Networking → Context-based ingress & egress control → Egress → Restricted access → add Allowed domains / storage → (optional) dry-run → assign to workspace. Account-level APIs need an OAuth token (PATs rejected). Block internet destinations is REST-API-only and in Public Preview.

5.4 · Serverless storage access patterns

Three ways to a firewalled ADLS Gen2, least → most locked-down — plus the separate auth layer. Switch the diagram between the three patterns; click any box for the "what + why." Remember: two locks — network reachability AND authorization.

The three patterns side by side

Illustrative config — service tag (NSP) + the auth layer

// Bicep — allow serverless (service tag) into a firewalled ADLS Gen2 via NSP.
resource inbound 'Microsoft.Network/networkSecurityPerimeters/profiles/accessRules@2023-08-01-preview' = {
  name: '${nspName}/${profileName}/allow-databricks-serverless'
  properties: {
    direction: 'Inbound'
    addressPrefixes: []
    serviceTags: [ 'AzureDatabricksServerless.${region}' ]   // regional tag limits exposure
  }
}

-- Authorization (all three patterns): wrap the managed identity, govern with UC grants.
CREATE STORAGE CREDENTIAL adls_cred
  WITH AZURE_MANAGED_IDENTITY ( ACCESS_CONNECTOR_ID = '/subscriptions/.../accessConnectors/adb-connector' );
CREATE EXTERNAL LOCATION data_lake
  URL 'abfss://raw@myadls.dfs.core.windows.net/' WITH (STORAGE CREDENTIAL adls_cred);
GRANT READ FILES ON EXTERNAL LOCATION data_lake TO `data-eng`;

Decision guide — what an architect recommends

Customer Q&A — what the security team actually asks

Common asks & the answer

What breaks in the field — and the FIRST check

Three questions to ask before recommending an architecture

1. Is there a regulatory mandate for Private Link / no public path, or is backbone-private (service tag) enough?
2. Do you need deny-by-default exfiltration control on serverless — and are you ready to dry-run it first?
3. Are you on Premium, and are workspace, serverless plane, and storage all co-regional?