Azure Landing Zones: A Foundation That Scales

Executive Summary

• An Azure landing zone is the pre-built, governed foundation your workloads land on: identity, networking, policy, and management decided once, centrally, before the first production workload ships. Get it right and every subsequent project inherits security and compliance by default. Get it wrong and you spend the next three years retrofitting.
• Microsoft’s Cloud Adoption Framework (CAF) defines this through eight design areas spanning billing and tenant, identity, resource organization, networking, security, management, governance, and platform automation. These are not optional chapters. They are the decisions that determine whether your environment scales or calcifies.
• The hard parts are organizational, not technical: a management-group hierarchy that reflects your governance model, a subscription-vending process that replaces click-ops, policy-as-code guardrails distinct from RBAC, and an Infrastructure-as-Code pipeline built on the official accelerators rather than hand-rolled scripts.
• Professnet delivers landing zones as an operational practice, not a one-off deployment. We build the platform on the official CAF accelerators, run it as code, and own the guardrails day to day. If your existing brownfield estate needs to be brought under governance gradually rather than rebuilt, we will tell you that and do it incrementally.

What Is an Azure Landing Zone?

An Azure landing zone is an environment that has been provisioned and governed in advance so that workloads can be deployed into it safely and consistently. Think of it as the developed land and utilities you prepare before any building goes up: the plots are surveyed, the power and water are connected, the zoning rules are enforced, and the access is controlled. Teams then build on that foundation without re-litigating where the water main goes.

The concept comes from Microsoft’s Cloud Adoption Framework (CAF), the vendor’s prescriptive guidance for adopting Azure at scale. CAF distinguishes between two kinds of landing zone. The platform landing zone provides shared services that every workload consumes: identity, connectivity, management, and security tooling. The application landing zone is the subscription a specific workload runs in, pre-configured and handed to a product team. The platform team owns the former; workload teams own the latter, within the guardrails the platform imposes.

Key fact: a landing zone is defined less by what you deploy and more by the decisions you make before deploying. CAF organizes those decisions into eight design areas, and the reference architecture is simply the result of answering all eight coherently.

Key Plain-language Definitions

• Management group: a container above subscriptions used to apply policy and access at scale across many subscriptions at once.
• Subscription: the primary billing and isolation boundary in Azure. Resources live inside subscriptions; subscriptions live inside management groups.
• Microsoft Entra tenant: the identity directory (formerly Azure Active Directory) that holds your users, groups, and service principals and underpins all authentication.
• Guardrail: an automated control, expressed as policy, that prevents or audits non-compliant configurations rather than relying on a human to remember the rule.

What Are the Eight CAF Design Areas?

Microsoft Learn groups the eight design areas into two sets. The environment design areas shape the platform foundation, and the compliance design areas are the focus for ongoing, iterative refinement. Verified against the current CAF documentation, they are as follows.

Environment Design Areas

1. Azure billing and Microsoft Entra tenant. Tenant creation, enrollment, and billing setup. These are early, structural decisions: how many tenants, which agreement, and how cost flows to the right business units.
2. Identity and access management. In the cloud, identity is the primary security boundary. This area covers your Entra design, privileged access, and how RBAC maps to your organizational structure.
3. Resource organization. Subscription design and the management-group hierarchy. As adoption scales, these choices directly shape governance, operations, and adoption patterns.
4. Network topology and connectivity. The foundational networking model: hub-and-spoke or Virtual WAN, hybrid connectivity, DNS, and traffic inspection.

Compliance Design Areas

1. Security. The controls and processes that protect the environment, from Microsoft Defender for Cloud to secret management and threat detection.
2. Management. The operations baseline: monitoring, logging, backup, and recovery so the platform is observable and resilient.
3. Governance. Automated auditing and enforcement of policy. This is where Azure Policy does most of its work.
4. Platform automation and DevOps. The tooling and templates that deploy the platform and workloads, treating the environment as code.

