Azure Landing Zone Blueprint: Build Your Cloud Like LEGO

Published on 2025-05-29 by Mathieu

Azure Landing Zone Blueprint: Build Your Cloud Like LEGO® 🧱

🎯 TL;DR

Treat your landing zone as a box of LEGO bricks: snap on governance and network bricks before you start stacking workloads. This guide maps each CAF pillar to a colour-coded brick so you can build, swap, and scale without knocking over the whole tower.

1️⃣ Why Landing Zones Matter (and Why LEGO?) 🤔

Walk into a kid's room after a LEGO marathon and you'll find two kinds of builders:

Chaos Crafters 🌪️ – everything mashed into a rainbow spaceship that collapses if you sneeze
Blueprint Builders 📐 – colour-sorted bricks, sturdy baseplates, and a clear plan

Cloud environments tend to mirror the first group—resource groups scattered across random subscriptions, no guardrails, duplicated VNETs. Microsoft's Cloud Adoption Framework (CAF) offers the second approach: the landing zone—a governed, repeatable foundation for any workload.

💡 Tip: CAF landing zones are opinionated but modular. Think of them as an IKEA manual that encourages hacking—swap parts to suit enterprise quirks.

2️⃣ The LEGO Colour Key 🎨

CAF Pillar	LEGO Colour	Real-World Analogy
Management	🔵 Dark Blue	The baseplate—everything snaps on here
Networking	🟢 Bright Green	Road plates connecting the city
Identity & Access	🟡 Bright Yellow	Minifigure badges—who can enter where
Policy & Security	🔴 Red	Safety-barrier bricks
Operations	⚫ Light Grey	Control-panel pieces—monitor & repair
Cost Management (FinOps)	🟡 Gold	Rare shiny bricks you guard carefully

We'll add these bricks layer by layer! 🏗️

3️⃣ Foundation Layers 🏗️

3.1 Management Groups & Subscriptions (Dark-Blue Baseplate) 🔵

Create Root → Corp → Region/BU groups (e.g., TPENG-EMEA, TPENG-APAC)
Policy inheritance starts here—define location & SKU allow-lists at the management-group level to avoid whack-a-mole per subscription 🎯
Keep the landing-zone subscription separate from the Shared Services subscription. This isolates core infra from transient workloads

# Terraform: management group example
data "azurerm_client_config" "current" {}
resource "azurerm_management_group" "emea" {
  name         = "TPENG-EMEA"
  display_name = "TP Engineering – EMEA"
  parent_management_group_id = data.azurerm_client_config.current.tenant_id
}

3.2 Subscription Naming & Tagging 🏷️

Element	Convention
Subscription Name	`AZ-SUB-{BU}-{REGION}-{ENV}`
Tag `CostCenter`	Finance GL code
Tag `Confidentiality`	Public, Internal, Restricted

💰 FinOps lens: Tag completeness > 95% is the #1 predictor of accurate chargeback in month 3.

4️⃣ Networking Hub (Bright Green) 🌐

4.1 Choose Your Topology 🗺️

Hub-and-Spoke – central firewall, shared DNS, easy security control
Mesh VNET Peering – low latency East-West, but policy sprawl

⚡ Rule of thumb: If you have more than five VNETs or regulated workloads, pick Hub-and-Spoke.

4.2 Address-Space Planning 📊

Reserve a /16 per region, slice into /24 per workload VNET
Avoid RFC 1918 overlaps with on-prem (e.g., use 10.200.0.0/16 if corp uses 10.0.0.0/8)

module "vnet_hub" {
  source              = "Azure/vnet/azurerm"
  resource_group_name = azurerm_resource_group.network.name
  address_space       = ["10.200.0.0/16"]
  subnets = [
    {
      name           = "AzureFirewallSubnet"
      address_prefix = "10.200.0.0/24"
    },
    {
      name           = "SharedServices"
      address_prefix = "10.200.1.0/24"
    }
  ]
}

