Start Here: What an Azure Landing Zone Really Is
If you take one idea from this series, take this one: a subscription is not the goal. A subscription is a single unit inside a larger platform contract. The platform defines how subscriptions are created, governed, secured, monitored, connected, and handed over to workload teams.
Purpose
This page explains the core concept behind everything that follows: an Azure Landing Zone consists of a platform landing zone and one or more application landing zones.
- The platform landing zone provides shared services — identity, connectivity, management and monitoring, governance, security, and automation.
- Application landing zones host workloads and inherit guardrails from the platform through management group placement, Azure Policy assignments, and Azure RBAC.
Design Reasoning
If landing zones are presented as a subscription structure only, the most important parts are missing: guardrails, centralized operations, identity foundations, networking, security, logging, and automation. Those are exactly the parts that make a collection of subscriptions into a platform.
The shared services in the platform landing zone are the reusable foundations no single workload should re-invent:
- Identity — Microsoft Entra ID, group-based access, privileged access management.
- Connectivity — the hub network, DNS, private connectivity, and hybrid links.
- Management and monitoring — centralized logging, alerting, and operational visibility.
- Governance — Azure Policy guardrails inherited through the management group hierarchy.
- Security — Defender for Cloud, secrets management, and a secure baseline.
Guardrails are the mechanism that lets workload teams move quickly and stay inside the intended design. A guardrail is not a gate that blocks every action; it is a control — usually an Azure Policy or an RBAC boundary — that makes the expected architecture hard to accidentally bypass.
Subscriptions are one part of the model
Subscriptions are units of ownership, billing, and isolation. They matter — but they are governed by the platform, not the other way round. Design the platform contract first, then vend subscriptions into it.
Architecture Decision Record
| Decision | Choice | Rationale |
|---|---|---|
| Platform model | Platform landing zone plus application landing zones | Follows Microsoft’s Azure Landing Zone model and separates shared services from workload-specific resources. |
| Build order | Platform guardrails before workload onboarding | Onboarding workloads first produces inconsistent RBAC, missing diagnostics, unclear ownership, and unmanaged networks. |
Tradeoff: Separating platform and application concerns adds a few platform subscriptions and a management group hierarchy up front. The return is that every workload inherits identity, networking, logging, and policy instead of reinventing them.
Recommended Configuration
For a clean greenfield Azure environment, a small-to-medium organization should build this baseline first:
- Microsoft Entra ID as the identity foundation
- A management group hierarchy for inheritance
- At least one management subscription (central logging and monitoring)
- At least one connectivity subscription (hub network and DNS)
- Azure Policy as the governance engine
- Azure RBAC with group-based role assignments
- Centralized logs, alerts, and diagnostics
- Infrastructure as Code for platform deployment
- A documented workload onboarding process
Example Implementation
The platform foundation is the set of shared capabilities that exist before any workload is onboarded:
flowchart LR A[Identity] --> Z[Platform foundation] B[Governance] --> Z C[Networking] --> Z D[Security] --> Z E[Monitoring] --> Z F[Automation] --> Z Z --> G[Workload onboarding]
Validation Steps
Confirm the documentation — and your environment — clearly answer the following:
- A platform landing zone provides shared platform services.
- An application landing zone hosts workload-specific resources.
- A workload can use one or more subscriptions depending on isolation, ownership, and scale requirements.
- Policy and access inheritance come from the management group hierarchy.
- Workload onboarding happens only after basic platform guardrails exist.
Common Mistakes
- Treating platform subscriptions as separate “helper” subscriptions. Identity, connectivity, and management subscriptions are platform landing zone components, not side projects.
- Onboarding workloads before guardrails exist. This is the single most common cause of inconsistent RBAC, missing diagnostic settings, unclear ownership, and unmanaged network patterns.