Azure Landing Zone: A Practical Architecture Guide

A Sydney SaaS company can move from a handful of Azure subscriptions to a sprawling estate before its leadership team realises the operating model never kept up. Each delivery team creates its own hub-and-spoke network, cost tags vary by project, identity boundaries depend on local preferences, and the first serious audit exposes gaps that nobody owns.

That refactor is expensive in engineering time, migration risk and executive attention. An Azure landing zone should prevent that outcome by establishing the platform controls, regional decisions and workload boundaries before application teams start multiplying subscriptions. For Australian organisations, the design must go beyond a generic Cloud Adoption Framework summary. It needs explicit decisions about Australia East and Australia Southeast, sovereignty, data residency, policy enforcement and day-two operations.

Table of Contents

• Why Most Azure Estates End Up Refactoring Twice
• What an Azure Landing Zone Actually Is
• Platform Layer vs Application Layer in Plain Terms
  • What the platform team owns
  • What the workload team owns
  • The operating decision
• Choosing Your Build Path
• Phased Rollout From Assessment to Scale
  • Phase one covers discovery and readiness
  • Phase two builds the platform foundation
  • Phase three hardens governance
  • Phase four proves one workload
  • Phase five scales and optimises
• Governance and Security Mechanics That Actually Work
  • Build the hierarchy for policy inheritance
  • Keep access powerful but bounded
  • Make the network restrictive by default
  • Turn controls into operating practice
• Common Pitfalls and How to Recover From Them
  • Recover by matching the fix to the failure
• Reference Architectures for Enterprise NGO and Startup
  • The decision checklist

Why Most Azure Estates End Up Refactoring Twice

A 120-person SaaS team in Sydney added 14 subscriptions in 18 months to isolate environments. The result was three hub VNets, inconsistent tagging and a finance team unable to reconcile Azure spend reliably. The platform team then spent its time resolving exceptions instead of improving the foundation.

The shortcuts looked sensible at the time. One team chose a convenient region, another created a virtual network without checking the connectivity design, and a third granted permissions directly to individuals. Each choice worked locally. Together, they produced an estate that could not be governed consistently.

Practical rule: If a new subscription triggers a fresh debate about identity, routing, logging or approved regions, the platform is not ready.

A landing zone supplies the operating model before those decisions spread across teams. Microsoft describes the architecture as region-agnostic, but Australian teams still need to pin the Azure regions used by the platform. That means documenting the Australia East and Australia Southeast position, defining sovereignty and residency requirements, and designing policies before workloads arrive. Australian guidance also sets out how to extend a landing zone into a target region with hub VNets, routing, gateways and DNS. Australian Azure landing zone guidance makes that distinction explicit.

The warning signs are clear:

• Identity boundaries: Administrators receive broad permissions because no role model was agreed.
• Policy drift: Controls are applied manually or only after workloads are deployed.
• Subscription topology: Nobody can explain which subscriptions belong to each business unit or environment.
• Regional ambiguity: Teams choose locations without a documented Australian residency or sovereignty position.
• Cost blindness: Tags exist, but workload owners and finance teams cannot rely on them.

Treat these symptoms as an investment decision, not a documentation exercise. Build the platform layer in-house when you have durable Azure engineering capacity, clear ownership and time for policy, networking, identity and day-two operations. Use a partner when migration deadlines or application dependencies make that capacity uncertain. A team such as Continuum Solutions' cloud migration services can connect landing-zone design with dependency mapping, cutover sequencing and operational support.

What an Azure Landing Zone Actually Is

An Azure landing zone is the operating foundation that lets application teams deploy without reopening decisions about identity, networking, security, residency or cost control. It is pre-provisioned platform for subscriptions and workloads, with the controls and ownership rules established before production systems arrive.

A workable landing zone has four parts:

1. A management group hierarchy aligned with ownership, environments and compliance requirements.
2. Azure Policy assignments applied before deployment, with parameters for permitted regions, tags and required configuration.
3. A platform subscription structure connecting networking, identity, monitoring and security services to daily operations.
4. A written responsibility model naming who administers the platform, deploys workloads, approves exceptions and handles incidents.

The design should follow a two-layer operating model. The platform layer supplies shared guardrails and services. Application landing zones give each workload a bounded subscription or deployment area. Microsoft's Azure landing zone architecture documents this separation.

The office tower analogy is useful. The body corporate manages lifts, fire systems, building security and shared utilities. Tenants control their floor fit-out and business activity. A workload team should not disable a shared security control, yet it should not need central approval to make routine application changes within its boundary.

