Azure landing zone design and deployment

What we build

We deploy enterprise-scale landing zones aligned to the Microsoft Cloud Adoption Framework, written entirely as code. Nothing is clicked into existence in the portal, which means the whole thing can be rebuilt, reviewed in a pull request, and explained to an auditor.

Management groups and policy. A hierarchy that matches how your organization actually works: by business unit, by environment, or by regulatory boundary. Azure Policy enforces region restriction, tagging, encryption, allowed SKUs and diagnostic settings at the level where they cannot be bypassed by a subscription owner in a hurry.

Identity. Entra ID tenant configuration, conditional access, privileged access management, break-glass accounts, and a role model that grants people the access their job requires rather than Owner on everything.

Networking. Hub-and-spoke topology, Azure Firewall or a third-party NVA, private endpoints for PaaS services, private DNS zones, and hybrid connectivity to what remains on-premises. Public exposure is the exception and it is documented.

Observability and cost. Centralized Log Analytics, diagnostic settings applied by policy, Defender for Cloud enabled at the right plan, budgets and anomaly alerts per subscription.

Deployment pipelines. GitHub Actions or Azure DevOps pipelines that plan on pull request and apply on merge, with OIDC federated credentials instead of long-lived secrets.

A landing zone as it is actually deployed Four levels, in this order: management group, subscription, resource group, then the resources themselves. Policy is assigned at the top and inherited all the way down, so a subscription owner in a hurry cannot switch it off. The workload runs in Container Apps in the spoke, and reaches its database through a private endpoint rather than across the public internet.

Tenant root Management group mg-root Everything below inherits from here, including the naming and tagging standard these names follow.

Azure Policy, assigned here, inherited by every subscription created after it

Allowed regions: canadacentral and canadaeast, and nothing else
Required tags: owner, cost centre, environment, data classification
Encryption at rest enforced, public network access denied unless an exception is filed
Diagnostic settings routed to the Log Analytics workspace automatically

Management groups

Management group Platform mg-platform Connectivity, identity and management. Owned by the platform team, not by a project.
Management group Landing zones mg-landing-zones Where workloads live. One subscription per application and environment, so cost has a boundary.

Subscriptions

Subscription Connectivity sub-connectivity The hub, and nothing else. No workload is ever deployed into it.
Subscription Management sub-management Logging, Microsoft Defender for Cloud plans, budgets and anomaly alerts.
Subscription Production workload sub-lz-prod-01 One application, one environment, its own cost boundary and its own blast radius.

Resource groups, and what is inside them

Resource group Hub rg-hub-canadaeast-01 Shared network services. Deployed once, used by every spoke that follows.

Network Hub network vnet-hub-canadaeast-01 Address space reserved for the region up front, rather than improvised one project at a time.
Egress control Azure Firewall afw-hub-canadaeast-01 All outbound traffic passes through it. The rule set is code, reviewed in a pull request.
Name resolution Private DNS zones privatelink.database.windows.net Linked to the hub, so a private endpoint resolves the same way from every spoke.
Hybrid ExpressRoute or VPN vgw-hub-canadaeast-01 Connectivity to what stays on premises. One of the two, chosen on bandwidth and latency, not on habit.

Hub and spoke peering The spoke reaches the hub, and only the hub reaches the outside.

Resource group Production workload rg-prod-canadaeast-01 The resource group the client asked to see. This is what a deployed application looks like inside one.

Network Spoke network vnet-prod-canadaeast-01 Peered to the hub. No public address on any subnet, and the route table sends egress to the firewall.
Public entry Application Gateway and WAF agw-prod-canadaeast-01 The single public entry point for the workload. Every other exposure is an exception with a name on it.
Runtime Container Apps environment cae-prod-canadaeast-01 Injected into the spoke network, internal ingress only, so the containers are never reachable directly.
Container Apps API ca-api-prod-01 Scales to zero outside business hours, which is where most of the saving on this workload comes from.
Container Apps Background worker ca-worker-prod-01 Same image, different revision, no ingress at all. It reads its queue and nothing reads it.
Data Azure SQL sql-prod-canadaeast-01 Public network access denied by policy. It has no address on the internet to attack.
Private Link Private endpoint pe-sql-prod-01 How the containers reach the database: an address inside the spoke, resolved by the hub private DNS zone.

