An Azure landing zone built as code, in Terraform or Bicep, turns a new environment into a parameter file and a pipeline run: perhaps twenty minutes and one approval, with a result identical to every sibling environment. Built by hand, the same environment can take a fortnight and five teams.
In organisations where a delivery team waits that fortnight, the cloud has reproduced the data centre's ticket queues. The subscription request goes to one queue, networking to another, identity to a third, and the resulting environment is subtly different from the last one because each was hand-assembled. Those differences surface later as the production incident that cannot be reproduced in test.
A landing zone is the prepared foundation an application is deployed onto: subscription structure, network topology, identity and access, policy guardrails, logging and cost tagging, all decided once and applied consistently. Microsoft and AWS both publish reference architectures for this, including the Azure landing zone guidance in Microsoft's Cloud Adoption Framework, and they are good starting points. The decision that matters most is how the landing zone is built: by hand, or as code.
Built as code, the landing zone is a repository. The platform team reviews pull requests in place of processing tickets, which is a better use of scarce people and leaves an audit trail as a side effect.
The cultural shift matters more than the tooling. A hand-built platform protects itself with gates: requests, reviews, waiting. A coded platform protects itself with guardrails: policies that prevent public storage, enforce encryption, restrict regions for data residency, and cap what a workload can spend, applied automatically to every environment because they are part of the code.
Gates slow everyone down to catch the rare bad actor. Guardrails let teams move and stop a bad configuration from being deployed at all. Teams ship faster on the guardrailed platform, and the security posture is stronger, because policy applies to every environment without depending on someone remembering to check.
The least appreciated benefit shows up on the platform's worst day. Recovering a hand-built environment means reconstructing what was configured, by whom, and why. When the platform is code, recovery is a rebuild from the repository. The same applies when an auditor asks how production is configured: the answer is the git history, with no series of interviews required.
Almost nobody starts from a blank page, and a landing zone does not require one. On existing estates we build the coded landing zone alongside, land new workloads on it from day one, and migrate existing workloads when they are touched for other reasons. Within a few quarters the coded platform is where things live, and the hand-built estate has shrunk to a decommissioning list, which our post on cloud migration decommissioning deals with.
Our Azure and cloud engineering practice builds landing zones as code on Azure and AWS, and hands them over with the pipelines as well as the diagrams.
A subscription is a single billing and access boundary. A landing zone is the structure around your subscriptions: networking, identity, policy, logging and tagging applied the same way to each.
Either works. Bicep is Azure-only and maintained by Microsoft; Terraform also covers AWS and other providers, which suits estates that span more than one cloud.
No. Build the landing zone alongside, put new workloads on it, and move existing workloads across when they are changed for other reasons.
Yes. Every change is a reviewed pull request, so the full configuration history sits in source control.
Harry Le is a cloud engineer at Coder Trove.