Networking & Cloud Foundations

1.1 · IP Addressing & CIDR

CIDR is the address book. You allocate it once, before any Databricks resource exists, and you size for peak because a subnet's CIDR is frozen the day the workspace deploys. Switch the diagram between the VNet CIDR plan and the node → IP math; click any box for the what + why.

Verified limits & sizing

Illustrative config — sizing is the whole point

resource "azurerm_virtual_network" "adb" {
  address_space = ["10.179.0.0/16"]   # /16 VNet: room for big subnets + a future Private Link subnet
}
resource "azurerm_subnet" "container" {
  address_prefixes = ["10.179.64.0/18"]   # ~16k usable; MUST match host subnet size; CIDR is PERMANENT
  delegation { name = "adb"; service_delegation { name = "Microsoft.Databricks/workspaces" } }
}
# 10.179.128.0/17 left FREE in the /16 — headroom for a /27 Private Link subnet (Stage 4).

Portal: Create a resource → Virtual network → IP addresses (10.179.0.0/16) → + Add subnet twice (host + container, each ≥ /26, non-overlapping).

1.2 · VNets, Subnets & the Cloud Network Model

The VNet is the gated estate you own; subnets are its streets, and they're where every control attaches. A VNet-injected workspace rents two same-sized delegated subnets. Switch between VNet injection and the managed (default) VNet; click any box for the what + why.

Managed VNet vs VNet injection

Illustrative config — the delegated subnet

resource "azurerm_subnet" "host" {
  address_prefixes = ["10.179.0.0/18"]
  delegation {
    name = "adb"
    service_delegation { name = "Microsoft.Databricks/workspaces" }   # hands subnet mgmt to Databricks
  }
}
# Container subnet identical shape, same size, no overlap — runs the Databricks Runtime.

Verify: VNet → Subnets → both show NSG attached and Delegation = Microsoft.Databricks/workspaces.

1.3 · Firewalls, NSGs & Routing

Every packet leaving a cluster passes a bouncer (NSG — whether), a GPS (UDR — where), and a loading dock (NAT — stable way out). Switch the diagram between the three controls; the highlighted arrow shows the active flow. Click any box for the what + why.

NSG vs UDR vs NAT vs Firewall

Illustrative config — force-tunnel WITHOUT blackholing the control plane

resource "azurerm_route" "dep_default" {       # DEP catch-all → Azure Firewall
  address_prefix = "0.0.0.0/0"
  next_hop_type  = "VirtualAppliance"; next_hop_in_ip_address = "10.10.0.4"  # firewall PRIVATE IP
}
resource "azurerm_route" "bypass_adb" {        # WITHOUT this, the control plane is blackholed
  address_prefix = "AzureDatabricks"           # service tag (OMIT if Private Link on)
  next_hop_type  = "Internet"                  # repeat for "Storage" and "EventHub"
}

Portal: route table → Routes → 0.0.0.0/0 → Virtual appliance + bypass routes per service tag (next hop Internet) → associate to both subnets. NAT gateway → assign a Standard public IP (= stable egress IP).

1.4 · DNS, Endpoints & Name Resolution

DNS is the phonebook; a Private DNS Zone is the internal company directory that makes the same name resolve to a private IP. Switch between public resolution and private (Private Link) resolution; click any box for the what + why.

The resolution chain (private deployment)

adb-….azuredatabricks.net                  (URL — UNCHANGED)
   └─ public DNS → CNAME →
adb-….privatelink.azuredatabricks.net      (CNAME into the privatelink zone)
   └─ your Private DNS Zone → A record →
10.10.4.5                                  (PRIVATE IP of the databricks_ui_api endpoint)

Illustrative config — the DNS half of Private Link

resource "azurerm_private_dns_zone" "adb" {
  name = "privatelink.azuredatabricks.net"   # EXACT name or auto-registration won't fire
}
resource "azurerm_private_dns_zone_virtual_network_link" "adb" {
  virtual_network_id = azurerm_virtual_network.adb.id   # without this, the VNet never sees the private A record
}
# Verify from a VM inside the VNet: nslookup adb-….azuredatabricks.net
#   ✓ a 10.x private IP   ✗ a public 20.x/40.x = zone not linked or custom DNS not forwarding

1.5 · Common Network Topologies

Every secure deployment lands in hub-and-spoke: shared services in one central hub, each workload in its own spoke, all routed through the hub. Switch between the generic hub-and-spoke and the Databricks mapping (hub = transit VNet, spoke = workspace VNet); click any box for the what + why.

Topology shapes & on-prem connectivity

Illustrative config — peering with gateway transit

resource "azurerm_virtual_network_peering" "hub_to_spoke" {
  allow_forwarded_traffic = true     # let hub forward spoke-origin traffic
  allow_gateway_transit   = true     # share the hub's on-prem gateway
}
resource "azurerm_virtual_network_peering" "spoke_to_hub" {
  allow_forwarded_traffic = true
  use_remote_gateways     = true     # use hub's VPN/ExpressRoute gateway (must exist first)
}
# Plus a spoke UDR: 0.0.0.0/0 → VirtualAppliance (hub firewall private IP) to force-tunnel egress.

Decision guide — what an architect recommends

FDE field notes — what the network/security team actually asks

Common asks & the answer

What breaks in the field — and the FIRST check

Three questions to ask before designing the network

1. What's the peak node count, and which CIDR block does central IPAM allocate (and does it overlap on-prem/hub)?
2. Is there a regulatory mandate for no public-IP hop / egress inspection, or is backbone-private enough?
3. Is there an existing landing-zone hub and on-prem connectivity (ExpressRoute/VPN) to reuse, or is this a standalone dev VNet?