Azure Cloud Adoption Framework: Ready — Landing Zones, Implementation Options, the Azure Setup Guide, the Eight Design Areas, and the Accelerator

Where this fits

In the Azure Cloud Adoption Framework, Ready is the methodology that turns the intent captured in Strategy and the backlog built in Plan into a concrete Azure environment that is safe to deploy workloads into on day one. Its single deliverable is an Azure landing zone: an environment that is scalable, modular, and pre-provisioned with the identity, network, governance, and operations scaffolding your first migration or innovation workload will land on, so that platform decisions are made once — centrally and deliberately — instead of being improvised under deadline pressure by every application team. Everything below is about how you produce that landing zone without over-building it.

The Azure landing zone concept

What it is

An Azure landing zone is not a single resource group or a subscription — it is an architectural construct made of two cooperating parts:

• Platform landing zones — the shared foundation. These are the subscriptions that host services consumed by every workload: the identity plane (Microsoft Entra ID, hybrid identity, Microsoft Entra Connect), the connectivity plane (the hub virtual network or Virtual WAN, Azure Firewall, ExpressRoute/VPN gateways, private DNS), and the management plane (Log Analytics workspace, Azure Monitor, Microsoft Defender for Cloud, Azure Backup, automation). Ownership sits with the central platform team.
• Application landing zones — the subscriptions where workloads actually run. Each is pre-wired to the platform (peered to the hub, bound to policy, scoped with RBAC, capped with a budget) and then handed to an application team. CAF further distinguishes online application landing zones (internet-facing) from corp (private, hub-routed) archetypes.

The connective tissue is the Microsoft Entra ID tenant at the top and a management group hierarchy beneath it that lets you assign Azure Policy and RBAC once and have them inherit down to hundreds of subscriptions. A landing zone is therefore best understood as the tenant root + management group tree + platform subscriptions + a repeatable application-subscription pattern, governed as one system.

Why it matters

The landing zone is the boundary between central control and application-team velocity. Get it right and the platform team enforces guardrails (encryption, allowed regions, diagnostic settings, network egress) through policy and RBAC inheritance, while application teams ship freely inside their subscription without filing tickets. Get it wrong — flat structure, no management groups, governance bolted on later — and you inherit the most expensive remediation in cloud: re-homing live production subscriptions, retrofitting policy onto running resources, and re-IP-ing networks. The landing zone exists specifically to make those decisions once, early, and centrally.

How to do it well

• Separate platform from application from the first subscription. Even a two-person pilot should put shared connectivity/identity/management in their own subscriptions, distinct from the workload.
• Design the management group tree before you create subscriptions. Subscriptions are cheap to mint but painful to re-parent under governance once workloads are live.
• Treat subscriptions as the unit of scale, segregation, and blast radius — by environment (prod/non-prod), by team, by archetype (online/corp) — not as a billing afterthought.
• Codify everything. The landing zone should be expressible as infrastructure-as-code (Bicep or Terraform) so it is reviewable, version-controlled, and reproducible.

Concrete artifacts, decisions, and Azure tools

Implementation options: start small and expand vs enterprise-scale vs partner

What it is

CAF deliberately does not prescribe a single way to build the landing zone. Instead it offers a spectrum of implementation options that trade up-front completeness against time-to-first-workload, so you can match the build to your organisation’s maturity and urgency.

• Start small and expand — you deploy a minimal landing zone (often just the Azure setup guide plus a small set of management-group policies) and iteratively add design-area maturity as workloads demand it. Best when you are still learning Azure, have a single team, or need a workload live this quarter.
• Enterprise-scale (the Azure landing zone conceptual + deployable architecture) — you deploy the full, opinionated reference architecture up front: a complete management group hierarchy (Intermediate root → Platform / Landing zones / Decommissioned / Sandbox), the platform subscriptions (Management, Connectivity, Identity), a curated Azure Policy initiative set, and hub networking. Best for organisations that already know they will run many workloads under central governance and want guardrails before the first migration wave.
• Partner-led — a Microsoft partner delivers a landing zone built on their own validated implementation, mapped back to CAF. Best when you lack in-house platform engineering capacity or want an accountable delivery owner.

Why it matters

The single most common landing-zone failure is mis-matching ambition to maturity — a three-person team attempting a full enterprise-scale deployment and stalling for months, or a 5,000-seat enterprise standing up a flat “start small” environment that needs a painful re-platform a year later. Choosing the right entry point is the decision that most determines whether Ready takes weeks or quarters.

