Landing zones: account structure, guardrails, network hub and identity
In short: A landing zone is a prepared, multi-account cloud environment with identity, guardrails, networking, logging and security already in place, so teams can deploy safely from day one. It is built from code and usually follows a provider reference such as AWS Control Tower or the Azure landing zone architecture.
Why build a landing zone?
When cloud adoption starts with one account and a credit card, problems grow quickly: everyone is an admin, logs are scattered, networks overlap and nobody knows who owns what. A landing zone fixes this up front. It is the foundation, built once and maintained as code, that every workload lands on.
Accounts (AWS), subscriptions (Azure) and projects (Google Cloud) are strong isolation boundaries. Using many of them limits the blast radius of a mistake or breach and makes cost allocation simple. Group them under organisational units or management groups so guardrails apply by purpose.
Guardrails
Guardrails are rules that keep every account within safe limits, whatever its owner does.
| Type | AWS example | Azure example |
|---|---|---|
| Preventive | Service control policy denying unapproved regions or disabling CloudTrail | Azure Policy Deny for disallowed locations or public IPs |
| Detective | AWS Config rules and Security Hub controls | Azure Policy Audit and Defender for Cloud recommendations |
| Proactive | CloudFormation hooks checking templates before deployment | Policy checks in deployment pipelines |
Keep preventive guardrails for the few things that must never happen, and use detective ones for the rest, so teams are not blocked unnecessarily.
Shared layers: identity, network, logging
- Identity: people sign in once through the corporate identity provider (IAM Identity Center, Entra ID) and receive roles per account. Break-glass accounts are documented and monitored.
- Networking: a hub (Transit Gateway or a hub VNet) holds shared firewalls, DNS and hybrid links; spokes connect to it. IP ranges are allocated centrally so nothing overlaps. See hybrid connectivity.
- Logging and security: a dedicated log archive account receives CloudTrail or activity logs; a security tooling account runs detection services with delegated admin rights.
- Account vending: new accounts are created by an automated process that applies the baseline, tags and budgets.
Tools and practical advice
Providers offer reference implementations: AWS Control Tower (with Landing Zone Accelerator for stricter needs), the Azure landing zone architecture from the Cloud Adoption Framework, and Google Cloud's enterprise foundations blueprint. All can be deployed with infrastructure as code such as Terraform.
- Agree the account or subscription structure and naming before building.
- Deploy the landing zone from code in a pipeline, never by hand.
- Start with a small set of strong guardrails, then add more as you learn.
- Test guardrails in a sandbox organisational unit first.
- Give a platform team clear ownership and a change process.
Tip: retrofitting a landing zone onto a messy estate is much harder than starting with one. Even a small organisation benefits from separate production, non-production and log accounts.
Practice
Why use many accounts or subscriptions instead of one?
Give one preventive guardrail a landing zone should include.
Where should audit logs from all accounts be stored?
Key takeaways
- A landing zone is a ready-made, secure multi-account foundation.
- Accounts and subscriptions are blast-radius boundaries.
- Guardrails are preventive, detective or proactive.
- Centralise identity, network hub, logging and security tooling.
- Build it as code and vend new accounts automatically.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.