Azure landing zones for mid-sized companies: where to start

Many Azure estates in mid-sized companies started the same way: one subscription for a first project, then another, permissions granted case by case, a network built as needs arose. While the footprint stays small, that holds up. Then comes a larger migration, a security audit or a NIS2 requirement — and it turns out the foundations need rework.

A landing zone is exactly that: the foundations — organisation, identity, networking, security, governance — put in place before applications move in. Microsoft documents the reference architecture in the Cloud Adoption Framework as Azure Landing Zones. The good news: a mid-sized company does not need, and should not want, to deploy all of it on day one.

The decisions that shape everything else

Some choices are hard to reverse once applications are running. Make those first, and write them down:

• the management group hierarchy and how you split subscriptions;
• the network model (hub-and-spoke or Virtual WAN) and the IP address plan;
• the identity and access model: who administers what, with which privileges;
• the allowed regions and any data residency constraints;
• the infrastructure-as-code tooling and how deployments run.

Everything else — number of spokes, extra security services, automation — can evolve over time.

Management groups and subscriptions

Management groups let you apply access and policy to sets of subscriptions. A simple hierarchy based on the reference architecture works in most cases:

1. an organisation-specific root group (not the Tenant Root Group itself);
2. Platform: connectivity, identity and management subscriptions (logs, monitoring);
3. Landing zones: application subscriptions, often split into corp (internal apps connected to the corporate network) and online (internet-facing apps);
4. Sandbox: experimentation, isolated from the corporate network, with capped budgets;
5. Decommissioned: subscriptions being shut down.

For subscriptions, the useful rule is to treat each one as a unit of ownership and billing: one per application or business domain, with production separate from non-production. That is easier to secure, charge back and decommission than one large shared subscription.

Azure Policy: guardrails from day one

Policies assigned at management group level are what turn an architecture diagram into rules that are actually followed. A reasonable starting baseline: allowed regions, mandatory tags, no public IPs in corp landing zones, diagnostic settings pointing to the central log workspace, Defender for Cloud enabled.

Here is the built-in Allowed locations policy assigned to a management group in Bicep:

targetScope = 'managementGroup'

resource allowedLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'allowed-locations'
  properties: {
    displayName: 'Allowed locations'
    policyDefinitionId: tenantResourceId('Microsoft.Authorization/policyDefinitions', 'e56962a6-4747-49cd-b67b-bf8b01975c4c')
    parameters: {
      listOfAllowedLocations: {
        value: [ 'francecentral', 'westeurope' ]
      }
    }
  }
}

A practical tip: roll out restrictive policies in audit mode on existing resources first, measure the gaps, and switch to deny once exceptions are dealt with.

Networking: hub-and-spoke or Virtual WAN?

Both models centralise connectivity — to on-premises, to the internet, between applications — in a hub, with peered application networks (spokes). The main difference is how much of the management you hand over to Microsoft.

For most mid-sized companies operating in one or two regions, a well-designed hub-and-spoke remains the clearest choice. Whichever model you pick, the IP address plan deserves real thought: it must not overlap with your sites, partners or future acquisitions.

Identity: Entra ID as the control plane

In Azure, identity is the real perimeter. Before the first application lands:

• define RBAC roles per management group and subscription, assigned to Entra ID groups rather than individuals;
• enable Privileged Identity Management for privileged roles, with time-bound elevation;
• protect administrators with phishing-resistant MFA and Conditional Access;
• set up break-glass accounts excluded from Conditional Access, monitored and tested;
• prefer managed identities over secrets for applications.

Infrastructure as code: Bicep or Terraform, with AVM and ALZ

A landing zone clicked together in the portal drifts quickly and cannot be reproduced. It should be described in code, version-controlled and deployed through a pipeline.

Choosing between Bicep and Terraform mostly comes down to context: Bicep is Azure-native and has no state file to manage; Terraform suits teams that already use it or work across several clouds. Both are fully supported.

There is no need to start from a blank page. Microsoft maintains Azure Verified Modules (AVM), a library of supported, tested Bicep and Terraform modules, and an Azure Landing Zones accelerator that builds on them to deploy the hierarchy, policies and connectivity. These accelerators cover a lot of ground; the job is to configure them to the right level for your organisation rather than switching on everything they offer.

The most common mistakes

• Putting everything in one subscription, then having to move resources under pressure.
• Copying the full reference architecture for an organisation that doesn't need it — unnecessary cost and complexity.
• An improvised IP plan that overlaps with a site or subsidiary network.
• Owner rights handed out widely, with no PIM and no periodic review.
• Policies set straight to deny on an existing estate, blocking teams until someone disables them.
• Manual changes in the portal alongside IaC, so the real state drifts from the code.
• Skipping central logging at the start — you cannot rebuild logs that were never collected.

Getting started

A landing zone sized for a mid-market company can be built in a matter of weeks, as long as the structural decisions are made early and the initial scope stays reasonable. The goal is not to cover everything, but to lay foundations that can grow without being rebuilt.

To see where your current environment stands, take our maturity self-assessment: the "Platform & network" area covers exactly these topics. To design or rework your landing zone, let's talk.