Azure networking baseline: secure landing zone foundation

Why networking is the landing zone multiplier

• Connectivity decisions touch every workload, so bad ones scale faster than any policy.
• DNS and Private Endpoint ownership determines whether data services stay available.
• Egress and firewall controls are where real risk and cost live; without standards every team builds their own.
• A consistent network makes subscription vending predictable: NSGs, diagnostics, and routes arrive already compliant.

What good looks like

• One hub per region (or vWAN hub) owned by the platform team, with well-known subnets, firewall/NAT, and DNS resolvers.
• Private DNS zones centralised, linked via automation, with platform ownership and change control.
• Policy guardrails that block public exposure, force NSG baselines, and link spokes to approved hubs.
• Subscription vending that wires new spokes to the right hub, assigns NSG baselines, and ensures diagnostics are enabled.
• Operational runbooks for private endpoint onboarding, egress change requests, and incident response.

Baseline decision points

1. Topology – Hub/spoke is simpler and suits most estates; vWAN only when you truly need global managed transit. Pick one and stick to it.
2. IP plan – Reserve blocks per region, per environment, and per hub. Avoid overlaps if you have hybrid aspirations.
3. DNS ownership – Decide where private zones live, who approves record changes, and how resolver rules are deployed.
4. Egress strategy – NAT Gateway for simple outbound, Azure Firewall when you need filtering/logging, proxy only if compliance forces it.
5. Inbound pattern – Front Door or Application Gateway with WAF; no ad-hoc public IPs.
6. Segmentation – Subscriptions, VNets, NSGs. Decide how prod vs non-prod are separated and who can create virtual networks.
7. Logging + monitoring – VNet flow logs, Azure Firewall logs, DNS logs all land in a central workspace with retention defined.

Signal vs noise

• Enable now: Controlled egress, NSG baselines, DNS logging, Azure Firewall logging, DDoS Network Protection on vNets with public-facing endpoints (if someone owns the alerts and the cost).
• Enable later (Day 30): Micro-segmentation policies, DDoS protection for the rest of the estate, Front Door Premium everywhere—only after Day 0 telemetry is stable.
• Maybe never: Full IDS/IPS on every workload subnet without owners, enabling every firewall SKU “for completeness,” or multi-layer proxies when a single firewall would do. Every log without an incident playbook is noise.

Phased rollout

• Day 0 baseline – Deploy regional hubs, NAT/firewall, DNS resolver, Private DNS zones, telemetry routing, and guardrail policies. Onboard a pilot workload.
• Day 30 hardening – Promote audit policies to deny, enable traffic analytics, integrate firewall alerts with SOC tooling, and validate DNS/Private Endpoint processes.
• Quarterly review – Run VNet flow-log reviews, check Private Endpoint inventory vs DNS zones, renew firewall policies, and prune unused VNets/subscriptions.

Topology trade-offs

• Hub/spoke – Great for single/few regions, centralised control, and simpler routing. Works well for most landing zones.
• vWAN – Use only if you need multiple regions/branches, dynamic routing to SD-WAN/ExpressRoute, or simplified global connectivity.

Runbook: secure networking baseline

Before you wire the vending pipeline, lay out the hub using Terraform. Swap the address prefixes, resource group, and firewall SKU for your estate.

resource "azurerm_resource_group" "hub" {
  name     = "rg-network-hub-uks"
  location = "uksouth"
}

resource "azurerm_virtual_network" "hub" {
  name                = "vnet-hub-uks"
  address_space       = ["10.100.0.0/16"]
  location            = azurerm_resource_group.hub.location
  resource_group_name = azurerm_resource_group.hub.name
}

# The name must be exactly AzureFirewallSubnet, and /26 is the minimum Azure
# accepts. Smaller and the deployment fails late.
resource "azurerm_subnet" "firewall" {
  name                 = "AzureFirewallSubnet"
  resource_group_name  = azurerm_resource_group.hub.name
  virtual_network_name = azurerm_virtual_network.hub.name
  address_prefixes     = ["10.100.1.0/26"]
}

# Azure Firewall requires a Standard SKU, statically allocated public IP.
resource "azurerm_public_ip" "fw" {
  name                = "pip-fw-hub-uks"
  location            = azurerm_resource_group.hub.location
  resource_group_name = azurerm_resource_group.hub.name
  allocation_method   = "Static"
  sku                 = "Standard"
  zones               = ["1", "2", "3"]
}

