A Pragmatic Azure Landing Zone for AU Enterprise

Most landing zone projects I am asked to rescue share the same root cause: someone deployed the full Cloud Adoption Framework enterprise-scale reference on day one, and now nobody can change a policy without a war room. The reference architecture is a menu, not a mandate. For an Australian enterprise or government agency, the useful question is not "what does Microsoft's diagram contain" but "what is the smallest structure that lets teams ship safely, and can be tightened later without a re-platform".

This is a practitioner's view of that structure, grounded in delivery for regulated Australian organisations. It is opinionated about sequencing, because sequencing is where these programmes actually succeed or stall. Build the load-bearing walls first; the fit-out can wait.

Management group and subscription topology

Start with a management group hierarchy that reflects governance boundaries, not the org chart. Org charts change every reorganisation; your policy inheritance should not. A layout that survives contact with reality:

• A top-level intermediate management group under the tenant root (never apply policy at tenant root itself, and never deploy workloads into the root subscription).
• Platform group for shared services: identity, management/observability, and connectivity subscriptions.
• Landing zones group split into Corp (private, no direct internet ingress) and Online (internet-facing).
• A Sandbox group with deliberately loose policy for experimentation, and a Decommissioned group for subscriptions being retired.

Use one subscription per workload environment (prod, non-prod) as the default billing and blast-radius boundary. Resist the temptation to pack twenty apps into one subscription to "save on management"; subscription-level limits and RBAC scoping will bite you within a year. Subscriptions are free. Untangling them is not.

Identity with Entra ID

Identity is the real security perimeter, so it gets built before networking. Keep the platform tenant clean: break-glass accounts excluded from Conditional Access, phishing-resistant MFA for every human, and Privileged Identity Management for anything above Reader on production scopes. Standing owner access is the single most common finding in the assessments I run.

• Model access with Entra ID groups mapped to Azure RBAC, assigned at the management group or subscription scope, never per-resource.
• Use PIM eligible assignments with approval and justification for Contributor and Owner; time-bound activation, not permanent grants.
• Prefer managed identities and workload identity federation for pipelines over service principal secrets. If you are still rotating client secrets by hand, that is your first backlog item.
• Enforce Conditional Access with named locations and device compliance; for government, align sign-in controls to the Essential Eight maturity level you are targeting.

Networking: hub-and-spoke, kept boring

Hub-and-spoke remains the right default for Australian enterprise. Azure Virtual WAN is compelling once you have multiple regions and significant branch/SD-WAN connectivity, but for a first landing zone a traditional hub VNet with peered spokes is easier to reason about and cheaper to run. Choose Virtual WAN when transit routing complexity justifies it, not because it is newer.

Put the shared firewall, a DNS resolver, and any ExpressRoute or VPN gateway in the connectivity subscription's hub. Spokes carry only workload subnets and peer back to the hub. Force tunnel egress through the firewall so you get a single, auditable inspection and logging point.

• Delegate DNS with Azure Private DNS zones centralised in the hub, and use Private Endpoints for PaaS (Storage, Key Vault, SQL) so data-plane traffic never traverses the public internet.
• Plan address space with room for growth and non-overlapping ranges against on-premises; IP exhaustion mid-programme is a self-inflicted outage.
• Default-deny NSGs, with explicit allows; log flow to your central Log Analytics workspace.

Data residency and regional design

For Australian data sovereignty, pin resources to Australia East (Sydney) as primary and Australia Southeast (Melbourne) as secondary. Australia East is the fuller-featured region; Southeast lags on some services and lacks availability zones, so validate service and zone availability per workload rather than assuming symmetric parity.

Enforce region restriction with Azure Policy from the outset, not by convention. A single resource accidentally created in East US can turn into a data-residency incident and a very awkward conversation with a regulator. There are also the Azure Australia Central regions in Canberra for government workloads with specific classification and community-cloud requirements; only reach for them when a control genuinely mandates it, as service coverage is narrower again.

Policy-as-code

Policy is how a landing zone stays a landing zone. Assign a deliberately small initial set at the intermediate management group and let it inherit. Deny-effect policies that pay for themselves immediately:

• Allowed locations restricted to Australia East and Southeast (plus the Central regions only where needed).
• Deny public network access on Storage, SQL and Key Vault; require Private Endpoints.
• Require diagnostic settings to the central Log Analytics workspace via deployIfNotExists.
• Enforce mandatory tags (cost centre, owner, environment, data classification) with modify effects to backfill.

resource loc 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
  name: 'allowed-locations-au'
  properties: {
    policyDefinitionId: tenantResourceId('Microsoft.Authorization/policyDefinitions', 'e56962a6-4747-49cd-b67b-bf8b01975c4c')
    parameters: {
      listOfAllowedLocations: { value: [ 'australiaeast', 'australiasoutheast' ] }
    }
  }
}

Deploy policy through the same pipeline as everything else so definitions and assignments are reviewed, versioned and reversible. Roll out new deny policies in Audit effect first, review the compliance report, then flip to Deny. Enforcing untested policy across every subscription at once is how you break Friday afternoon deployments.

IRAP and Essential Eight for government

If you are delivering to government, the Essential Eight and the ISM are not a later phase; they shape the topology above. Practical translations that matter for a landing zone:

• Application control and patching maturity map to how you manage compute images and update rings; bake this into your golden image and Update Manager strategy early.
• Restrict administrative privileges aligns directly with PIM and just-in-time access already described.
• Centralised logging with defined retention supports both monitoring maturity and IRAP evidence; set retention deliberately rather than accepting defaults.
• Treat your policy compliance dashboard and RBAC assignments as audit artefacts. An IRAP assessor will ask how controls are enforced, not whether they are documented in a wiki.

Do not attempt to certify an environment you cannot describe as code. The single biggest accelerant to an IRAP assessment is being able to point at a repository that deterministically produces the assessed configuration.

Cost governance

Governance without cost visibility gets overruled by finance within two quarters. Wire it in at bootstrap: tagging enforced by policy, budgets with action groups per subscription, and Cost Management exports to a workspace teams can actually query. Give engineering teams their own cost view; accountability follows visibility.

Landing zone as code: Bicep or Terraform

Both work. Choose Terraform if you have multi-cloud or existing HashiCorp muscle and want a mature module ecosystem; choose Bicep if you are Azure-only and want the tightest, lowest-friction alignment with the platform and its API versions. What matters far more than the tool is discipline: everything through pipelines, remote state or deployment stacks, mandatory review, and no portal ClickOps in production. A portal change that nobody can reproduce is technical debt with interest.

What to do first, and what to defer

1. 01First: management group hierarchy, platform subscriptions, Entra ID hardening with PIM, remote state and pipelines.
2. 02Next: hub networking, central logging, the minimal deny-policy set in Audit then Deny, and subscription vending for the first real workload.
3. 03Later: Virtual WAN migration, advanced network inspection, reservations, fine-grained charge-back, and broader policy coverage as teams mature.
4. 04Never on day one: the entire enterprise-scale reference deployed verbatim, standing privileged access, or purchasing commitments before you have usage data.

A landing zone is a product with a backlog, not a project with a finish line. Ship the load-bearing structure, prove it with one real workload, and let the governance tighten as the organisation's cloud maturity catches up. The teams that treat it that way are the ones still moving quickly two years in.