The Five Azure Landing Zone Decisions That Actually Matter

Most Azure landing zone decisions get made before anyone calls them decisions. The organization buys into the Cloud Adoption Framework, the platform team installs the reference accelerator, and eighteen months later someone notices the structural choices already locked in are the wrong ones for the actual workloads. This piece names the five Azure landing zone decisions that determine whether the platform scales, and the design areas you can safely defer until the evidence demands them.

Azure landing zone decisions framework — subscriptions, identity, network, policy, and vending

The scenario you have probably seen

A regulated organization adopts Azure. The platform team reads the Cloud Adoption Framework, downloads the ALZ accelerator, and deploys the full enterprise-scale reference: a six-level management group hierarchy, a connectivity subscription with a hub VNet and Azure Firewall Premium, an identity subscription with a domain-controller pair, centralized Log Analytics, and a “Landing Zones” management group with empty Corp and Online branches waiting for workloads.

Eighteen months later the picture has shifted. There are eleven subscriptions, not the projected eighty. The Azure Firewall Premium instance has become a material monthly platform cost before logs and data processing are fully accounted for, while processing only modest east-west traffic. Half the application teams route around the hub because firewall rule changes take five business days through a ServiceNow queue. The tagging strategy was never enforced with Deny, so the FinOps team cannot answer who owns 40% of the compute spend. RBAC was assigned directly to user objects in the first quarter of operations, and now a permissions audit is a multi-week exercise. The platform team has become the bottleneck for every subscription creation, and “give us a sub” has a four-week SLA.

The architecture is not wrong. The reference is not wrong. The mistake is older than any of this: someone treated the most complex pattern as the default pattern, deployed it before the operating model existed, and discovered too late that an Azure landing zone is not a deployment, it is a contract between the platform team and the rest of the organization.

This piece is about the five Azure landing zone decisions that actually determine whether that contract holds — and the design areas Microsoft documents but that you can safely defer until you have evidence you need them.

Decision Summary

The five Azure landing zone decisions that matter most are subscription boundaries, identity and access, network topology, policy authoring, and subscription vending.

These Azure landing zone decisions determine whether the platform can scale without becoming either uncontrolled or bureaucratic. Other design areas still matter, but many of them can start smaller and grow when there is evidence: multi-region design, ExpressRoute, Azure Firewall Premium, custom RBAC roles, deep management group hierarchies, complex tag taxonomies, and per-spoke Bastion.

The goal is not to deploy the most complete reference architecture. The goal is to build the smallest governed platform that can safely support production workloads and evolve when requirements become real.

When This Matters

This article matters when an organization is moving from Azure experimentation to a governed production platform.

It is especially relevant when multiple teams, subscriptions, environments, or regulatory requirements are involved. At that point, Azure landing zone decisions stop being theoretical. Subscription boundaries affect blast radius. Identity choices affect auditability. Network topology affects delivery speed. Policy authoring affects whether governance is enforceable. Subscription vending affects whether the platform team becomes an enabler or a bottleneck.

What an Azure landing zone really is, in one paragraph

An Azure landing zone is the executable operating model for Azure. Management groups, subscriptions, policy assignments, role assignments, network topology, and platform automation are the surface area, but the substance underneath is a set of agreements: who owns what, who can do what without asking, where the guardrails are, and what the platform team is on the hook for. ALZ accelerators (Bicep, Terraform CAF, the Azure Verified Modules-based stack) are how you express that operating model in code. They are not the model itself. If the model is wrong, no accelerator will save you.

With that out of the way, here are the five decisions that matter.

Decision 1 — Subscription strategy and boundaries

Position: subscriptions are blast-radius boundaries. Design them around what fails together, not around your org chart.

The default Microsoft-shaped answer is Platform (Management, Connectivity, Identity) plus Landing Zones (Corp, Online) and you grow from there. That structure is fine. The mistake is treating the Landing Zones branch as a place to mirror the business unit hierarchy.

The useful question is not “how many subscriptions do we need,” it is “what do we want to fail independently?” A subscription boundary gives you:

Independent quota envelopes (vCPU per region, public IPs, NSGs per VNet).
Independent RBAC root for the Owner role.
Independent policy assignment scope, separate from inherited management-group policy.
Independent billing scope for cost allocation that survives reorganizations.
A clean blast radius for a credential compromise or a runaway deployment.

If two workloads must fail together because they share a database or a tightly coupled lifecycle, they belong in the same subscription. If they have different compliance scopes, different funding sources, different operational owners, or different release cadences, split them. “One subscription per team” is almost always wrong because teams reorganize faster than subscriptions do, and the resulting subscription debt is painful to unwind.