You should evaluate all eight before choosing an implementation option. They are sequential and they interlock: a networking decision constrains your security model, and your resource organization constrains how governance is applied. Skipping one does not remove the decision. It just means the decision gets made implicitly, by accident, later.

How Should the Management-group Hierarchy and Subscriptions Be Organized?

The management-group hierarchy is the skeleton of the whole environment. The CAF reference architecture places an intermediate root management group beneath the tenant root, then branches into a small, deliberate set of children. A typical shape is:

• Platform, containing the shared-service subscriptions: identity, connectivity, and management.
• Landing zones, containing the application subscriptions, commonly split into corp (workloads with private connectivity to on-premises) and online (internet-facing workloads).
• Sandbox, for experimentation, deliberately isolated with no corporate connectivity and loosely governed.
• Decommissioned, where subscriptions go to be retired under tight, deny-by-default policy.

Key fact: the hierarchy should reflect your policy and governance boundaries, not your org chart. A common and expensive mistake is to model management groups on departments. Departments reorganize; security postures do not. You apply different controls to internet-facing and internally-connected workloads, so that distinction belongs in the hierarchy. Marketing versus Finance does not.

Subscriptions are the unit of scale, and how you create them matters as much as how you arrange them. The answer is subscription vending: a standardized, automated process by which a workload team requests a subscription and the platform team provisions it, already placed in the correct management group, already wired to networking, already carrying the right policies and budgets. Microsoft ships subscription-vending modules for both Bicep and Terraform via Azure Verified Modules, so this does not have to be built from scratch.

Quick answer: the alternative to vending is click-ops, where someone creates subscriptions by hand in the portal. That path produces ungoverned, unnetworked, untagged subscriptions that escape every guardrail you carefully built. If you take one principle from this article, make it this: subscriptions are vended by a pipeline, never clicked into existence.

Hub-and-spoke or Virtual WAN?

CAF supports two network topologies, and the choice is one of the more consequential decisions in the whole landing zone.

Traditional hub-and-spoke uses a hub virtual network that you build and operate yourself, holding shared services such as Azure Firewall, a VPN or ExpressRoute gateway, and DNS. Spoke networks peer to the hub. You control routing explicitly through user-defined routes. This gives maximum control and is well understood, but you own the operational burden, including the routing tables. Asymmetric routing in particular is a recurring source of dropped traffic in hub-and-spoke designs, and it is worth understanding the failure modes before you commit. We have written separately on asymmetric routing in hybrid hub-and-spoke topologies.

Azure Virtual WAN is a Microsoft-managed networking service that provides the hub as a managed resource, with built-in transitive routing between spokes, branches, and remote users. It reduces the routing and scaling work you carry, at the cost of some flexibility and a different pricing model. As a rough rule: choose Virtual WAN when you have many regions, many branch sites, or large-scale remote connectivity and want Microsoft to manage transitivity; choose traditional hub-and-spoke when you need fine-grained control over a smaller, more static footprint, or have specific appliance requirements. Neither is wrong. The wrong answer is a flat network with no segmentation at all, which collapses the security boundary the moment one workload is compromised.

How Do Azure Policy and RBAC Actually Differ?

These two are constantly confused, and conflating them produces real security gaps. They answer different questions.

Role-based access control (RBAC) answers who can do what. It governs identities and actions: can this user create a virtual machine, read a storage account, or delete a resource group. RBAC is about permissions.

Azure Policy answers what is allowed to exist and how it must be configured. It governs the resources themselves regardless of who creates them: storage accounts must reject public access, virtual machines may only use approved SKUs, every resource must carry a cost-center tag, deployments may only target European regions. Policy is about compliance and configuration.

The distinction matters because they fail in opposite directions. A user with broad RBAC rights still cannot create a non-compliant resource if a deny policy forbids it. And a perfectly compliant resource is still exposed if RBAC grants the wrong people access to it. You need both, and you need them as policy-as-code: definitions and assignments stored in version control, reviewed in pull requests, and deployed by pipeline. Guardrails that live only in the portal are guardrails nobody can audit or reproduce.

