Azure Landing Zone Design: Hub-Spoke Topology, Governance, and Policy-Driven Compliance

An Azure landing zone is a pre-configured, governed environment that provides the networking, identity, security, and management foundations for workload subscriptions. It encodes your organisation's standards so that every new workload inherits them by default rather than requiring individual configuration. Getting the landing zone right at the start is one of the highest-leverage investments in cloud adoption — retrofitting governance onto an ungoverned Azure environment is significantly more expensive and disruptive than building it in from day one.

Management Group Hierarchy

Management groups sit above subscriptions in the Azure hierarchy and are the primary mechanism for applying governance at scale. A typical enterprise hierarchy looks like this:

Tenant Root Group
└── Contoso (Intermediate Root MG)
    ├── Platform
    │   ├── Management       (Log Analytics, Defender, automation)
    │   ├── Connectivity     (Hub VNet, ExpressRoute/VPN, DNS, Firewall)
    │   └── Identity         (AD DS domain controllers, PIM)
    └── Landing Zones
        ├── Corp             (connected to hub, internal workloads)
        │   ├── Production subscription
        │   └── Non-production subscription
        └── Online           (internet-facing, no hub connectivity required)

Azure Policy and RBAC assignments at a management group level inherit down to all child subscriptions. This means you apply a policy once at the Landing Zones MG level and it automatically covers every workload subscription beneath it — including ones created in the future.

Hub-Spoke Network Topology

The hub-spoke model places shared network services (firewall, DNS, VPN/ExpressRoute gateway, Bastion) in a central hub VNet. Spoke VNets (one per workload or environment) peer to the hub. Traffic between spokes must traverse the hub, allowing the central firewall to inspect and control east-west traffic.

Key design decisions:

• Non-overlapping RFC-1918 address space — plan the entire VNet address plan upfront. Overlapping address space in spoke VNets cannot be corrected without redeployment. Common approach: allocate /16 per region, subdivide into /24s for spokes.
• Azure Firewall vs NVA — Azure Firewall (Premium SKU) provides IDPS, TLS inspection, and URL filtering without managing VM scale sets. Third-party NVAs (Palo Alto, Fortinet) offer more granular policy control but require operational overhead. Azure Firewall is the right default for most organisations.
• Private DNS zones — link private DNS zones (privatelink.blob.core.windows.net, etc.) to the hub VNet so that private endpoint name resolution works from all spokes via the single DNS resolver in the hub.
• VNet peering vs Virtual WAN — for environments with more than 5–10 spokes or multi-region connectivity, Azure Virtual WAN provides automated routing and global mesh connectivity that's difficult to replicate with manual VNet peering.

Azure Policy: Governance as Code

Azure Policy evaluates resources against defined rules and either denies non-compliant deployments or remediates existing non-compliant resources. Key built-in initiatives to apply:

• Microsoft Cloud Security Benchmark (MCSB) — maps to CIS controls, NIST, and ISO 27001. Apply in audit mode first to establish a baseline compliance score, then switch to deny for the most critical controls.
• Allowed locations — restrict resource deployment to your chosen Azure regions, preventing accidental deployment outside your data-sovereignty boundary.
• Require tags — enforce tagging (CostCenter, Environment, Owner) on all resource groups at creation. Retroactively enforceable via DeployIfNotExists policies with managed identity remediation tasks.
• Network guardrails — deny creation of resources with public IP addresses in subscriptions designated as internal-only; deny NSGs that allow inbound 22/3389 from 0.0.0.0/0.

Subscription Vending

At scale, new subscriptions should be provisioned via an automated "vending machine" pattern — typically a Terraform module or Bicep template triggered by a service request that creates the subscription, places it in the correct management group, peers the VNet to the hub, applies required Policy assignments, and notifies the workload team. Manual subscription setup doesn't scale and leads to inconsistency.

Defender for Cloud: Security Posture Management

Enable Microsoft Defender for Cloud at the Management MG level so it automatically covers every subscription. Set the email notifications and configure integration with Sentinel for alert ingestion. The Regulatory Compliance dashboard gives you a continuously updated view of your posture against selected frameworks (PCI-DSS, ISO 27001, SOC 2).

Identity: Entra ID Roles and Managed Identities

• Avoid standing Owner/Contributor assignments on subscriptions. Use Privileged Identity Management (PIM) with eligible assignments and approval workflows.
• Use managed identities for Azure resources (VMs, Functions, Logic Apps) that need to authenticate to other Azure services. Eliminates the need to store credentials in code or Key Vault for inter-service auth.
• Assign RBAC at the subscription level via security groups synced from on-premises AD (or Entra ID-native groups). Individual user assignments don't scale.

"A landing zone is not something you build once. It evolves with your organisation. Start with the minimum viable landing zone and add governance incrementally — but get the management group hierarchy and network topology right on day one, because those are the hardest to change."

Sripadatech designs and implements Azure landing zones aligned to the Microsoft Cloud Adoption Framework. Contact us to discuss your cloud foundation.