A few hard-won positions:

Don’t put dev, test, and production in the same subscription separated by resource groups. Resource-group-scoped RBAC is harder to reason about than subscription-scoped RBAC, quota math gets muddy, and a single misapplied policy can take down all three.
A Sandbox management group is non-negotiable. It is the only place where engineers can experiment without violating production policy. The cost of not having it is engineers building noncompliant patterns in production and then arguing for exemptions.
Management group depth matters less than people think. The hard limit is six levels above subscriptions, but Microsoft’s own CAF guidance says keep it to three or four. Anything deeper is almost always a sign that the hierarchy is trying to model the org chart, which it should not.

Decision 2 — Identity and access model

Position: single Microsoft Entra tenant is the default. Multi-tenant is a legal/sovereignty answer, not an isolation answer. PIM belongs in the production baseline.

The most expensive identity mistakes happen early and are almost impossible to undo. The two that I see most often:

The first is choosing multi-tenant for “isolation” between business units. Multi-tenant should be driven by legal entity separation, regulatory boundaries, or M&A transitional states. If you can solve your problem with management groups, subscriptions, and RBAC, do that. For a deeper look at when multi-tenant is genuinely required and what it costs operationally, see Managing Multiple Azure Tenants for Enterprise Cloud Environments. Cross-tenant B2B collaboration looks straightforward in a diagram and is meaningfully harder in operations — every Conditional Access policy, every Privileged Identity Management assignment, every guest invitation lifecycle becomes a coordination problem.

The second is treating PIM as a Phase 2 item. The whole point of a landing zone is that the security posture is correct on day one for every subscription that lands. PIM-eligible assignments for privileged roles (Owner, User Access Administrator, Contributor at management-group scope, all directory roles) belong in the baseline, not the backlog. The same applies to Conditional Access. There is a minimum baseline that should be in place before any production workload lands:

Block legacy authentication.
Require MFA for all users, with phishing-resistant methods for administrators.
Require compliant or hybrid-joined devices for privileged operations.
Sign-in risk and user risk policies wired to Entra ID Protection.
Continuous Access Evaluation enabled for token revocation latency.

Workload identity is the other half of this decision. The default for Azure-native workloads should be managed identities with role assignments scoped to the resource they need, period. Service principals with client secrets should be the exception, not the rule, and when you need them for cross-cloud or GitHub Actions integration, use workload identity federation rather than long-lived secrets. Every secret you don’t issue is a rotation problem you don’t own.

A note on Entra ID Governance: access reviews and entitlement management belong in the platform baseline if you have any privileged role assignments at the management-group level — which you do, by definition, the moment you create the hierarchy. If you cannot show me a quarterly access review report for management-group Owners, you have a finding waiting to happen.

Decision 3 — Network topology and Private DNS

Position: hub-spoke is a centralization choice, not an enterprise standard. Default to simpler patterns until you have specific evidence you need centralization. Private DNS is the place this design actually breaks in production.

The hub-spoke reflex is the most expensive piece of cargo-culting in Azure. It exists because most reference architectures show it, and most reference architectures show it because Microsoft’s largest customers need it. You probably do not.

Centralized hub-spoke with an NVA earns its cost when at least two of the following are true: you have meaningful on-premises connectivity over ExpressRoute that needs to be amortized; you have a regulatory requirement for centralized egress inspection; you have many spoke VNets that need controlled transit between them; you have a security team that will actually operate the firewall, not just own it on the org chart. If fewer than two are true, you are probably better served by hub-and-spoke without the NVA, by simple peered VNets, or by Virtual WAN if your driver is branch count rather than inspection depth.

Virtual WAN versus classic hub-spoke is the second-order question. vWAN is the right answer when you have many branches and want Microsoft to own routing complexity. Classic hub-spoke is the right answer when you need precise control over routing tables, NVAs in non-standard positions, or you want to integrate third-party firewalls in active-active across regions. Both are valid. Picking vWAN because it sounds more modern, or picking hub-spoke because it sounds more enterprise, is not a decision — it is a vibe.

Now Private DNS, which is where most landing zones actually hurt. The moment you adopt Private Endpoints at scale, you need a Private DNS strategy. There are three patterns:

