Azure Architecture Series #30 — Landing Zones and the Cloud Adoption Framework Accelerator

Business Challenge

This series began with management groups and subscriptions, and has spent twenty-nine posts on the mechanisms underneath an Azure estate: policy, RBAC, locks, deny assignments, moves, deployment scopes, templates, state. Every one of those posts ended with a design decision left to the reader.

The Cloud Adoption Framework's landing zone is Microsoft's version of those decisions already made. It is a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment, and it comes in two halves:

• A platform landing zone — the centralized foundation that establishes governance, security, and shared resources for all your Azure workloads. Most organisations should have only one per Microsoft Entra tenant.
• Application landing zones — the environments where workload teams deploy and operate workload resources within the guardrails of the platform landing zone. One per workload, containing every environment that workload needs.

You can get either by accelerator — Microsoft-provided infrastructure as code — or by custom build. The guidance does not hedge: for most organizations, accelerators provide the fastest path to a deployment that aligns with Microsoft's recommended practices.

That could be read as "run the accelerator and stop thinking", and it is worth saying plainly why that reading fails. An accelerator makes the reversible decisions for you. It does not make the irreversible ones, and it cannot stop you undoing its work with a well-intentioned change in week three. The most useful thing in the landing zone documentation is therefore not the hierarchy diagram. It is the list of things it tells you not to do — because every item on that list is something a competent architect does by instinct.

Architecture

What the platform landing zone actually contains

Three things, and the third is the one most estates underestimate.

A management group hierarchy, which organizes all of your Azure subscriptions and applies governance standards to those subscriptions. The baseline names are worth knowing because they encode decisions:

Notice what the top-level split is doing. Corp, Online and Local are not business units or environments — they are connectivity and compliance postures. That is the choice that makes the hierarchy useful for its stated purpose, which is applying policy to groups of subscriptions that need the same rules.

Centralized resources, with a sentence worth pinning up: only centralize capabilities that provide clear governance, operational, or economic benefits across multiple workloads. Centralising is not free — it creates a platform team dependency for every workload that touches it — and the test offered is a benefit across multiple workloads, not a preference for tidiness.

A distribution process. The platform needs a repeatable process for requesting, creating, and distributing application landing zones to workload teams, and as the number of application landing zone requests grows, automation becomes increasingly important. This is subscription vending, and it is the part teams build last and wish they had built first, because until it exists every new workload is a bespoke conversation.

The application landing zone is a workload, not a subscription

The definition is more specific than the casual usage suggests. Each workload has a single application landing zone, and that landing zone contains all the environments required to support that workload, such as development, test, and production. Each environment is then one or more Azure subscriptions.

So the unit is the workload; environments live inside it; subscriptions are the implementation detail underneath. The platform team's only decision at handover is which of Online, Corp or Local the subscriptions belong in — and that decision is about connectivity posture, which determines which policies the subscription inherits.

The five prohibitions, and why each one is tempting

The second one deserves emphasis, because it collides with an argument this series has made. Post #18 established that role assignments are a per-scope budget, and post #19 that assigning to groups rather than users is how you stay inside it. The natural next step — assign the group at a management group and cover everything at once — is exactly what the guidance forbids for application teams, on the grounds that inheritance turns a convenience into a blast radius. Platform teams may hold management group scope, and even then this should be controlled via privileged identity management to ensure that the permissions are only granted when needed.

Depth, and the headroom you are asked not to spend

A management group tree can support up to six levels of depth, excluding the tenant root and the subscription level. The recommendation is no more than three to four levels — 6 − 4 = 2 levels deliberately left unspent, because this restriction reduces management overhead and complexity.

The suggested alternative for the cases that tempt you into more depth is neat: use resource tags to query and horizontally navigate across the management group hierarchy, enforced or appended by Azure Policy, so you can group resources for search needs without having to use a complex management group hierarchy. Tags for finding things, hierarchy for governing them — which is exactly the split post #13 argued for from the tagging side.

Why This Architecture Holds Up

The accelerator makes the cheap decisions, not the expensive ones

Running an accelerator produces a hierarchy, policy assignments, platform subscriptions and a network topology — all of which are reversible with effort. What it cannot do is make the decisions this series spent twenty-nine posts showing are hard to undo:

• Where custom role definitions live, because AssignableScopes caps their reach permanently (#20).
• Which resource group a resource is created in, because moving it is a four-hour lock, a changed resource ID and an orphaned role assignment (#23).
• Which management group a subscription sits under, because that determines everything it inherits (#14–#17).
• Whether stacks or Terraform hold the record of what exists, and where that record lives (#27, #28).

The accelerator is best understood as removing the decisions that have a known right answer, so attention is left for the ones that do not. That is a real service, and it is a different thing from removing the need to understand the platform.

Start with the default three

For all the tailoring documentation, the guidance is unambiguous about where to begin: for many organizations, the default Corp, Online, and Local management groups provide an ideal starting point.

That is worth taking literally, because the failure mode is predictable. A design workshop generates fifteen management groups reflecting every distinction anyone can name, and the estate spends two years discovering that twelve of them never received a different policy from their sibling. Groups are cheap to add when a genuine policy difference appears, and expensive to remove once subscriptions live in them.

The architecture is designed to absorb what comes next

One claim in the documentation is easy to skip and worth testing against the last two years: an Azure landing zone supports new and emerging technologies without requiring changes to the overall architecture. The mechanism is that new workload types go into application landing zones like any other, and new requirements become policy updates in the platform, applied consistently downward.

That is the real argument for the hierarchy being about policy rather than organisation. An org chart has to be restructured when the company reorganises. A hierarchy whose top-level split is connectivity posture does not care, because what changed was reporting lines and what it governs is network exposure.

Key Architecture Decisions

The shape that works

Closing Thought

This post closes the foundations phase of the series, and the landing zone is a fitting place to end it — because it is the moment all the individual mechanisms stop being separate topics and become one environment.

What stands out, having taken the platform apart first and read the reference architecture second, is how much of the guidance is defensive. Do not nest deeply. Do not grant broadly. Do not model things the hierarchy was not built to model. Do not put policy where it will be inherited by everything. These are not the notes of a team describing an elegant design; they are the notes of a team that has watched a great many estates go wrong in the same handful of ways, and has written down the turnings.

Which suggests the right way to use it. Deploy the accelerator, by all means — it is the fastest path to a defensible starting point. But read the prohibitions first and treat them as the actual deliverable, because the hierarchy it creates can be rebuilt in an afternoon, and the habits that erode it take a year to form and several to undo.

Official Azure Reference

• What is an Azure landing zone?
• Management groups design area
• Azure landing zone design areas
• Subscription vending
• Tailor the Azure landing zone architecture