MICROSOFT
Azure landing zone: what you commit to on day one
5 min read
The Azure decisions worth agonising over on day one are the ones that are expensive to reverse later — subscription and management group structure, network address space, naming and identity boundaries — while most policy and cost tuning can safely wait until something is actually running.
Landing zone guidance has a way of expanding to fill the time available. There is a reference architecture for everything, and it is entirely possible to spend a quarter designing a platform before deploying a single workload.
The useful discipline is separating the decisions that are genuinely hard to undo from the ones that only feel urgent. The first list is short.
Hard to reverse: subscription and management group structure
Subscriptions are the boundary for policy, budget and, in practice, blast radius. Moving resources between them later is possible for some resource types and awkward for others, and it tends to happen at the worst time.
The structure should reflect how you will actually govern — usually some combination of environment, business unit and workload — rather than the org chart as it stands this quarter. Org charts change more often than platforms do.
Hard to reverse: network address space
Address space is the classic one. A range chosen because it was convenient becomes a constraint the moment you need to peer with another network, connect to on-premises, or merge with an organisation that made the same convenient choice.
Plan for more than you need, avoid the ranges everyone else uses by default, and write down which blocks are reserved for what before anything is deployed into them.
Hard to reverse: naming and tagging
Naming looks trivial and is not, because every automation, every report and every cost allocation downstream depends on it. Renaming resources after the fact ranges from tedious to impossible depending on the type.
The same applies to the tags that drive cost reporting. If owner, environment and cost centre are not applied from the start, the first cost review produces a large untagged bucket and an argument about whose it is.
- Subscription and management group layout
- Virtual network address space and reserved ranges
- Resource naming convention and the required tag set
- Identity boundaries: which directory, which privileged roles, which break-glass accounts
Safe to defer
Almost everything else. A comprehensive policy set written before any workload exists will be written against imagined workloads, and the first real deployment will break it.
Start with the policies that enforce the day-one decisions — allowed regions, required tags, naming — and add the rest as patterns emerge. The same applies to cost management: budgets and alerts are useful immediately, detailed chargeback is not useful until there is something to charge back.
What a sensible first phase produces
A structure you can deploy into, a network you will not have to renumber, a naming standard that is written down and enforced, identity with privileged access controlled, and enough policy to stop the obvious mistakes.
Not a finished platform. A platform you can start using without creating work for the version of yourself that exists in eighteen months.
Questions we get asked
How long does an Azure landing zone take to build?
The day-one decisions and an initial deployable structure are typically a few weeks of work, including the workshops to agree them. A platform that is fully governed, monitored and cost-managed develops over months, alongside the workloads that move into it.
What if we already have Azure resources deployed without a landing zone?
That is the common case. The approach is usually to build the structure alongside what exists, move new work into it, and migrate existing resources where the benefit justifies the disruption. Retrofitting everything at once is rarely worth it.
Should we follow Microsoft’s reference architecture exactly?
Use it as the checklist of decisions rather than the answer to them. The reference architecture is designed for organisations much larger than most, and adopting the full structure for a small estate produces management overhead with no corresponding benefit.