resource "azurerm_firewall" "hub" {
  name                = "fw-hub-uks"
  location            = azurerm_resource_group.hub.location
  resource_group_name = azurerm_resource_group.hub.name
  sku_name            = "AZFW_VNet"
  sku_tier            = "Standard"
  ip_configuration {
    name                 = "fw-ipconfig"
    subnet_id            = azurerm_subnet.firewall.id
    public_ip_address_id = azurerm_public_ip.fw.id
  }
}

Policy guardrails

Use Bicep to enforce that all spokes peer to the approved hub and use standard route tables. Update the policy definition IDs for your environment.

targetScope = 'managementGroup'

@description('Region for the assignment identity. Not where policy applies.')
param location string = 'uksouth'

// Resolve real definition IDs first, e.g.:
//   az policy definition list --query "[?contains(displayName,'<search term>')].{name:displayName,id:id}" -o table
resource initiative 'Microsoft.Authorization/policySetDefinitions@2023-04-01' = {
  name: 'alz-network-guardrails'
  properties: {
    displayName: 'Landing Zone Network Guardrails'
    description: 'Force spokes to peer to approved hubs and send diagnostics.'
    policyType: 'Custom'
    policyDefinitions: [
      {
        policyDefinitionReferenceId: 'require-hub-peering'
        policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/<require-hub-peering-id>'
      }
      {
        policyDefinitionReferenceId: 'deploy-nsg-diagnostics'
        policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/<deploy-nsg-diagnostics-id>'
      }
    ]
  }
}

resource assignment 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
  name: 'alz-network-guardrails'
  // Required: the initiative contains a deployIfNotExists effect, which cannot
  // remediate without an identity that holds rights at the assigned scope.
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    displayName: 'Landing Zone Network Guardrails'
    policyDefinitionId: initiative.id
  }
}

resource remediationRights 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(managementGroup().id, assignment.id, 'Contributor')
  properties: {
    // Contributor — narrow this to the least-privileged role your definitions need.
    roleDefinitionId: tenantResourceId(
      'Microsoft.Authorization/roleDefinitions',
      'b24988ac-6180-42a0-ab88-20f7382dd24c'
    )
    principalId: assignment.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

Validation checks

Audit routing, DNS and flow logs regularly. This finds VNet flow log targets that were producing records and have stopped. Take the last timestamp per target first, then test it, because a target that went silent has no rows left to filter on. It needs Traffic Analytics enabled on the VNet flow logs, which write to NTANetAnalytics. That table replaces AzureNetworkAnalytics_CL, which NSG flow logs used, so update any saved queries and workbooks.

NTANetAnalytics
| where SubType == "FlowLog"
| summarize lastSeen = max(TimeGenerated) by TargetResourceId, TargetResourceType
| where lastSeen < ago(1d)
| order by lastSeen asc

Flow logs being configured is a separate question from flow logs arriving, and a vNet that never had them on won’t show up above. VNet flow logs can target a vNet, a subnet or a NIC, so check coverage per vNet in Azure Resource Graph. This lists vNets with no enabled vNet-level flow log, and counts any subnet-level ones so you can tell “partial” from “none”. NIC-level flow logs aren’t counted.

resources
| where type =~ 'microsoft.network/virtualnetworks'
| project vnetId = tolower(id), vnetName = name, resourceGroup, subscriptionId
| join kind=leftouter (
    resources
    | where type =~ 'microsoft.network/networkwatchers/flowlogs'
    | where tobool(properties.enabled)
    | extend targetId = tolower(tostring(properties.targetResourceId))
    | where targetId contains '/providers/microsoft.network/virtualnetworks/'
    | extend vnetId = tostring(split(targetId, '/subnets/')[0])
    | summarize vnetLevel = countif(targetId == vnetId),
                subnetLevel = countif(targetId != vnetId) by vnetId
  ) on vnetId
| where isnull(vnetLevel) or vnetLevel == 0
| project subscriptionId, resourceGroup, vnetName,
          subnetFlowLogs = coalesce(subnetLevel, 0)

Common pitfalls

Rollback / back-out plan

• Failed policy rollout – Disable the specific assignment, not the entire initiative. Fix definition parameters, re-run on a pilot subscription, then reapply.
• Firewall change gone wrong – Revert the IaC change, redeploy the previous version, and document the blocked traffic. Keep last-known-good configs in source control.
• DNS misconfiguration – Remove the faulty Private Endpoint link, flush caches, and validate before re-linking. Document the change window to avoid surprise outages.
• Spoke onboarding failure – Move the subscription to a quarantine management group, delete partially created VNets, and rerun the pipeline after the fix.

Networking baselines succeed when they are boring to operate. Make decisions once, automate them ruthlessly, collect the logs, and review them often.