Cloud Landing Zone Design: Network, Security and Governance Foundation

What a Landing Zone Is and Why It's Built First

A landing zone is the pre-configured cloud environment that workloads deploy into. It includes: network architecture (VNets, subnets, connectivity), identity integration (Entra ID, RBAC, Conditional Access), security baseline (NSGs, firewall, Defender), governance policies (Azure Policy, naming, tagging), monitoring infrastructure (Log Analytics, alerts, dashboards), and subscription structure (management groups, subscription segmentation). Building the landing zone first — before migrating or deploying any workload — ensures every workload benefits from enterprise-grade infrastructure from day one.

Organizations that skip the landing zone deploy workloads into ad hoc environments: each team creates their own VNet (network sprawl), configures their own security (inconsistent posture), and names resources arbitrarily (ungovernable chaos). Retrofitting governance onto 200 already-deployed workloads costs 5-10x more than building the landing zone correctly upfront.

Landing Zone Components: The 7 Foundations

Foundation 1: Network Topology — Hub-and-Spoke

The hub-and-spoke network topology is the standard for enterprise Azure deployments. The hub VNet contains shared services: Azure Firewall (centralized network security), VPN/ExpressRoute gateway (on-premises connectivity), DNS forwarders (name resolution across environments), and shared monitoring agents. Spoke VNets contain workloads — each spoke is an isolated network peered to the hub for shared service access. Spoke-to-spoke communication routes through the hub firewall, ensuring all traffic is inspected.

Network design principles: Each workload gets its own spoke VNet (isolation by default). Subnets within spokes separate tiers (web, API, database). NSGs on every subnet enforce layer-specific access rules. Private Endpoints eliminate public internet exposure for PaaS services. The hub firewall inspects and logs all outbound internet traffic — no workload accesses the internet directly.

IP Address Planning

Plan IP ranges before deployment — changing IP ranges after workloads deploy requires downtime. Allocate: /16 for the overall environment (65,536 addresses), /22-/24 per spoke (256-1,024 addresses per workload), /24-/26 per subnet (64-256 addresses per tier). Leave gaps between ranges for future expansion. Avoid RFC 1918 ranges already used on-premises — overlapping ranges break VPN/ExpressRoute connectivity.

Foundation 2: Identity and Access Management

Centralized identity means every cloud resource authenticates through Entra ID — no local accounts, no shared passwords, no service-specific identity stores. Implementation: Entra ID Connect synchronizes on-premises AD to Entra ID (hybrid identity for organizations with on-premises AD). Conditional Access policies enforce MFA, device compliance, and location restrictions for all cloud access. Privileged Identity Management converts standing admin access to just-in-time elevation. Azure RBAC assigns permissions at the management group, subscription, resource group, or resource level — following least-privilege principles (minimum permissions for each role).

Service identity: Applications authenticate to Azure services using Managed Identity — not connection strings, not API keys, not shared secrets stored in config files. Managed Identity provides: automatic credential rotation (no expired secrets), no credentials in code (nothing to leak), and audit trail (every service-to-service authentication is logged). For every new application, the question is "does it use Managed Identity?" If not, fix it before deployment.

Foundation 3: Security Baseline

The security baseline defines the minimum security configuration applied to every resource — regardless of which team deploys it. Azure Policy enforces the baseline automatically: encryption at rest enabled on all storage (deny creation without encryption), public network access disabled on all PaaS services (deny creation with public endpoint), diagnostic settings enabled on all resources (deny creation without logging), and TLS 1.2+ enforced on all endpoints (deny configuration below TLS 1.2). The baseline is non-negotiable — no team can deploy a resource that violates it, because Azure Policy prevents the deployment from succeeding.

Microsoft Defender for Cloud provides continuous security posture assessment. Secure Score (0-100) quantifies the landing zone's security posture. Each recommendation includes: the security risk, the remediation steps, and the Secure Score impact. Start with the recommendations that add the most points — they represent the highest-impact security improvements. Target: Secure Score 80+ within 30 days of landing zone deployment.

Foundation 4: Governance and Policy

Naming convention: Every resource follows a standardized naming pattern: [resource-type]-[workload]-[environment]-[region]-[instance]. Example: vm-orderapi-prod-eastus-001. Consistent naming enables: identification (what is this resource?), grouping (which workload does it belong to?), and automation (scripts can parse names to determine environment and region).

Tagging strategy: Every resource tagged with: Environment (prod/dev/test), CostCenter (department budget code), Owner (team responsible), Application (workload name), and DataClassification (public/internal/confidential/restricted). Azure Policy denies resource creation without required tags. Tags enable: cost allocation (which department pays?), security classification (which resources need enhanced protection?), and lifecycle management (who approves decommission?).