How to do it well

Pick the option that matches your end-state certainty and platform-engineering capacity, not your enthusiasm. Crucially, “start small” and “enterprise-scale” are the same destination reached at different speeds — both converge on the eight design areas — so a “start small” environment built on the right management-group bones can grow into enterprise-scale without a re-platform. The failure mode to avoid is “start small” built without a management group tree, because that is the part that is expensive to retrofit.

Option comparison

The Azure setup guide

What it is

The Azure setup guide is the lightweight, action-by-action onboarding checklist that sits inside the Ready methodology and the Azure portal’s “Quickstart Center.” It is the minimum responsible configuration of a tenant and subscription — the things you should do before any workload, even if you are deliberately starting small and not yet deploying the full landing zone. It is the on-ramp, not the highway.

The guide walks through, in order: organising resources (management groups, subscriptions, resource groups, naming and tagging conventions); managing access (RBAC, least privilege, Privileged Identity Management); managing costs and billing (Microsoft Cost Management, budgets, billing scopes); governance, security and compliance (Azure Policy, Microsoft Defender for Cloud, Azure Blueprints/Key Vault); monitoring (Azure Monitor, Log Analytics, Service Health alerts); staying current with Azure (Azure Updates, roadmap, Service Health); and hybrid + scale considerations (Azure Arc, ExpressRoute).

Why it matters

The setup guide is what prevents the two most common early mistakes: deploying into a single flat subscription with Owner handed to everyone, and running for months with no cost visibility or diagnostic logging. It encodes the “tax” you pay once — naming, tagging, RBAC, budgets, baseline policy — so that everything provisioned afterward inherits sane defaults. For a “start small” path, the setup guide effectively is your first landing zone increment.

How to do it well

• Do the irreversible-by-default items first: management group structure, naming standard, tagging taxonomy (cost centre, environment, owner, data classification), and an RBAC model anchored on groups + PIM rather than direct user assignments.
• Turn on Cost Management budgets and Defender for Cloud on day one, before workloads exist, so the baseline is established and alerts are wired.
• Enforce a small set of policies immediately — allowed locations, require tags, deny public IPs where not needed, require diagnostic settings to a central Log Analytics workspace.

Concrete artifacts

• A documented naming and tagging standard (and an Azure Policy that enforces the required tags).
• A management group skeleton with at least platform vs landing-zones separation.
• An RBAC model document: which Entra groups map to which built-in/custom roles at which scope, plus PIM eligibility for privileged roles.
• Budgets per subscription/management group in Microsoft Cost Management, with action groups.
• A baseline Azure Policy assignment set at the tenant root or intermediate root.

The eight landing-zone design areas at a glance

What it is

The eight design areas are CAF’s checklist of the cross-cutting decisions every landing zone must resolve, regardless of which implementation option you pick. They are grouped into two categories — environment design (A–D), which is hard to change after the fact, and compliance design (E–H), which is more operational and iterative. Whether you deploy the full enterprise-scale architecture or start small, you are answering these same eight questions; the only difference is whether you answer them all up front or incrementally.

Why it matters

These are the decisions that, if deferred, become the expensive retrofits described earlier. The environment-design areas in particular (especially resource organisation and network topology) are the ones that lock in blast radius, governance inheritance, and IP addressing — getting them wrong means re-homing subscriptions and re-IP-ing networks under production load. Treating the eight areas as an explicit, reviewed gate before workload onboarding is the single highest-leverage practice in Ready.

The eight areas

How to do it well

• Resolve A–D before you create production subscriptions. Document each as a one-page decision record so the rationale survives staff turnover.
• Implement E–H as code and policy, not as runbooks, so the compliance areas are continuously enforced rather than periodically audited.
• Map each area to an owner. Network topology to the network team, governance to the platform/governance lead, automation to platform engineering — with one architect accountable for coherence across all eight.

The landing zone accelerator

What it is

The Azure landing zone (ALZ) accelerator — sometimes called the Enterprise-Scale landing zone accelerator — is Microsoft’s opinionated, deployable implementation of the eight design areas. It is the fastest route to a governed enterprise-scale environment because it ships the entire reference architecture as maintained code and (optionally) a portal-based deployment experience, rather than asking you to assemble it by hand.