Centralized Private DNS Zones in the connectivity subscription, linked to all spoke VNets. This is the default for ALZ. Every privatelink.* zone lives in one place. Spokes have their VNets linked (without autoregistration) to each relevant zone. Records are written by Azure Policy DeployIfNotExists rules when a private endpoint is created. The constraint that matters: each private DNS zone has a hard limit of 1,000 virtual network links, and a VNet can be linked to up to 1,000 private DNS zones. For most organizations this is fine. For very large estates with thousands of spokes per region, it forces a regional sharding model.
Decentralized Private DNS Zones per workload subscription, with custom DNS forwarders. This is what you end up with when nobody owned the decision early. It works, but cross-VNet resolution requires DNS servers that conditionally forward privatelink.* queries to 168.63.129.16 from a VNet that is linked to the zone. It is brittle and the on-call pages it generates are not fun.
Azure DNS Private Resolver in the connectivity subscription with centralized zones. This is the current best pattern for hybrid scenarios. Inbound endpoints handle resolution from on-premises, outbound endpoints and forwarding rulesets handle conditional forwarding to on-premises DNS. For most hybrid designs, the Private Resolver is a cleaner pattern than maintaining a pair of DNS forwarder VMs.

For greenfield: centralized Private DNS Zones in connectivity, Azure DNS Private Resolver for hybrid, policy-driven A-record creation. Do not let application teams own their own privatelink.* zones. The fragmentation is not worth the autonomy.

Decision 4 — Policy authoring and governance scope

Position: policy is engineering. If it is not in source control, not tested, not assigned at the right scope, and not using Deny or Modify where it matters, it is decoration.

The CAF lists “governance” as a design area and most teams interpret that as “assign the ALZ policy initiative.” That is the starting line, not the finish.

Policy authoring is the discipline that separates a landing zone that holds up from one that drifts. The decisions inside it:

Assignment scope. Assign policies at the management-group level that matches the intent of the policy. Allowed locations for European data residency belongs at the top-level enterprise root or just below it. SQL TDE enforcement belongs at the Landing Zones level, not at Tenant Root, because the Platform subscriptions legitimately run things that should not have to comply. Identity and tagging baselines belong at the enterprise root. Workload-specific policy belongs at the workload’s management group, not at its subscription, so it survives subscription moves.

Effects. Audit is for discovery. Deny is for enforcement. Modify and DeployIfNotExists are for self-healing. The mistake to avoid: rolling out new Deny policies without first running them in Audit mode for a sprint and reviewing the noncompliance report. The other mistake: rolling out Audit policies and then leaving them in Audit forever because nobody wants the political fight to escalate them. An audit-only policy is a finding the org chose not to fix.

Tagging. Tagging policies that are not Deny or Modify are theater. If CostCenter matters to FinOps, then a resource without CostCenter should either be denied at creation or have a default inherited from the resource group via a Modify rule. “Audit only and trust the application teams” produces the unattributable spend problem in eighteen months. Pick inheritTagFromResourceGroup as a starting Modify pattern and refine from there.

Initiatives. Always assign initiatives, not standalone definitions, even for a single policy. Initiatives give you a single artifact to version, a single assignment to track, and a single set of parameters to manage. The ALZ initiatives published by Microsoft are a reasonable baseline if you understand what each policy does. Assigning them blind is how you end up with a policy that requires Network Watcher in every region of every subscription and then spend a week debugging why a hub deployment failed.

Exemptions. Exemptions are not failures, they are the pressure-relief valve that keeps the policy framework politically viable. Define exemptionCategory (Waiver or Mitigated), set expiresOn, require a justification, and review the exemption inventory quarterly. An exemption without an expiry date is a deletion of the policy.

If you write policies, version them in Git, deploy them with the same pipeline that deploys everything else, and validate them with Resource Graph queries. Azure Verified Modules and the ALZ pipeline templates make this materially easier than it was two years ago — use them. For broader context on how policy authoring sits inside enterprise architecture practice, see the wider Cloud Architecture coverage on CloudTales.

Decision 5 — Platform ownership and subscription vending

Position: the platform team builds the road, application teams drive on it. If the platform team is the bottleneck for every change in every subscription, the security model is a control problem in disguise.

This is the decision that determines whether the platform stays usable as you scale, and it is the one most often skipped because it is organizational rather than technical.

The boundary that matters is: what does the platform team own permanently, and what does a workload team own the moment a subscription is vended to them?

A clean split:

Platform team owns: management group hierarchy, top-level policy assignments, identity baseline (Entra tenant, Conditional Access, PIM configuration), connectivity (hub VNets, vWAN hubs, ExpressRoute, on-premises peering, central Private DNS), shared observability backbone (central Log Analytics, Defender for Cloud baseline), the subscription vending pipeline.
Application teams own: everything inside their subscription that does not violate inherited policy. Their own resource groups, their own RBAC inside the subscription, their own workload-specific policies layered on top of inherited ones, their own monitoring, their own cost.

