Azure Landing Zone

A practical Contoso implementation guideline — not a restatement of Microsoft documentation. Each decision below is the one the platform team actually made, and why.

Structure

Management group hierarchy

Tenant root splits into Platform, Landing Zones and Sandbox. Policy and RBAC inherit down the hierarchy, so structure is a governance decision first and an organisational chart second.

Design decisions

Ten platform design areas

Each area follows the same repeatable format: principle, decision, implementation, guardrail and a concrete Contoso example.

Identity

Principle: Identity is the primary security boundary.
Decision: Entra ID is the single source of truth for human and workload identity across the tenant.
Implementation: Conditional Access, Privileged Identity Management, and workload identity federation for pipelines.
Guardrail: No standing owner access; break-glass accounts monitored and excluded from Conditional Access.
Example: contoso.com.au platform admins activate Owner via PIM for a maximum 4-hour window.

Resource organisation

Principle: Structure reflects governance, not org charts.
Decision: Management groups mirror the platform/landing zone/sandbox split, not business unit structure.
Implementation: A management group hierarchy applied via Bicep, deployed through the platform pipeline.
Guardrail: Only the platform team can create or modify management groups.
Example: Contoso's Corp, Data, Integration and ERP landing zones each map to a dedicated management group.

Subscriptions

Principle: Subscriptions are a unit of governance and blast-radius control, not billing convenience.
Decision: Each workload environment (dev/test/prod) gets its own subscription within its landing zone.
Implementation: Subscription vending via a self-service pipeline with pre-approved landing zone templates.
Guardrail: Subscriptions inherit policy and RBAC automatically on creation — no manual exceptions.
Example: contoso-data-prod and contoso-data-dev are provisioned as separate subscriptions under Data.

Networking

Principle: Connectivity is centralised and private by default.
Decision: A hub-and-spoke topology with all egress inspected; no landing zone has direct internet ingress.
Implementation: Hub VNet with Azure Firewall, ExpressRoute, and spoke VNets peered per landing zone.
Guardrail: Azure Policy denies public IP creation outside the connectivity subscription.
Example: The Online landing zone reaches the internet only via Application Gateway and WAF in the hub.

Security

Principle: Security posture is measured continuously, not audited annually.
Decision: Microsoft Defender for Cloud is enabled tenant-wide with a mandated minimum secure score.
Implementation: Defender plans enabled via policy assignment at the tenant root management group.
Guardrail: Regulatory compliance dashboards reviewed monthly by the platform and security teams.
Example: Defender for Cloud alerts route to the SOC via Sentinel with a 15-minute triage SLA.

Governance & Azure Policy

Principle: Guardrails are enforced automatically, not through review meetings.
Decision: A curated Azure Policy initiative is assigned at each management group tier.
Implementation: Policy-as-code in the platform repository, deployed alongside management group changes.
Guardrail: Deny-effect policies for tagging, allowed regions, allowed SKUs and encryption at rest.
Example: Deployments outside Australia East / Australia Southeast are denied by policy for AU landing zones.

RBAC

Principle: Access is scoped to the smallest resource that satisfies the need.
Decision: Custom roles are used sparingly; built-in roles are assigned at resource group scope, not subscription.
Implementation: Role assignments deployed as code, reviewed as part of every landing zone change.
Guardrail: Quarterly access reviews via Entra ID Access Reviews for all privileged roles.
Example: The Application Lifecycle team holds Contributor only on their landing zone's app resource groups.

Management & observability

Principle: Every landing zone is observable from day one.
Decision: Diagnostic settings and Log Analytics workspace connection are enforced by policy at creation.
Implementation: A central Log Analytics workspace per region, with Azure Monitor workbooks per landing zone.
Guardrail: Resources without diagnostic settings configured fail policy compliance and are flagged for remediation.
Example: The Integration landing zone streams API Management and Service Bus diagnostics to the shared workspace.

Automation

Principle: Production deployments are automated.
Decision: All landing zone and workload infrastructure is deployed through pipelines, never manually.
Implementation: Azure DevOps pipelines and Infrastructure as Code (Bicep) for every environment.
Guardrail: RBAC-scoped deployment identities, branch policies, and Azure Policy prevent portal-based changes.
Example: A pull request against environments.bicep triggers plan, approval, and apply stages.

FinOps

Principle: Cost is a design constraint, not a monthly surprise.
Decision: Budgets and cost anomaly alerts are configured per landing zone at creation.
Implementation: Azure Budgets with action groups, and monthly FinOps review of Cost Management + Power BI reports.
Guardrail: Landing zones exceeding 110% of forecast trigger an automatic notification to the owning team.
Example: The Data landing zone's budget alert flagged an unscaled-down dev Synapse pool within 24 hours.

Identity alignment

How this landing zone aligns to the RBAC framework

The Identity management group above (under Platform) is where Entra ID, Conditional Access and the directory itself live — but who can do what inside it is governed by a separate, dedicated framework: a tiered, dual-layer RBAC model that keeps privileged application access structurally apart from operational support access, and maps each control to where a specialist IDAM or PAM platform (SailPoint, Okta, CyberArk, Delinea) typically sits.

·Landing zone RBAC decisions (this page) set scope — which management group or subscription a role applies to.
·The RBAC framework sets tiering and lifecycle — how a role is requested, approved, elevated and reviewed.

View the RBAC framework

Security & governance alignment

Landing zones feed the Security & Data Governance model

The Security landing zone provides the platform surface — Defender, Sentinel, policy — but which framework and controls apply is a governance decision, not a landing zone decision. The Data landing zone is where Purview-governed data domains actually live.

View Security & Data Governance