TopolearnAt enterprise scale, the structure of subscriptions, networks and guardrails decides how fast teams can move safely.
A landing zone is a pre-provisioned subscription with networking, identity, policy and monitoring already in place, so an application team can deploy into it safely on day one. The Cloud Adoption Framework's Azure landing zone reference architecture defines the common layout:
- A management group hierarchy under the tenant root, typically: an intermediate root (e.g.
contoso) containing Platform (child groups Identity, Management, Connectivity), Landing zones (Corp for internal, private-network apps; Online for internet-facing ones), Sandbox and Decommissioned. - Platform landing zones: dedicated subscriptions for central logging (Log Analytics, Defender for Cloud), connectivity (hub VNet or Virtual WAN, Azure Firewall, VPN/ExpressRoute gateways, DNS Private Resolver, private DNS zones), and identity (domain controllers if needed).
- Application landing zones: one or more subscriptions per workload and environment, spoke VNets peered to the hub, with policies inherited from their management group (deny public IPs in Corp, enforce diagnostics, allowed regions).
Subscription vending automates creating a new landing zone: create the subscription through the billing API, place it in the right management group, peer its spoke, assign budgets and RBAC, all from IaC triggered by a request.
Design principles: policy-driven guardrails rather than manual approvals, subscriptions as the unit of scale and isolation, central platform services, and application teams owning everything inside their landing zone. Accelerators with Bicep and Terraform (Azure Verified Modules) implement the reference rather than building it from scratch.
Example
# Skeleton of the reference management group hierarchy
az account management-group create -n contoso -d "Contoso"
for mg in platform landingzones sandbox decommissioned; do
az account management-group create -n "contoso-$mg" --parent contoso
done
for mg in identity management connectivity; do
az account management-group create -n "contoso-$mg" --parent contoso-platform
done
for mg in corp online; do
az account management-group create -n "contoso-$mg" --parent contoso-landingzones
done
# Place a vended application subscription under Corp
az account management-group subscription add -n contoso-corp --subscription "$NEW_SUB_ID"
# Corp guardrail: assign a policy denying public IPs at the management group
az policy assignment create -n deny-public-ip --scope /providers/Microsoft.Management/managementGroups/contoso-corp \
--policy 6c112d4e-5bc7-47ae-a041-ea2d9dccd749 --params '{"listOfResourceTypesNotAllowed":{"value":["Microsoft.Network/publicIPAddresses"]}}'Remember
- Landing zone = subscription pre-wired with network, identity, policy and monitoring
- Platform (identity, management, connectivity) vs application landing zones
- Guardrails are inherited from the management group hierarchy
- Automate subscription vending; start from the accelerators
Watch out for
- Modeling management groups on the org chart instead of on policy and access needs, creating deep hierarchies that are hard to change.