For Australian teams, region selection belongs in the landing zone design from the start. Microsoft's conceptual guidance is region-agnostic, but implementation must pin locations. A design may use Australia East as the primary region and Australia Southeast for paired-region recovery, subject to service availability, recovery objectives and sovereignty classification. Encode that decision in Azure Policy and infrastructure code. Do not rely on deployment conventions or team memory.

Sovereignty may require a stronger platform posture. Microsoft describes a Sovereign Landing Zone for customers seeking sovereign controls in Azure public cloud through the Sovereign Public Cloud. Microsoft's sovereign cloud update shows the shift from generic governance toward sovereignty-aware foundations.

The steering-committee version is direct: An Azure landing zone is a repeatable operating model that lets workload teams move quickly while preserving identity, security, Australian residency and financial control.

Platform Layer vs Application Layer in Plain Terms

A migration team can deploy an application quickly, then lose weeks fixing inconsistent identity, networking and policy controls across subscriptions. A landing zone prevents that by separating shared platform responsibilities from workload ownership. The platform layer governs the estate. The application layer runs the product.

What the platform team owns

The central platform team should operate the services that protect and connect workloads:

• Management groups: The hierarchy that applies governance across subscriptions.
• Azure Policy: Allowed locations, tags, diagnostics, security settings and compliance rules.
• Hub networking: Shared connectivity, Azure Firewall or an approved network virtual appliance, gateways, routing and DNS.
• Central monitoring: Log Analytics and security monitoring, including Microsoft Sentinel where the operating model requires it.
• Identity controls: Microsoft Entra ID integration, privileged access management and administrative role design.
• Shared developer services: Self-service portals, approved deployment templates and reusable infrastructure modules.

The platform team also owns the exceptions process. Every policy exemption needs an accountable owner, an expiry approach and a compensating control. Without those details, the exemption becomes a permanent gap in the security boundary.

For Australian organisations, the platform layer must pin deployment locations from the beginning. A design may use Australia East as the primary region and Australia Southeast for paired-region recovery, subject to service availability, recovery objectives and sovereignty classification. Encode the decision in Azure Policy and infrastructure code. Do not leave it to deployment conventions or team memory.

What the workload team owns

Application teams should control the resources required to deliver and operate their product:

• Application subscriptions or the workload resources assigned to them.
• Spoke networking and workload-specific network security groups.
• Workload identity, managed identities and application permissions.
• Application code, deployment pipelines and release configuration.
• Workload cost allocation, including tags for showback or chargeback.

Document the boundary in a RACI rather than inferring it from portal permissions. Disputes usually centre on Log Analytics ingestion costs, role assignments and private endpoints. The platform team can provide the workspace and DNS architecture. The workload team should decide what requires monitoring and which private services the application needs.

The operating decision

Choose the model that matches the operating team you have now. Microsoft's reference implementation provides a standard baseline. Terraform or Bicep gives your engineers greater control over topology, policy parameters and module composition, while leaving them responsible for testing and maintenance. A partner can shorten delivery, but internal owners still need to approve changes and run day-two operations.

The boundary should let workload teams make routine application changes without central approval, while preventing them from disabling shared security controls. Treat that separation as an operating rule, not merely an architecture diagram.

Choosing Your Build Path

There are three credible ways to build an Azure landing zone in Australia. The right choice depends on your network complexity, sovereignty requirements, IaC capability and tolerance for owning the result after go-live.

The Microsoft Cloud Adoption Framework reference implementation, accelerated by the ALZ accelerator, suits teams that want a policy-driven baseline without designing every component from scratch. It can be a practical route for a small internal team, but it may not fit a complex identity model, unusual connectivity pattern or tightly controlled Private Endpoint strategy.

Building with Terraform or Bicep gives your engineers control over management groups, hub-spoke design, policy modules and region pinning. That flexibility is valuable when the landing zone must integrate with existing platforms, but it isn't free. Your team must test module changes, manage state, review policy effects and maintain the design as Azure services evolve.

A partner-delivered deployment makes sense when the landing zone is blocking a migration or when the internal team understands the business but hasn't built Azure platform foundations before. The commercial risk is scope ambiguity. A fixed delivery price is useful only when the statement of work defines subscriptions, policies, network services, identity integration, documentation, testing and handover.

The cost table uses the delivery ranges supplied for this architecture decision, not a universal Azure price list. Azure consumption, security plans, connectivity and monitoring remain separate from implementation cost.

For a migration programme, I'd sequence the engagement around assess, design, build, prove and hand over. Cloud computing consulting from Continuum Solutions is one example of a partner-led route that can combine Azure architecture with migration planning and operational transition.