It comes in several flavours that you choose between based on your tooling and control preferences:

• ALZ Bicep — Microsoft’s Bicep modules for the full architecture (management groups, custom policies and initiatives, hub networking, management resources), driven by orchestrator templates.
• ALZ Terraform — the equivalent for HashiCorp Terraform shops, historically the terraform-azurerm-caf-enterprise-zones / caf-enterprise-scale module and now the Azure Verified Modules (AVM) for platform landing zones, deployable via Azure DevOps or GitHub Actions.
• Portal-based accelerator — a guided deployment in the Azure portal that provisions the management group hierarchy, platform subscriptions, policy set, and connectivity from a form, ideal for a first opinionated deployment without writing code.
• Azure Verified Modules (AVM) — the strategic, Microsoft-owned and supported module library that the accelerators increasingly build on, giving you consistent, tested building blocks.

What you get out of the box is substantial: the management group hierarchy (Intermediate root → Platform → {Management, Connectivity, Identity}, plus Landing zones → {corp, online}, Decommissioned, Sandbox); a curated Azure Policy initiative set mapped to the security and governance design areas (deny public IPs, enforce diagnostic settings to a central workspace, enforce allowed locations, audit/deploy Defender plans); a hub network (hub-and-spoke or Virtual WAN) with Azure Firewall and private DNS; and the management subscription wired with Log Analytics and Defender for Cloud.

Why it matters

The accelerator collapses what is otherwise months of platform engineering into a reviewable, repeatable deployment, and — critically — it keeps you aligned with Microsoft’s evolving guidance because the modules are maintained. It is the recommended path for the enterprise-scale implementation option, and even “start small and expand” teams increasingly begin from a trimmed ALZ deployment so that growth does not require re-platforming.

How to do it well

• Fork or wrap the accelerator, do not clickops it into production. Drive it from a Git repository and a pipeline so every change to the platform is reviewed and reversible (this is design area H, platform automation, in practice).
• Customise the policy set deliberately — start from the accelerator’s initiatives, then add/remove to match your compliance obligations, rather than accepting or rejecting wholesale.
• Choose Bicep vs Terraform by team skills, and prefer AVM-based modules for new builds so you inherit Microsoft’s testing and support.
• Treat the accelerator output as the platform landing zone, then layer subscription vending (see the next part of this series) to mint application landing zones on top.

Concrete artifacts

• A Git repository containing the ALZ Bicep/Terraform configuration with your parameters (tenant root ID, regions, IP ranges, policy exclusions).
• A deployment pipeline (Azure DevOps or GitHub Actions) that plans and applies platform changes.
• The deployed management group hierarchy, platform subscriptions, policy assignments, and hub network — all version-controlled.
• A policy exemptions register documenting any intentional deviations from the baseline.

Real-world enterprise scenario

NorthBank Mutual is a fictional mid-sized building society (≈4,200 employees, regulated, UK-based) migrating from two on-premises data centres to Azure over 18 months, with a backlog of 140 applications classified in the Plan phase. They are subject to financial-services regulation, so central control and auditability are non-negotiable. Here is how they execute Ready.

Landing zone concept. NorthBank stands up a single Microsoft Entra ID tenant (northbankmutual.onmicrosoft.com). They separate platform from application landing zones from day one: three platform subscriptions (Management, Connectivity, Identity) owned by a newly formed eight-person platform team, and a repeatable application-subscription pattern split into corp (internal banking systems) and online (the customer mobile/web channel) archetypes.

Implementation option. Because the end state (140 workloads under strict governance) is known and certain, they reject “start small” and choose enterprise-scale via the ALZ accelerator, delivered by internal platform engineering with a Microsoft partner providing two weeks of advisory rather than full partner-led delivery — keeping accountability in-house while de-risking the build.

Azure setup guide. Before any subscription is handed out, the platform team completes the setup guide: a naming standard (nbm-<workload>-<env>-<region>-<type>), a five-tag taxonomy enforced by policy (CostCentre, Environment, Owner, DataClassification, Application), an RBAC model where all access flows through Entra groups with PIM required for any privileged role, Microsoft Cost Management budgets on every subscription, and Microsoft Defender for Cloud enabled tenant-wide.

