Why landing zones matter
A landing zone gives cloud teams a repeatable foundation before workloads arrive. It defines how identities, subscriptions, networks, policies, logging and security controls work together so every new environment starts from a known baseline instead of a fresh set of guesses.
Without one, growth looks fine for the first few subscriptions and then stops looking fine. Naming gets inconsistent, network peering turns into a tangle nobody fully understands, security findings surface months late because logging was never centralized, and every new team asks for access through a different process. None of that is a single failure. It is the compounding cost of never having agreed on a foundation in the first place.
What belongs in the foundation
A management group hierarchy comes first, because policy and access inheritance flow through it. Get the hierarchy wrong and every later policy assignment becomes a workaround. Subscription design follows: how workloads are isolated, which billing boundaries matter, and how many subscriptions a growing team can actually operate without the sprawl becoming its own management problem.
Identity and access are non-negotiable. Role-based access control, least-privilege assignments and a documented break-glass process for emergency access all need to exist before the first production workload lands. Networking decisions, hub-and-spoke versus Virtual WAN, private endpoints versus public access, DNS strategy, need to be made deliberately rather than inherited from whatever the first project happened to need.
Policy as code turns intent into enforcement: guardrails that block risky configurations automatically instead of relying on a reviewer catching them in a pull request. A shared Log Analytics workspace with a sane retention period gives security and operations teams one place to look instead of ten. Tagging standards make cost allocation and ownership answerable in seconds instead of a research project, and a backup and disaster recovery baseline means resilience is a default, not something bolted on after an incident.
Reference architectures are a starting point, not a finished design
Microsoft’s Cloud Adoption Framework landing zone accelerator is a genuinely useful starting point, but treating it as a finished design is a common mistake. The real decisions, how many management groups actually make sense for this organization, whether shared services live in a dedicated subscription, how regional the architecture needs to be, who owns policy exceptions when a workload legitimately needs one, are specific to the business, not generic. A landing zone copied wholesale from a reference architecture tends to carry assumptions that do not match the team that has to operate it.
How iNET SYSTEMS approaches it
We start with discovery: current-state environment, compliance requirements, team size and operational maturity. From there we design the target operating model, who owns what, how exceptions get approved, what “done” looks like for a compliant environment, before writing a single line of infrastructure code. The foundation is then built as reusable Terraform modules, piloted in a sandbox subscription, and rolled out in waves rather than a single high-risk cutover.
Common mistakes we see
The most expensive one is building the landing zone by hand through the portal instead of as infrastructure as code. It works until someone needs to reproduce it, audit it, or recover from a mistake, at which point the lack of a definition becomes the whole problem. Overcorrecting the other way, dozens of restrictive policies applied on day one, creates friction without much real security benefit and usually gets rolled back under pressure, which is worse than never having had it.
A missing subscription vending process is another recurring gap: without one, every new team requests access through a ticket, and the landing zone stops being self-service. And cost management left until the first surprising invoice arrives is a sign the foundation was built without FinOps in mind from the start.
Practical next step
Start by mapping business units, environments, compliance needs and ownership. From there, build the smallest landing zone that is secure, documented and ready to scale, and expand it deliberately as real workloads arrive rather than trying to anticipate every future need up front.