Don't select the partner path to avoid making decisions. Select it when you want experienced engineers to turn those decisions into tested infrastructure, documentation and a working operating model.

Phased Rollout From Assessment to Scale

Treat the landing zone as a sequence of gated deliverables, not a single deployment. Each gate should produce evidence that the controls work, the target Australian operating model is practical, and an accountable owner can run it.

Phase one covers discovery and readiness

During the initial assessment, inventory subscriptions, tenants, applications, identities, network dependencies, data classifications and current spend. Produce a cost baseline and a target subscription model tied to approved Australian regions, such as Australia East or Australia Central where the workload and service availability support that choice.

The exit criterion is a signed target-state design. It must define management groups, subscription ownership, connectivity, identity, logging, security responsibilities and the treatment of sovereign workloads. Record the decisions in a delivery backlog with named owners.

Phase two builds the platform foundation

Deploy the management-group hierarchy, hub virtual network, Azure Firewall or approved NVA, Bastion and Log Analytics workspace. Connect monitoring to the chosen security operating model, then test the path from administrative access through to alert handling.

Validate the target-region hub by deploying the VNet, gateway and DNS links through code. Confirm that policy blocks deployments outside Australia East or Australia Southeast when the workload classification requires regional restriction. For the hub VNet extension pattern, use Microsoft's Azure landing zone implementation guidance. The deliverable is a repeatable deployment and a test record, not merely a diagram.

Phase three hardens governance

Implement policy initiatives, role assignments, required tags and naming conventions through code. Parameters should enforce allowed locations and management-group placement for classifications that require Australian residency or sovereignty controls.

Derive each policy from a business control or compliance requirement. Microsoft's governance design guidance supports centralised baseline assignments and continuous compliance reporting. Test both denial and audit behaviour, document approved exceptions, and prove that policy results reach the people responsible for remediation.

Phase four proves one workload

Move one low-risk application into an application landing zone. Use it to test deployment pipelines, private connectivity, diagnostics, incident runbooks, backup, recovery and cost allocation. Choose a workload that exercises the controls future migrations will depend on, rather than one that bypasses them.

Require evidence from the application team and platform team before approving the next workload. Missing runbooks, unresolved policy exceptions or unclear ownership should stop the rollout.

Phase five scales and optimises

Repeat the subscription and workload pattern from month 4 onward. Add FinOps reviews, budget ownership and resilience testing, including controlled failure exercises where they improve operational confidence. Keep the platform layer stable while application teams consume approved patterns.

Close every phase against written evidence. A project date does not prove that a policy blocked an invalid region, a workload reached dependencies privately, or the on-call team knew how to respond.

For migration economics and planning discipline, compare the programme with cost considerations in an Australian migration assessment. The provider differs, but the planning principle holds. Foundation work changes the risk, effort and repeatability of every workload that follows.

Governance and Security Mechanics That Actually Work

An Australian team can have a polished Azure architecture and still lose control through weak inheritance, excessive privilege, or unowned exceptions. Build governance as a policy-first operating model with two layers: a platform layer that enforces shared controls, and application layers that consume approved patterns without bypassing them.

Build the hierarchy for policy inheritance

Start with the Tenant Root Group. Create an intermediate group for platform owners, then separate Identity, Management, and workload groups by environment, business unit, or sovereignty classification. The labels are less important than predictable inheritance, ownership, and a clear place to apply each control.

Assign baseline Azure Policy initiatives at the management-group scope. Cover approved SKUs, mandatory tags, diagnostic settings, and an Australian region allow-list for workloads that must remain in-country. Pin eligible workloads to approved Australian regions, and place subscriptions under the management group matching their sovereignty requirements. Microsoft's landing zone tailoring guidance describes this structure.

Make policy exceptions time-bound, approved, and recorded. An exception without an owner or expiry is a permanent bypass.

Keep access powerful but bounded

Use Microsoft Entra RBAC for administration, require multifactor authentication, and apply Conditional Access to users with Azure permissions. Assign roles at subscription or resource-group scope rather than management-group scope. Management groups should carry policy, while workload administrators retain enough autonomy to operate applications without changing inherited controls. Microsoft's landing zone identity guidance explains this separation.

Pair standing access with Privileged Identity Management and separately controlled break-glass accounts. Review assignments, record approvals, and test the emergency path before an incident exposes a failure.

Make the network restrictive by default

Use Private Endpoints for supported platform services, deny-by-default network security groups, controlled egress through the firewall, and Private DNS zones linked to the relevant hubs. Apply security plans according to the risk profile, then give a named owner responsibility for configuration and workload findings.

