A landing zone is an operating model, not a subscription layout

Landing zone designs tend to be assessed on their diagrams. Two years later, the problems that surface are rarely topological. They are questions about who may create what, who pays for it, who approves an exception and how a standard changes.

Decisions that outlive the diagram

1. Subscription boundaries: whether they follow business units, environments or applications determines how cost and access are delegated for years.
2. Cost accountability: tagging enforced at creation, budgets assigned to named owners, and showback reported to people who can act on it.
3. Policy as code: standards encoded in Azure Policy rather than described in a document nobody reads at deployment time.
4. Exception process: a documented route to deviate, with expiry. Without one, teams deviate silently.
5. Change process for the platform itself: how a standard is proposed, reviewed and rolled out to existing workloads.

Right-size the starting point

A full enterprise-scale landing zone is appropriate for organisations with many workload teams and formal separation of duties. An organisation with two application teams and a shared operations function will spend more effort maintaining that structure than it recovers. Start with the smallest structure that satisfies current segregation, cost and compliance requirements, and design the expansion path explicitly.

Practical readiness checks

• Can you attribute last month spend to named owners without manual work?
• Can you evidence policy compliance without assembling it by hand?
• Is there a documented, time-bound route to request an exception?
• Does someone own the platform backlog, with time allocated to it?

If any answer is no, the gap is in the operating model rather than the architecture, and it will grow with the estate.