Azure Platform Foundation
Azure Landing Zones are not just subscriptions. They are the foundation of a real cloud platform.
This series documents how to build that foundation from a clean Azure tenant, in the order the decisions actually need to be made. It is written for a small-to-medium organization that wants the structure and guardrails of the Microsoft Cloud Adoption Framework without copying a large enterprise reference architecture it does not yet need.
Purpose
This is platform documentation, not a loose collection of Azure how-to articles. An Azure Landing Zone is a standardized platform foundation that provides shared services, governance, and guardrails before workloads are onboarded. Microsoft defines it across eight design areas — Azure billing and Microsoft Entra tenant, identity and access, resource organization, network topology and connectivity, security, management, governance, and platform automation and DevOps — not as a subscription layout.
The series distinguishes two layers that the rest of the documentation keeps separate:
- Platform landing zone — the shared services every workload depends on: identity, connectivity, management and monitoring, governance, and security.
- Application landing zones — the subscriptions where workloads are deployed and operated, inheriting guardrails from the platform through management group placement, Azure Policy, and Azure RBAC.
Design Reasoning
For an organization starting with a clean tenant, the biggest risk is rarely a missing Azure feature. The bigger risk is copying a large reference architecture too early — before the platform capabilities behind it are understood — and inheriting complexity that nobody owns.
This series therefore moves from principles to implementation, defining the foundation before onboarding workloads:
Start Here → Design Principles → Management Groups → Subscriptions → Naming and Tagging → Identity and Access → Policy → Networking → Security → Monitoring → Automation → Workload Onboarding → Governance → Reference Implementation.
Every page explains not only what to configure, but why the configuration exists, and where a deliberate deviation from Microsoft’s reference architecture is reasonable.
How to read this series
Read it in order the first time — each page assumes the decisions made in the previous one. Afterwards, use it as a reference: each page is self-contained, with its own decisions, examples, validation steps, and sources.
Architecture Decision Record
| Decision | Choice | Rationale |
|---|---|---|
| Series scope | Platform-first foundation for a small-to-medium organization | Workloads are easy to add once the platform contract exists; the contract is expensive to retrofit once workloads are running. |
| Source of truth | Microsoft Learn and the Cloud Adoption Framework | Community tools and field experience are supporting material, not the primary architectural authority. |
Tradeoff: A platform-first approach delays the first workload slightly. In exchange, every workload that follows inherits consistent identity, networking, logging, and governance instead of negotiating them one ticket at a time.
Recommended Configuration
A practical Azure platform foundation for a small-to-medium organization includes:
- Microsoft Entra ID as the identity foundation
- A management group hierarchy for policy and access inheritance
- Platform subscriptions for shared services (connectivity, management, identity)
- Application landing zone subscriptions for workloads
- Azure Policy as the governance engine
- Azure RBAC with group-based assignments and Privileged Identity Management
- Centralized monitoring and logging in a single Log Analytics workspace
- A network and DNS foundation (hub-spoke or Virtual WAN, private DNS, private endpoints)
- A security baseline (Defender for Cloud, Key Vault with RBAC, managed identities)
- Infrastructure as Code for deployment and ongoing operations
Example Implementation
The relationship between the Microsoft Entra tenant, the management group hierarchy, the platform landing zone, and the application landing zones:
flowchart TD T[Microsoft Entra ID tenant] --> R[Intermediate root management group] R --> P[Platform landing zone] R --> L[Application landing zones] P --> P1[Identity] P --> P2[Management and monitoring] P --> P3[Connectivity] P --> P4[Security] L --> L1[Corp-connected workloads] L --> L2[Online workloads] L --> L3[Sandbox]
Complete Table of Contents
| # | Page | Focus |
|---|---|---|
| 1 | Start Here | What an Azure Landing Zone really is |
| 2 | Design Principles | Architecture principles and tradeoffs |
| 3 | Management Group Hierarchy | Governance hierarchy and scope placement |
| 4 | Subscription Strategy | Platform and workload subscriptions |
| 5 | Naming and Tagging | Consistency, cost visibility, and automation |
| 6 | Identity and Access | Microsoft Entra ID, Azure RBAC, PIM, break-glass |
| 7 | Policy Baseline | Guardrails, initiatives, exemptions, remediation |
| 8 | Network Foundation | Hub-spoke, Virtual WAN, DNS, private endpoints |
| 9 | Security Baseline | Defender for Cloud, Key Vault, managed identities |
| 10 | Logging, Monitoring, and Operations | Log Analytics, diagnostics, alerts, workbooks |
| 11 | Platform Automation and IaC | Bicep, Terraform, AVM, ALZ accelerators |
| 12 | Workload Onboarding | Subscription vending and workload handover |
| 13 | Governance Operating Model | Reviews, exceptions, ownership, operations |
| 14 | Common Mistakes | Frequent design and implementation mistakes |
| 15 | Final Reference Implementation | Target architecture, sequence, MVP vs. mature |
Common Mistakes
- Introducing landing zones as a management group tree only. That framing misses identity, connectivity, governance, security, monitoring, and automation — the parts that make it a platform.
- Assuming landing zones are only for large enterprises. Microsoft’s guidance is explicitly designed to be tailored to organizations of different sizes and maturity levels.