Why Landing Zones: The Cost of Organic Growth

Organic Azure growth: Team A creates a subscription, deploys VMs, exposes them to the internet. Team B creates a subscription with a different naming convention, different network configuration, and different security settings. Team C uses Team A's subscription (because getting a new subscription takes 3 weeks through IT). After 18 months: 50 subscriptions with inconsistent configuration, 200 VMs (40 abandoned but still running at $30K/month), 15 public IP addresses (3 with no firewall rules), no centralized monitoring (each team uses different tools), and a cloud bill that nobody can explain. Landing zones prevent this by establishing: standardized architecture before workloads deploy, centralized governance that applies to every subscription, and visibility into all resources through unified monitoring.

Cloud Adoption Framework: Azure's Architecture Blueprint

Microsoft's Cloud Adoption Framework (CAF) provides the methodology: Strategy (business justification and expected outcomes), Plan (cloud adoption plan, digital estate assessment), Ready (landing zone deployment — the architecture foundation), Adopt (migrate existing workloads + innovate with cloud-native), and Govern + Manage (ongoing governance, operations, and optimization). The landing zone is the "Ready" phase — the technical foundation that the Adopt phase builds upon. Skipping Ready and jumping to Adopt produces the organic growth disaster described above.

Landing Zone Design Areas: 8 Pillars

Design Area 1: Identity and Access

Identity is the security perimeter in cloud: Entra ID as the identity provider (all Azure access through Entra ID — no local accounts, no shared credentials), RBAC with least privilege (each user/service gets the minimum permissions needed — Reader for viewers, Contributor for deployers, Owner only for subscription management), PIM for elevated access (Owner and Contributor roles are just-in-time — request elevation, provide justification, auto-expire after 4-8 hours), Conditional Access (MFA required from untrusted networks, managed devices required for production access, risk-based policies that block suspicious sign-ins), and service principals for automation (CI/CD pipelines, automation scripts, and applications use managed identities or service principals — never user credentials).

Design Area 2: Network Topology

Hub-spoke topology: Hub VNet contains shared services (firewall, VPN gateway, DNS, bastion host). Spoke VNets contain workloads (App spoke, Data spoke, Dev spoke). All spoke traffic routes through the hub — centralized inspection and control. Hub-to-spoke: VNet peering (low latency, high bandwidth). Spoke-to-spoke: through the hub firewall (inspected). On-premises connectivity: ExpressRoute (dedicated circuit) or VPN (internet-based). Internet egress: through Azure Firewall in the hub (centralized logging and policy enforcement — no direct internet access from spoke resources).

Design Area 3: Governance and Compliance

Azure Policy enforces governance automatically: required tags (every resource must have: CostCenter, Environment, Owner, Application — resources without tags are non-compliant and optionally blocked from creation), allowed regions (resources can only deploy to approved regions — data residency compliance without manual review), allowed VM sizes (prevent deployment of expensive GPU VMs in development subscriptions), required encryption (storage accounts must use encryption, SQL databases must use TDE), and network restrictions (public IP assignment denied on production resources, storage accounts must use private endpoints). Policies apply at the management group level — every subscription inherits governance automatically. No manual enforcement, no compliance drift.

Design Area 4: Security

Security baseline: Defender for Cloud (continuous security posture assessment — Secure Score 0-100 with remediation recommendations), Microsoft Sentinel (SIEM — centralized security event collection, threat detection with AI, automated incident response), Azure Firewall (network traffic inspection — allow/deny rules, threat intelligence-based filtering, TLS inspection), DDoS Protection (Standard tier on all public-facing resources — automatic mitigation), and Key Vault (centralized secrets management — connection strings, certificates, API keys stored in Key Vault, never in code or configuration files).

Design Area 5: Management and Monitoring

Azure Monitor + Log Analytics: Centralized monitoring across all subscriptions. Resource metrics (CPU, memory, storage, network), application logs (errors, performance, transactions), and security events — all flowing to a single Log Analytics workspace. Dashboards in Power BI or Azure Workbooks for: executive visibility (cost, resource count, compliance score), operational visibility (performance metrics, error rates, availability), and security visibility (threat detections, compliance status, vulnerability count). Alerting: Resource health alerts (VM down → page on-call), performance alerts (database DTU above 80% for 30 minutes → auto-scale or alert), cost alerts (daily spend exceeds 120% of average → alert finance team), and security alerts (Defender detects threat → create Sentinel incident → auto-assign to security team).