What every subscription reports into

Resource group Management rg-mgmt-canadaeast-01 One place the whole estate reports into, which is what makes an audit answerable in an afternoon.

Logging Log Analytics workspace log-platform-canadaeast-01 Diagnostic settings are pointed here by policy, so a new subscription is instrumented on the day it is created.

Subscription scope Microsoft Defender for Cloud Enabled at the plan the estate needs, with the regulatory compliance view mapped to the framework you are assessed against. It sits on the subscription, not in a resource group.
Tenant scope Microsoft Entra ID The role model and the privileged access rules that every subscription in the hierarchy inherits. Nothing about it lives inside a resource group.

The dark elements are what keeps the traffic private, and the policy inherited from the top of the hierarchy.
Resource names follow the convention deployed on the estate: type, environment, region, index.

How the four weeks run

Week 1: decisions. We work through the choices that are expensive to reverse: hierarchy shape, region strategy, identity model, network topology, naming and tagging. Output is a decision record, not a slide deck. Every choice is written down with its reason, so the person who asks “why is it like this?” in two years gets an answer.

Week 2: platform. Management groups, policy assignments, the hub network, logging and the identity baseline are deployed to a non-production tenant or subscription set and reviewed with your team.

Week 3: production and pipelines. The same code is promoted to production. Pipelines, branch protection and the review process go live. Your engineers open their first pull request against the infrastructure.

Week 4: handover. Documentation, runbooks, a walkthrough with your team, and a backlog of what we deliberately left out and when it should be picked up.

What you keep

A Terraform or Bicep repository in your Git organization, with module documentation.
Working CI/CD pipelines and the service principals or federated credentials behind them.
The decision record from week one.
A policy set mapped to the controls your auditor asks about.
A named remediation backlog, prioritized, with our honest estimate of what each item costs.

Who this is for

Organizations between roughly 50 and 5,000 people that are either starting on Azure properly for the first time, or that have an estate which grew without governance and is now slowing them down. It works particularly well ahead of a migration, an AI project or an audit. All three expose an ungoverned estate quickly.

Who this is not for

If you have three virtual machines and no plans to grow, an enterprise-scale landing zone is over-engineering and we will tell you so. If your organization cannot agree on a subscription hierarchy because the underlying question is political rather than technical, fix that first. We cannot deploy our way around it.

AI engineering on Azure AI Foundry: what the landing zone is usually built for.
Cloud migration and VMware exit: the workloads that land in it.
Compliance architecture: how the policy set maps to SOC 2 and HIPAA.
Read: Landing Zone Blueprint: the reference architecture we deploy.

Questions we get

How long does a landing zone take?

Four weeks for a standard enterprise-scale deployment, from kickoff to a governed subscription your team can deploy into. Complex identity migrations or multi-region requirements extend that to six or eight, and we say so before you sign rather than after.

We already have Azure subscriptions. Is it too late?

No, and it is the most common starting point. We assess what exists, keep what is sound, and bring the rest under management groups and policy. Existing workloads are moved into the new structure without redeployment wherever possible.

Do we get the Terraform code?

Yes, in your own repository, from the first commit. We work in your Git organization, not ours. If you end the engagement in week two, you still hold everything produced up to that point.

What if we do not have anyone who can maintain it?

Then say so at the start and we scope differently, either a managed arrangement or a simpler architecture your team can actually run. Handing a sophisticated estate to a team that cannot maintain it is a failure, not a delivery.

Can it be deployed in Canadian regions only?

Yes. Region restriction is enforced by Azure Policy at the management group level, so it applies to every future subscription automatically rather than depending on anyone remembering.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.