Azure landing zones without the platform team you do not have

The Azure landing zone reference architecture is good, and it is written for an organisation with a platform engineering team, a network team and a security operations function. A great many organisations adopting Azure have none of those — they have three or four infrastructure engineers who also run the on-premises estate.

For that reader, the honest advice is not “adopt the reference architecture” and it is certainly not “skip governance”. It is to identify which parts are expensive to retrofit and do those, and to defer the rest until there is someone to operate it.

The problem: what a landing zone is actually for

A landing zone is the environment a workload lands in, with identity, networking, governance, security and cost management already decided. The purpose is that a team deploying an application does not each time re-answer questions about where logs go, which regions are permitted, how the network connects and who can do what.

The failure mode without one is not usually a breach. It is an estate that grew a subscription at a time, where no two workloads are configured alike, nothing is tagged consistently, and nobody can answer basic questions about cost or exposure. Retrofitting governance onto that is considerably more work than starting with it.

Design choices: what is expensive to retrofit

This is the whole decision, so it is worth being explicit. Ordered by how much it hurts to change later.

The management group hierarchy — expensive. Moving subscriptions between management groups changes inherited policy and access simultaneously, which is exactly the kind of change that produces surprises. Get a simple shape right early.

Subscription boundaries — expensive. Not all resources can move between subscriptions, and some carry networking or regional constraints that make a move a rebuild.

Network address space — very expensive. Overlapping address ranges between your Azure space and your on-premises estate, or between two Azure environments you later need to connect, is resolved by renumbering. Plan the space before the first virtual network, with room for growth, and record it somewhere durable.

Naming and tagging — moderately expensive. Renaming resources is frequently not possible, so inconsistent names persist. Tags can be added retrospectively, but the cost data you wanted them for is already lost for the past period.

Log destination — moderate. Retroactively collecting logs is impossible. What was not collected is gone.

Policy assignments — cheap. Assign, audit, adjust. Genuinely low cost to change, which is why policy is the part to start with rather than the part to defer.

Role assignments — cheap individually. As covered in Azure RBAC scope decisions, the aggregate becomes expensive, but any single assignment is easy to change.

The subset worth doing first

For a small team, I would do these six things and defer everything else.

1. A shallow management group hierarchy. Something like a top-level group for the organisation, with platform, workloads and sandbox beneath it, and production and non-production under workloads if that distinction matters to you. Three levels is plenty. Resist modelling the org chart.

2. Separate subscriptions for production and non-production, at minimum. This is the cheapest blast-radius control available and it makes cost attribution trivial.

3. A planned address space. Written down, non-overlapping with on premises, with room for growth. Even if you start with one virtual network.

4. One Log Analytics workspace, with diagnostic settings enforced by policy. Use deployIfNotExists so it happens without anyone remembering, as described in Azure Policy as a guardrail. Collection cannot be applied retrospectively, which is what makes this urgent rather than important.

5. A small policy baseline in audit mode. Allowed regions, required tags, public network access, secure transfer. Audit first, deny later.

6. Microsoft Defender for Cloud enabled, at least the free tier, for the secure score and the recommendations. It is the cheapest way for a small team to get a prioritised list of what is wrong.

That is achievable in days rather than months, and it addresses every item in the expensive half of the table above.

What to defer, honestly

The reference architecture includes a great deal that a small team should not attempt on day one, because an unoperated control is worse than no control — it creates the belief that something is handled.

A hub-and-spoke network with Azure Firewall. This is a significant ongoing cost and a real operational commitment. Until you have multiple workloads needing shared connectivity and centralised inspection, it is premature. The considerations are in hub-and-spoke in Azure, including when it stops being the right answer.

Subscription vending automation. Excellent when you are creating subscriptions monthly. Pointless when you create two a year.

A full DevOps platform pipeline for infrastructure. Worth building toward. Not worth blocking your first workload on.

Dedicated connectivity and identity subscriptions. The separation is correct at scale. For three engineers, it is more subscriptions to administer than the isolation is worth. Start merged and split later — this is one of the cheaper things to change.

Comprehensive custom policy. The built-in definitions cover most of what a small estate needs. Writing custom policy is a maintenance commitment.

Implementation considerations

Use the accelerators, but read them. Microsoft publishes landing zone accelerators that deploy a full reference implementation. They are useful, and they deploy a great deal. For a small team, deploying everything and operating a fraction of it produces an estate you do not understand. Deploy the portions you have decided on.

Everything in version control, from the first resource. Bicep or Terraform, in a repository, even when a human runs it manually. The cost is small at the start and enormous to introduce later.

Do not model the organisation chart in management groups. Organisations reorganise; the hierarchy does not want to. Model by governance requirement — what needs the same policy — which is much more stable.

Decide the log retention and budget early. Log Analytics costs scale with ingestion, and an unconsidered diagnostic-settings policy applied estate-wide can produce a surprising bill. Set a daily cap while you learn the volume.

Revisit at the point of growth. The right trigger to adopt more of the reference architecture is a specific problem: a second team needing isolation, a shared connectivity requirement, a compliance obligation. Adopting it in anticipation is how small teams end up maintaining a platform instead of delivering workloads.

Validation

You have a working landing zone when you can answer these without investigation:

• Which subscription does a given workload live in, and why that one?
• Where do its logs go, and for how long are they kept?
• Who can deploy into it, and who can grant that access?
• What does it cost, and to which part of the business?
• Which policies apply to it, and what is currently non-compliant?

If any answer requires a conversation with a specific person, that is the next thing to fix.

Verification and limits

The Cloud Adoption Framework landing zone design areas, management group and subscription inheritance behaviour, and the policy and diagnostic-settings mechanisms referenced here were checked against current Microsoft documentation on 20 September 2026. The prioritisation and the deferral advice are my own judgement, stated as such, and they are deliberately a reduction of the reference architecture rather than a summary of it.

Nothing here was deployed for this article. Management group and subscription structure changes affect inherited policy and access at once — make them before workloads arrive where you can, and in a controlled window where you cannot. Accelerator content changes, so review what a given template deploys before running it.

References

• What is an Azure landing zone?
• Azure landing zone design areas
• Organize your resources with management groups
• Cloud Adoption Framework: govern