Azure Policy enforcement: Policies applied at the management group level cascade to all subscriptions and resources. Categories: security policies (encryption, network access), compliance policies (logging, data residency), cost policies (allowed VM sizes, region restrictions), and operational policies (required tags, naming conventions). Policy runs continuously — new resources evaluated at creation, existing resources evaluated on schedule. Non-compliant resources are flagged, auto-remediated, or denied depending on the policy effect.

Foundation 5: Management and Monitoring

Centralized monitoring through Azure Monitor and Log Analytics. Every resource sends diagnostic logs and metrics to a central Log Analytics workspace. Dashboards show: resource health across the entire environment, cost trends and anomalies, security alerts and posture changes, and performance metrics for key workloads. Alert rules trigger notifications and automated responses for: resource failures, security events, budget threshold breaches, and performance degradation. The monitoring foundation is deployed in the landing zone before any workload — so the first workload has monitoring from minute one.

Foundation 6: Subscription Design

Subscriptions provide logical boundaries for: billing (each subscription has independent cost tracking), access control (RBAC applied at subscription scope), policy application (different policies for prod vs. dev), and blast radius (a misconfiguration in one subscription doesn't affect others).

Subscription Segmentation Model

Management groups organize subscriptions hierarchically: Root → Platform (Connectivity, Identity, Management) + Workloads (Production, Non-Production, Sandbox). Policies applied at the Workloads management group cascade to all workload subscriptions. This hierarchy provides governance at scale — adding a new workload subscription inherits all policies automatically.

Foundation 7: Deployment Automation (IaC)

The landing zone itself is deployed through Infrastructure as Code — Terraform or Azure Bicep. Every component (VNets, policies, RBAC assignments, monitoring configuration) is defined in code, version-controlled in Git, and deployed through CI/CD pipelines. Benefits: the landing zone is repeatable (deploy identical environments for test/staging/disaster recovery), auditable (every change tracked in Git with who, what, when), and recoverable (rebuild the entire landing zone from code if needed).

Terraform vs. Bicep: For Azure-only environments, Bicep provides native integration (first-party, no state file management, direct ARM compilation). For multi-cloud or organizations with existing Terraform expertise, Terraform provides platform-agnostic IaC with a large provider ecosystem. The choice follows team skills and multi-cloud requirements — both produce equivalent results for Azure landing zones.

Azure Landing Zone Accelerator

Microsoft provides the Azure Landing Zone Accelerator — pre-built reference architectures that implement the 7 foundations. The accelerator includes: Terraform and Bicep modules for all components, policy definitions for enterprise governance, network topology templates (hub-and-spoke or Virtual WAN), and RBAC assignment templates. The accelerator provides a starting point that's customized to your requirements — not a one-size-fits-all template. Customization areas: IP ranges, policy strictness, subscription structure, and on-premises connectivity configuration. Deployment time with the accelerator: 2-3 weeks for the foundation, compared to 6-8 weeks building from scratch.

Landing Zone Anti-Patterns

Three anti-patterns that undermine landing zone investments: The "one subscription for everything" anti-pattern — all workloads in a single subscription. No isolation, no blast radius containment, no granular cost tracking. When (not if) a misconfiguration occurs, it affects every workload. Fix: subscription segmentation per the model above. The "governance later" anti-pattern — deploy workloads first, add governance after. By the time governance arrives, 200 resources exist with inconsistent naming, no tags, and conflicting NSG rules. Retrofitting governance costs 5-10x more than building it first. Fix: landing zone before any workload. The "copy the template" anti-pattern — deploy Microsoft's reference architecture without customization. The reference architecture assumes generic requirements. Your organization has specific: IP ranges (must not conflict with on-premises), policy requirements (industry-specific compliance), and connectivity needs (specific VPN/ExpressRoute configuration). Fix: customize the accelerator, don't copy it.

Landing Zone Governance Automation

Azure Policy at the management group level enforces governance continuously. Essential policies to deploy in week 1: deny public IP on VMs (prevent internet exposure), deny storage accounts without encryption (data protection), require tags on all resources (cost and ownership tracking), audit resources without diagnostic settings (monitoring completeness), and restrict allowed VM SKUs (cost control). These policies apply to every resource in every subscription under the management group — existing resources are audited, new resources are denied or auto-remediated. The policy deployment is included in the landing zone IaC — governance is code, not documentation.

Go Deeper

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