Eight design areas. They resolve A–D first and record each as a one-page decision: single tenant on an MCA billing account (A); Entra ID with PIM and managed identities, no direct user role assignments (B); Virtual WAN with two secured hubs (UK South / UK West), ExpressRoute to the remaining on-prem data centre, Azure Firewall Premium for egress, and Private DNS zones for Private Link ©; a management group tree of Intermediate root → Platform / Landing zones (corp, online) / Sandbox / Decommissioned (D). Compliance areas E–H are delivered as code: Defender + Sentinel for security (E), a central Log Analytics workspace with Azure Backup and Site Recovery for management (F), an Azure Policy initiative of 60+ assignments for governance (G), and Terraform-in-Azure-DevOps for platform automation (H).

Landing zone accelerator. The platform team deploys ALZ Terraform (Azure Verified Modules) from a Git repository through an Azure DevOps pipeline. The accelerator provisions the full management group hierarchy, the three platform subscriptions, the Virtual WAN hub, and the baseline policy initiatives. NorthBank customises the policy set — adding a “deny storage account public access” and a “require customer-managed keys for PaaS data services” initiative for regulatory reasons — and records two intentional exemptions in a policy exemptions register.

Measurable outcome. Ready completes in nine weeks. The first corp workload lands in a freshly minted, policy-compliant subscription on day 63, peered to the hub and budget-capped, with zero manual network or governance configuration by the application team. Over the following quarter, 22 application landing zones are provisioned from the same pattern; Defender for Cloud reports a secure score above 85% from the first month because the baseline was enforced before workloads arrived, and an internal audit confirms 100% tag-compliance and central diagnostic logging across all subscriptions.

Deliverables & checklist

By the end of Ready you should have produced:

• A chosen implementation option (start small / enterprise-scale / partner) with documented rationale tied to maturity and end-state certainty.
• A completed Azure setup guide baseline: naming standard, tagging taxonomy (enforced by policy), RBAC model with PIM, budgets, and Defender for Cloud enabled.
• A management group hierarchy separating platform from application landing zones (corp/online), with Sandbox and Decommissioned.
• Platform subscriptions for Management, Connectivity, and Identity, deployed and wired together.
• Hub connectivity (hub-and-spoke or Virtual WAN) with firewall/egress, hybrid links (ExpressRoute/VPN), Private DNS, and a documented IP plan.
• A documented decision record for each of the eight design areas, with A–D resolved before any production subscription.
• A baseline Azure Policy initiative set assigned at the intermediate/landing-zones scope, plus a policy exemptions register.
• Central Log Analytics workspace, monitoring, backup, and security posture (Defender/Sentinel) configured.
• The landing zone expressed as infrastructure-as-code (ALZ Bicep/Terraform/AVM) in a Git repository, deployed via a reviewed pipeline.
• A repeatable application landing zone pattern ready to hand to the first workload team.

Common pitfalls

• Building enterprise-scale when you needed to start small (or vice versa). A small team stalls for months on the full accelerator, or a large enterprise builds flat and re-platforms a year later. Avoid it: match the implementation option to platform-engineering capacity and end-state certainty — and ensure even “start small” sits on a real management group tree so it can grow.
• No management group hierarchy / flat subscription sprawl. Governance gets bolted on later, forcing live subscriptions to be re-homed under policy. Avoid it: design and deploy the management group tree (design area D) before creating workload subscriptions.
• Deferring network topology and IP planning. Overlapping address spaces and ad-hoc egress surface only when you try to peer or connect on-prem, triggering painful re-IP-ing. Avoid it: resolve design area C with a documented IP plan up front; pick hub-and-spoke vs Virtual WAN early.
• Treating the accelerator as clickops. A portal-deployed landing zone with no source of truth drifts, and changes are neither reviewed nor reversible. Avoid it: drive ALZ from Git + a pipeline (design area H) so the platform is code.
• Skipping the setup guide’s “boring” basics. No naming/tagging standard, Owner handed out broadly, and no budgets or diagnostic logging until cost and audit problems appear. Avoid it: complete naming, tagging, RBAC-with-PIM, budgets, and baseline policy on day one, before workloads.
• Gold-plating the platform before the first workload. Months spent perfecting every design area while the migration backlog waits and stakeholders lose confidence. Avoid it: deliver a “good enough” governed landing zone, land a real workload, then mature the compliance design areas (E–H) iteratively.

What’s next

With a governed landing zone in place, the next part of Azure Cloud Adoption Framework moves to Migrate — assessing, replatforming, and moving your backlog of workloads into the application landing zones you just built.