Subscription Organization: Management Groups

Management group hierarchy: Root → Platform (shared services, connectivity, identity) + Workloads (Production, Non-Production). Under Production: by business unit or application type. Under Non-Production: Development, Staging, Sandbox. Policies applied at each level: Root (company-wide: required tags, allowed regions), Platform (network policies, identity policies), Production (security policies, encryption requirements, audit logging), Non-Production (relaxed policies, cost controls, auto-shutdown for VMs). Subscription vending: automated process for creating new subscriptions — request submitted → approval → subscription created with: correct management group placement, inherited policies, network peering to hub, monitoring configured, and RBAC assigned. Time: 30 minutes (automated) vs 3 weeks (manual ticketing process).

Implementation: Azure Landing Zone Accelerator

Landing Zone Anti-Patterns: What Not to Do

Five anti-patterns: 1. Skip the landing zone (governance later never comes — by then: 200 unmanaged resources and a remediation project costing 3x what the landing zone would have). 2. Over-engineer on day one (deploying Virtual WAN, Firewall Premium, and Sentinel for 20 resources — governance infrastructure costs more than workloads). 3. Manual configuration (portal clicking is not reproducible, auditable, or scalable — Infrastructure as Code from day one). 4. Flat subscription model (everything in one subscription — no isolation, no cost attribution, no blast radius containment). 5. Ignore naming conventions (rg-1, vm-test, storage123 — unidentifiable at 500 resources. Use convention: resourcetype-workload-environment-region-instance).

Landing Zone Cost: Investment vs Prevention

Landing zone deployment: 4-6 weeks, $50-100K. What it prevents: security remediation ($100-200K for fixing 200 inconsistent resources), cost waste ($50-200K/year in abandoned resources), compliance failure ($100K+ remediation plus business impact), and operational firefighting ($100-200K/year in lost engineering productivity managing cloud chaos). The $50-100K investment prevents $400-700K in remediation and waste over 24 months. ROI: 4-7x.

Subscription Vending: Automating the New Workload Process

Without automation: requesting a new Azure subscription involves: IT ticket, approval chain (3-5 approvers), manual creation in the portal, manual policy assignment, manual network peering, manual monitoring configuration — total: 2-4 weeks. With subscription vending automation: developer submits request through a self-service portal (or Git pull request) specifying: workload name, environment (dev/staging/prod), cost center, and owner. Automation pipeline: creates subscription under the correct management group, assigns RBAC (requestor gets Contributor, team gets Reader), applies policies (inherited from management group plus workload-specific), peers network to hub VNet, configures diagnostics (Log Analytics workspace), creates resource groups with naming convention, and notifies the requestor. Total: 15-30 minutes, zero manual steps. Subscription vending is the capability that transforms the landing zone from an architecture diagram into a self-service cloud platform. Without it: the landing zone is correct but slow — developers wait weeks for infrastructure, creating shadow IT pressure. With it: the landing zone is correct AND fast — developers get governed infrastructure in minutes.

Compliance Frameworks on Azure Landing Zones

The landing zone adapts to compliance requirements: SOC 2 (add: continuous monitoring via Defender for Cloud, access review via Entra ID, change management via Azure DevOps, incident management via Sentinel), HIPAA (add: BAA with Microsoft, encryption at rest with customer-managed keys, audit logging retention 6+ years, data classification via Purview), PCI-DSS (add: network segmentation for cardholder data environment, WAF for web applications, penetration testing schedule, encryption for data in transit and at rest), and ISO 27001 (add: information security management system documentation, risk assessment, control mapping, internal audit schedule). Each compliance framework adds: specific Azure Policy assignments, monitoring requirements, and documentation. The landing zone architecture supports all frameworks — compliance is additive configuration, not architectural redesign.

Go Deeper

Continue building your understanding with these related resources from our consulting practice.