Insights · Cloud Engineering · 18 August 2026 · 5 min
Build the landing zone before the first workload, not after the tenth.
The Azure foundation is cheap to build early and expensive to retrofit. What belongs in it, what does not, and how to keep it small.
The most common Azure estate we see was built one project at a time. The first team created a subscription and a virtual network. The second team copied it, slightly differently. By the tenth workload there are nine network designs, four ways to do identity, three logging configurations and nobody who can say what the monthly bill is for.
Retrofitting a foundation under running workloads is possible. It is also the most expensive way to get one.
What a landing zone is
A landing zone is the set of decisions that every workload should inherit rather than make:
| Decision | Made once in the landing zone |
|---|---|
| Where do subscriptions live? | Management-group hierarchy with policy inheritance |
| How does traffic flow? | Hub-and-spoke (or Virtual WAN) with central firewall, DNS and private endpoints |
| Who can do what? | Entra ID groups, role assignments per subscription, privileged access with approval |
| What is enforced? | Azure Policy: allowed regions, tagging, encryption, diagnostic settings, no public IPs |
| Where do logs go? | Central Log Analytics workspace with retention and access rules |
| What does it cost? | Budgets and alerts per subscription, tags that map to cost centres |
| How is it changed? | Terraform in a repository with a pipeline, reviews and state locking |
Everything in that table is boring, and that is the point. A workload team should be able to say “give me a subscription for this system” and receive one that already has networking, identity, policy, logging and cost tracking in place.
What does not belong in it
Landing zones fail in two directions. They are either too thin (a subscription and a wish) or too heavy (a platform team spends a year building a “cloud centre of excellence” and no workload arrives). The second failure is more expensive because it also costs credibility.
Keep these out of the initial landing zone:
- Kubernetes. It is a workload platform, not a foundation. Build it when the first containerised workload is real.
- A service catalog and self-service portal. Start with a Terraform module and a pull request. Add a portal when the module has been used twenty times.
- Multi-region and disaster recovery for everything. Decide per workload; the landing zone only needs to make it possible.
- Every Azure Policy in the built-in library. Start with the twenty that prevent expensive mistakes.
The minimum that is worth doing
A landing zone that fits in one Terraform repository and takes a small team two to four weeks:
- Management groups: platform, landing zones (corp, online), sandbox, decommissioned.
- Three platform subscriptions: identity, management (logging), connectivity (hub).
- A hub network with firewall, private DNS zones and a VPN or ExpressRoute stub.
- A subscription-vending module: creates a subscription, a spoke network peered to the hub, role assignments, budget, diagnostic settings and tags from a short input file.
- A policy set: allowed locations, required tags, diagnostic settings, deny public IPs on PaaS, deny unencrypted storage.
- A pipeline that plans on pull request and applies on merge, with state in a locked storage account.
That is enough to onboard the first workload the right way and every subsequent one the same way.
When it already went the other way
If you already have nine network designs, do not start a migration programme. Build the landing zone next to the existing estate, onboard new workloads into it from day one, and move existing workloads only when they have another reason to change. Within a year the old estate is a shrinking list instead of a growing one.
