Conceptual Overview

Understanding why Azure Landing Zones exist and what problems they solve.

The Problem: Cloud at Scale is Hard

When organizations adopt Azure without a structured approach:

Common symptoms:

• Every team creates resources differently
• IP address conflicts between VNets
• No centralized logging or monitoring
• Security policies applied inconsistently
• Shadow IT and ungoverned resources
• Lengthy subscription provisioning (weeks!)
• No clear ownership model

The Solution: Azure Landing Zone

An Azure Landing Zone provides a standardized, repeatable foundation for hosting workloads:

Two Types of Landing Zones

Platform Landing Zones

Owned by: Platform/Central IT Team

Provide shared services that application landing zones consume:

Platform LZ	Purpose
Identity	Azure AD, domain controllers, Entra ID Connect
Connectivity	Hub network, ExpressRoute, Firewall, DNS
Management	Log Analytics, Automation, Backup vaults

Application Landing Zones

Owned by: Application/Workload Teams

Where actual business workloads run:

Application LZ	Purpose
Corp	Internal applications (connected to hub)
Online	Public-facing applications (internet ingress)
Sandbox	Development, testing, experimentation

Core Concepts

1. Management Group Hierarchy

Azure Management Groups create a governance hierarchy above subscriptions:

Tenant Root Group
├── Platform
│   ├── Identity
│   ├── Management
│   └── Connectivity
├── Landing Zones
│   ├── Corp
│   └── Online
├── Sandboxes
└── Decommissioned

Why it matters:

• Policies applied at a management group inherit to all child subscriptions
• RBAC assignments flow down the hierarchy
• Enables governance at scale without per-subscription configuration

2. Subscription as Unit of Scale

In Landing Zone architecture, a subscription is:

• The blast radius boundary
• The billing boundary
• The access control boundary
• The quota boundary

Key insight: Don't put multiple unrelated workloads in one subscription. Use subscriptions liberally!

3. Policy-Driven Governance

Instead of relying on tribal knowledge or manual reviews:

Policy effects:

• Deny - Block non-compliant deployments
• Audit - Allow but flag for review
• Modify - Auto-fix configuration
• DeployIfNotExists - Auto-deploy required resources

4. Network Topology Options

Two primary patterns for enterprise connectivity:

Hub-Spoke (Traditional)

Best for:

• Traditional hub-and-spoke networks
• Granular traffic control with Azure Firewall
• Smaller deployments (< 200 spokes)

Virtual WAN

Best for:

• Many branch offices
• Global deployments
• Simplified connectivity management

• 200 VNets

Design Principles

1. Subscription Democratization

Traditional Approach	Landing Zone Approach
Central team provisions everything	Self-service with guardrails
Weeks of lead time	Minutes to provision
Manual reviews	Automated policy checks
Bottleneck on platform team	Distributed ownership

2. Policy-Driven Governance

Shift-left compliance:

• Policies prevent misconfigurations at deployment time
• No more "audit and remediate" cycles
• Developers get immediate feedback

3. Single Control Plane

All management through Azure Resource Manager:

• Consistent APIs
• Unified RBAC
• Comprehensive audit logs

4. Application-Centric Migration

Design for workload independence:

• Each application has its own landing zone (subscription)
• Teams own their resources
• Platform team owns shared services

Journey to Landing Zones

Real-World Example

Scenario: Contoso Corp migrating to Azure

Before:

• 15 subscriptions created by different teams
• No naming convention
• VNet IP conflicts
• No centralized logging
• 4-week subscription provisioning

After Landing Zone Implementation:

Contoso (Tenant Root)
├── Platform
│   ├── Identity (1 sub)
│   │   └── Domain Controllers, Entra ID Connect
│   ├── Management (1 sub)
│   │   └── Log Analytics, Automation, Backup
│   └── Connectivity (1 sub)
│       └── Hub VNet, ExpressRoute, Firewall
├── Landing Zones
│   ├── Corp (10 subs)
│   │   ├── SAP Production
│   │   ├── SAP Non-Production
│   │   ├── HR System
│   │   └── ... (internal apps)
│   └── Online (5 subs)
│       ├── E-commerce Prod
│       ├── E-commerce Non-Prod
│       └── ... (public apps)
└── Sandbox (3 subs)
    └── Developer experimentation

Results:

• Subscription provisioning: 4 weeks → 15 minutes
• Security incidents: 12/month → 1/month
• Compliance audit: 3 weeks → 2 days
• Network conflicts: Weekly → None

Quick Reference Card

Concept	Definition
Landing Zone	Pre-configured Azure environment with governance
Platform LZ	Shared services (network, identity, management)
Application LZ	Where workloads run (corp, online, sandbox)
Management Group	Governance container above subscriptions
Hub-Spoke	Traditional network topology with central hub
Virtual WAN	Managed network hub for large deployments
Policy-Driven	Governance through Azure Policy, not manual review

What Interviewers Look For

When discussing Landing Zones in interviews:

✅ Good answers:

• Explain the why (governance at scale)
• Describe management group hierarchy
• Discuss policy-driven governance
• Compare hub-spoke vs Virtual WAN trade-offs
• Mention subscription democratization

❌ Red flags:

• Treating subscriptions as "just billing containers"
• Ignoring network topology decisions
• No mention of Azure Policy
• Proposing manual governance processes

Next Steps

Continue to Design Areas to understand the 8 critical decisions every Landing Zone must address.