Turn controls into operating practice

Policy without remediation: Audit findings accumulate when nobody owns correction. Use remediation tasks and, where safe, DeployIfNotExists effects.

Over-broad administrator roles: Individual assignments survive staff changes. Use groups, PIM, and documented approval paths.

Unpriced observability: Central logging creates ingestion, retention, and analytics costs. Define the chargeback boundary before enabling it, and connect platform telemetry with enterprise application monitoring and debugging services when internal teams need operational support.

Private endpoint sprawl: Teams create conflicting DNS links and connectivity exceptions. Publish a supported module, naming standard, and request workflow.

Application monitoring belongs in the platform and application handover. Document telemetry ownership, alert thresholds, escalation paths, and response procedures. Azure-native diagnostics or approved third-party tools can support the model, but no tool compensates for unclear accountability.

Common Pitfalls and How to Recover From Them

A landing zone fails when it is treated as a diagram rather than an operating model. A successful deployment does not rotate privileged credentials, review policy exemptions, allocate logging costs, or tell a workload owner which private endpoint to use. Australian teams should run two connected layers: a governed platform layer with pinned regions and shared controls, and an application layer with clear workload ownership.

Recover by matching the fix to the failure

Subscriptions were created before management groups. The result is a flat estate where exceptions are handled locally. Rebuild the hierarchy, move subscriptions into the correct groups, and test policy inheritance before onboarding more workloads.

Azure Policy exists but changes nothing. Audit-only assignments often remain in place because deny effects create friction, while findings continue to accumulate. Use audit for discovery, then enforce mature controls. Apply DeployIfNotExists where Azure can safely configure the required setting.

Identity is centralised without privileged access discipline. One tenant can still carry excessive standing privilege. Protect and rotate break-glass accounts separately, use privileged access workstations where the risk justifies them, and review role assignments through PIM.

The platform subscription becomes a bottleneck. Centralising every service, SKU, and deployment decision slows application delivery and obscures ownership. Separate subscriptions by platform domain when scale or risk requires it, while keeping shared standards consistent.

Australian sovereignty is assumed rather than encoded. A developer can select an overseas default region and place data outside the intended boundary. Pin permitted locations with Azure Policy, classify workloads, and place subscriptions under the appropriate sovereignty management group.

Tags state intent but do not support allocation. Finance cannot trust showback when tags are optional or inconsistent. Require ownership and cost tags through policy, remediate existing resources, and make those fields part of provisioning.

The accelerator is applied directly to production. Default settings and policy effects can disrupt live workloads. Run it in a sandbox, inspect the generated topology and policy behaviour, then promote the tested configuration through code.

If the estate already consists of exceptions, do not rebuild it wholesale before mapping dependencies. Establish the target hierarchy, onboard one controlled workload, measure operational impact, and migrate subscription groups in an order that protects business services. The same discipline used to avoid common cloud mistakes in smaller organisations applies to a larger Azure estate. Assign named owners for platform controls, workload findings, telemetry, and remediation, or the recovery plan will fail at execution.

Reference Architectures for Enterprise NGO and Startup

Your organisation's scale should determine the landing-zone pattern, not an ambition to resemble a large enterprise. A platform that overwhelms a small team will be neglected, while a single-subscription model can leave a complex organisation with no meaningful control boundary.

The enterprise pattern supports multiple business units and stronger separation, but it demands a real platform operating team. The NGO pattern keeps the boundary manageable, with governance focused on approved Australian regions, access and spend. The startup pattern should avoid enterprise complexity until additional workloads, regulatory requirements, hybrid connectivity or organisational growth justify it.

These cost ranges are planning inputs supplied for the reference patterns, not guaranteed Azure bills. Consumption, data transfer, security services, support and application architecture can change the result substantially.

The decision checklist

Choose the enterprise pattern if you need business-unit isolation, hybrid connectivity, central security operations and workload-level financial accountability. Choose the NGO pattern when the team is small and the immediate requirement is dependable governance around a limited estate. Choose the startup pattern when one product team owns one primary workload and speed matters more than a complex management-group structure.

Take three actions this week:

1. Inventory every subscription, owner, region, workload and policy assignment.
2. Decide which workloads require Australian residency or sovereignty controls, then document the approved regions and exception process.
3. Choose an owner for the platform layer and obtain a design estimate that includes build, migration, testing, documentation and day-two support.

Continuum Solutions helps Australian organisations design Azure foundations, plan phased migrations, codify infrastructure and connect application monitoring to day-two operations. Visit Continuum Solutions to discuss an Azure landing zone that matches your workloads, governance needs and internal engineering capacity.