In practice you assign policy initiatives (grouped sets of policies) at the management-group level so that every subscription beneath inherits them automatically. This is the entire point of the hierarchy: define the control once, near the top, and let inheritance do the rest. This is also where just-in-time privileged access fits, complementing standing RBAC with time-bound elevation. We cover the pattern in Microsoft Entra PIM for just-in-time access.

Bicep or Terraform, and Which Accelerator?

A landing zone must be Infrastructure as Code from day one. The two mainstream choices on Azure are Bicep, Microsoft’s native declarative language that compiles to ARM, and Terraform, HashiCorp’s multi-cloud tool. Both are first-class here, and Microsoft publishes official Azure Landing Zones accelerators for each, now built on Azure Verified Modules (AVM) so you consume tested, supported building blocks rather than reinventing them.

The current IaC accelerator follows a phased approach: a planning phase to choose your language and version-control system, a prerequisites phase to set up credentials and subscriptions, a bootstrap phase that prepares the Azure environment and pipelines, and a run phase where you customize the code. The value is that the difficult, error-prone scaffolding is already solved and maintained by Microsoft.

Quick answer: choose Bicep if your team is Azure-only and values the tightest native integration and zero state management. Choose Terraform if you operate multi-cloud, already have Terraform expertise, or want its module ecosystem. The deciding factor is rarely the language and almost always the operating model around it. With Terraform, state management is the part teams underestimate; remote state, locking, and isolation are not optional at landing-zone scale, and we have written specifically on advanced Terraform state management. Whichever you pick, standardize naming and tagging conventions before you write the first module, because retrofitting tags across hundreds of resources is miserable and is exactly the kind of work guardrails exist to prevent.

Greenfield or Brownfield?

Greenfield adoption means deploying the landing zone into a clean tenant before significant workloads exist. This is the comfortable case: you deploy the accelerator, set your policies to deny from the start, and every workload is born compliant.

Brownfield adoption is the reality for most established companies. You already have subscriptions, networks, and workloads, often created over years without a coherent model. You cannot flip a deny policy across that estate without breaking production. The correct approach is incremental: deploy the management-group hierarchy alongside what exists, move subscriptions into it carefully, and roll out policies first in audit mode to measure non-compliance without enforcing it. Once you understand the gap, you remediate and progressively switch high-confidence policies to enforcement. This is slower and less satisfying than a clean build, but it is how regulated organizations adopt governance without an outage.

What Are the Common Mistakes?

• No management-group design. Dropping everything into the default group and applying policy per subscription. You lose inheritance and consistency immediately.
• Click-ops subscriptions. Hand-created subscriptions that bypass vending, arriving ungoverned, unnetworked, and untagged.
• Flat networks. A single network with no segmentation, so one compromise reaches everything and the security boundary is fiction.
• No naming or tagging standard. Without it, cost allocation, automation, and policy targeting all break, and the cleanup cost compounds with every new resource.
• Modeling the hierarchy on the org chart. Governance boundaries, not departments, belong in management groups.
• Guardrails in the portal, not in code. Unauditable, unreproducible, and quietly drifting.

Where Should You Start?

Start with the eight design areas, on paper, before you touch the portal. Decide the management-group hierarchy and the network topology first, because everything else hangs off them. Pick your IaC language and stand up the official accelerator rather than scripting from scratch. Express every guardrail as policy-as-code, assigned at the management-group level, and begin in audit mode if you are brownfield. Then vend your first application landing zone through the pipeline and confirm it is born compliant. If that first vended subscription is correct, the next thousand will be too.

If you are planning a new Azure foundation, or you have a sprawling brownfield estate that needs to be brought under governance without breaking production, we would be glad to help. Professnet builds and operates landing zones on the official CAF accelerators as a hands-on practice, and you can reach us through our services page or contact us for an assessment.