HTML article · Talk to an experienced engineer

# Azure Landing Zones: what they actually need

What belongs in an Azure landing zone that an operations team can run — and what to leave out of the first release.

Published: 2026-04-18
Canonical: https://northark.ai/insights/azure-landing-zones-what-they-actually-need/

A landing zone is the set of subscriptions, identity, networking, logging and guardrails that make later Azure work boring. If those pieces are missing, every project invents its own hub, its own DNS hack, and its own “temporary” exception that never expires.

The first release should be small enough to operate. Management groups that match how you actually approve spend. A hub that carries hybrid connectivity, DNS and shared services. Spoke patterns that application teams can copy. Central logging that security can query. Backup and key management with named owners. Policy that blocks the mistakes you have already made, not a thousand unused initiatives.

What does not belong in v1: a perfect CAF diagram, twenty management groups for an organisation with three application teams, and custom policy at a density nobody can explain. Over-governance is how landing zones stall. Under-governance is how you get public storage accounts and mystery peering.

Identity is the usual failure point. Hybrid Entra ID, privileged access, break-glass, and workload identities need a design before the first production subscription is used. Networking is the second: address space, ExpressRoute or VPN, private DNS, and outbound internet paths. Get those two right and most other Azure services become configuration rather than invention.

Treat the landing zone as a product with a backlog. Version it. Document the exceptions. Review them. North Ark’s landing-zone work is successful when an internal team can add a spoke without calling a consultant for every subnet.

## Next step

Talk to an experienced engineer about how this environment is managed today. [Contact North Ark](https://northark.ai/contact/)