4.3 Connectivity Options 🔗

Scenario	Choice	Notes
< 50 Mbps Dev/Test	Site-to-Site VPN	Quick but higher latency
Prod + > 100 Mbps	ExpressRoute	/29 BGP, QoS SLAs
Multi-Cloud	Azure vWAN	Centralise routing + policy

⚠️ Warning: Avoid using both ExpressRoute & VPN concurrently unless you configure forced-tunnel routing—split-brain DNS hell awaits.

5️⃣ Guardrails (Red Bricks) 🔐

5.1 Azure Policy 📋

Deploy AllowedLocations, AllowedSKUs, and InheritTags at the management-group level
Attach a DeployIfNotExists policy for diagnostic settings—auto-onboard new resources to Log Analytics

{
  "mode": "Indexed",
  "parameters": {
    "allowedLocations": {
      "type": "Array",
      "allowedValues": ["westeurope", "uaenorth"],
      "metadata": { "description": "Allowed regions." }
    }
  },
  "policyRule": {
    "if": {
      "not": {
        "field": "location",
        "in": "[parameters('allowedLocations')]"
      }
    },
    "then": { "effect": "Deny" }
  }
}

✅ Success tip: Automate remediation by linking a Logic App that posts exemption links to Slack—the dev team owns the exception story, not you.

5.2 Role-Based Access Control (RBAC) 👥

Use custom roles sparingly; prefer built-ins (Network Contributor, Reader)
Follow least privilege and combine with PIM for time-bound elevation

6️⃣ Operations & Observability (Light Grey) 📊

Layer	Service
Metrics & Logs	Azure Monitor + Log Analytics workspace per region
Dashboards	Grafana integration (native in portal)
Alerts	Action Groups routing to PagerDuty & Teams

Backup & DR 💾 – Recovery Services Vault for VMs/SQL, geo-redundant storage (GRS) for critical blobs
Automation 🤖 – Azure DevOps or GitHub Actions for Terraform; Azure Automation for key rotation

🔒 Tip: Store Terraform state in a Storage Account behind a Private Endpoint to keep state files off the public internet.

7️⃣ FinOps Impact (Gold Bricks) 💰

Landing-zone decisions heavily influence your future cloud bill.

Decision Point	Cost Impact	Mitigation
Too many subscriptions	Idle minimum spend per EA subs	Consolidate Dev/Test into one sub
Unlimited SKUs	Devs choose P* or M-series VMs	`AllowedSKUs` policy + cost alerts
No budget alerts	Overruns unnoticed for 30 days	Budgets + Action Groups to FinOps
Broad VNET peering	Data-egress surprise	Cost-analysis workbook per VNET

💡 FinOps takeaway: Governance ≠ bureaucracy; it's prepaid cost avoidance.

8️⃣ Next Steps 🚀

Download 📥 the 30-point landing-zone checklist PDF
Complete ✅ the checklist as you build your sandbox landing zone
Read 📖 Pillar A2 – Azure Policy Playbook to level up your guardrails - Coming Soon.

📥 Download the Checklist PDF

❓ FAQ

Q: What's the difference between a CAF landing zone and a reference architecture? A: CAF landing zones include governance and operations layers (policy, identity, budgets). Reference architectures often focus solely on workload topology without those guardrails.

Q: Can I retrofit an existing subscription into a landing zone? A: Yes—perform a gap analysis first. Apply policy assignments in audit mode, remediate drift (tags, naming, location), and migrate resources only if network CIDR conflicts arise.

📢 Share & Subscribe

If this blueprint saved you hours (or budget), share it on X/LinkedIn, tag @TalkNerdyTo_Me, and subscribe for weekly cloud memes & deep dives! 🚀

This guide provides a comprehensive, governance-first approach to building production-ready Azure landing zones using the LEGO analogy to make complex concepts more accessible and memorable.

Tags: azure, landing zone, policy