Azure and Cloud

Landing Zones as Code: A New Environment Should Be a Pipeline Run

HL
Harry Le
4 min read
If standing up a new environment takes your organisation a fortnight of tickets, the platform is the bottleneck. What a landing zone built as code changes, in practice.

Here is a test of a cloud platform that has nothing to do with architecture diagrams. A delivery team needs a new environment for a project starting Monday. How long does it take, and how many people have to touch it?

In organisations where the answer is a fortnight and five teams, the cloud has faithfully reproduced the data centre's bureaucracy at a higher hourly rate. 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 subtle differences surface later as the production incident that cannot be reproduced in test.

What a landing zone actually is

A landing zone is the prepared ground an application lands on: 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, and the references are good starting points. The decision that matters is not which reference to follow but how the landing zone is built: by hand, or as code.

Built as code, in Terraform or Bicep, the landing zone is a repository. A new environment is a parameter file and a pipeline run: perhaps twenty minutes, one approval, and the result is identical to every sibling environment by construction. The platform team reviews pull requests instead of processing tickets, which is a better use of scarce people and leaves an audit trail as a side effect.

Guardrails instead of gates

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 buckets, enforce encryption, restrict regions for data residency, and cap what a workload can spend, all applied automatically to every environment because they are part of the code.

Gates slow everyone down to catch the rare bad actor. Guardrails let everyone move and make the bad configuration unrepresentable. Teams ship faster on the guardrailed platform, and the security posture is stronger, not weaker, because policy coverage is total rather than dependent on someone remembering to check.

Recovery becomes a rebuild

The least appreciated benefit shows up on the platform's worst day. When an environment is hand-built, recovering it means archaeology: what was configured, by whom, and why. When the platform is code, recovery is a rebuild from the repository. The same is true of the audit that asks how production is configured; the honest answer is a git history rather than a series of interviews.

Starting from an existing estate

Almost nobody starts from a blank page, and the good news is that a landing zone does not require one. The pattern we use on existing estates is to build the coded landing zone alongside, land new workloads on it from day one, and migrate existing workloads opportunistically, when they are touched for other reasons. Within a few quarters the coded platform is simply where things live, and the hand-built estate has shrunk to a decommissioning list.

Our Azure and cloud engineering practice builds landing zones as code on Azure and AWS, and hands them over with the pipelines, not just the diagrams.

Harry Le is a cloud engineer at Coder Trove.