Subscription vending is how this scales. The pattern: a workload team raises a request through a Git pull request or a portal form. A pipeline (GitHub Actions, Azure DevOps, whatever your shop uses) executes the vending Bicep or Terraform module from the published ALZ vending modules, which deploys the subscription under the correct management group, applies the standard policy initiatives via inheritance, peers it to the hub or connects it to the vWAN, sets the standard RBAC groups, creates the budget alert, applies the tagging defaults, and hands the team back a subscription that is policy-compliant on day zero.

The metric that matters: time from approved request to live subscription. If the approved request becomes a live subscription in under an hour, you have a vending pipeline. If it still takes several business days after approval, you probably have a service desk workflow pretending to be a platform capability.

Two corollaries:

The Connectivity subscription belongs in its own management group under Platform, not mixed with Management and Identity in a flat Platform group. Networking has different change cadence, different operational ownership, and different policy needs than logging. Treating it as a peer of those things saves a future migration.

Cost ownership lives with the team that creates the resource. The platform team owns the cost of platform services. The application team owns the cost of their workload. The vending pipeline must produce subscriptions with budget alerts wired to the actual owner, not to a generic distribution list that nobody reads. Without this, FinOps becomes a hunting exercise.

Azure Landing Zone Design Areas You Can Safely Defer

Microsoft documents these areas for good reason. The mistake is assuming every design area must be implemented in its most capable form on day one.

The CAF design areas are presented as a checklist, which gives the impression that they all need to be solved at once. They do not. The five Azure landing zone decisions above need to be solved before workloads land. These are the things you can defer until you have evidence you need them:

Multi-region active-active design. Defer until you have a workload with an RTO that single-region cannot meet. Deploying multi-region hub-spoke from day one when all your workloads are single-region is paying for resilience you do not consume.
ExpressRoute. Defer in favor of VPN gateways until you have measured the latency, bandwidth, or SLA gap. ExpressRoute Direct or even standard ExpressRoute is a meaningful monthly commitment.
Azure Firewall Premium. Defer in favor of Azure Firewall Standard, or even NSGs plus Azure Front Door for ingress, until you have a documented requirement for TLS inspection or IDPS.
Custom RBAC roles. Defer in favor of built-in roles until you have a specific permission gap that built-ins cannot solve. Most “we need a custom role” requirements collapse under inspection into “we did not look at the right built-in role.”
Full six-level management group depth. Defer in favor of three or four levels. Add depth when an actual policy or RBAC scope cannot be expressed at the current depth, not because the reference diagram has more boxes.
Sovereign cloud / data-residency management group branches. Defer until you actually have a workload with that requirement. The cost of restructuring later is real but small compared to the cost of building two parallel hierarchies that you operate forever.
Complex tag taxonomies. Defer in favor of three mandatory tags (CostCenter, Environment, Owner) enforced with Deny or Modify. Add more tags when you have a specific reporting need that the existing three cannot answer.
Bastion in every spoke. Defer in favor of one shared Azure Bastion in the hub with the developer SKU, or in favor of Just-In-Time access via Defender for Servers. Per-spoke Bastion is a recurring line item that mostly serves the rare interactive RDP session.

The pattern is the same in each case: the design area is real, but the answer is not “deploy the most capable version of it on day one.” It is “deploy the smallest version that meets a documented requirement, and scale up when the evidence appears.”

The position to take into your next planning meeting

A useful Azure landing zone is not the one that matches the most ambitious reference diagram. It is the one where five things are true: subscriptions are designed around blast radius and not the org chart; identity has PIM, a Conditional Access baseline, and managed identities as defaults; the network is as simple as it can be given your actual integration footprint, with Private DNS centralized; policies live in Git, use Deny or Modify where they matter, and are scoped to intent; and a vending pipeline can hand a workload team a compliant subscription in under an hour.

Everything else — the depth of the management-group tree, the firewall SKU, the number of regions, the granularity of the tag taxonomy — is a function of evidence. If the evidence is not there yet, deploy the smaller version and let the platform earn its complexity. The biggest mistake in Azure landing zone design is not choosing the wrong template. It is mistaking the most complex template for the most correct one. Get the five Azure landing zone decisions above right, defer the rest, and the platform will outlast both the people who built it and the diagram it started from.

Related Tools

CloudTales explains the architecture and operating-model decisions. cld2day can help validate the workload and cost assumptions that usually sit underneath those decisions.

Useful tools include:

These tools do not design an Azure landing zone. However, they help teams test the sizing and cost assumptions that influence subscription planning, workload placement, and financial governance.