Landing zones are not just templates — they're the architectural contracts that determine whether your cloud estate remains governable at scale or becomes an ungovernable sprawl by year three.
What is a Cloud Landing Zone?
A cloud landing zone is a pre-configured, scalable, and secure cloud environment that enables organisations to onboard workloads rapidly and consistently. It covers identity, networking, security, governance, and operational tooling — all established before the first workload arrives.
In a multi-cloud context, the challenge is amplified: each cloud provider has its own primitives, and the temptation to build three separate, optimised landing zones is strong. However, that approach creates silos, duplicates effort, and makes central governance almost impossible.
The Core Principles
After deploying landing zones across financial services, healthcare, and retail clients, I've distilled the design down to six durable principles:
Security by Default
Every resource born into the landing zone must inherit baseline security posture. No opt-in. Use deny-by-default policies and RBAC with least-privilege.
Everything as Code
Landing zone infrastructure must be 100% reproducible via IaC. Terraform modules with semantic versioning, stored in Git, deployed via pipeline.
Network Segmentation
Hub-and-spoke or VWAN on Azure, Transit Gateway on AWS. Enforce micro-segmentation from day one — retrofitting it later is a multi-year project.
Centralised Identity
Federate all cloud IAM to a single identity plane. Entra ID as the IdP with cross-cloud OIDC federation eliminates credential sprawl.
Observability First
Centralise logs, metrics, and telemetry to a SIEM from the start. Azure Monitor, CloudWatch, and Cloud Logging all feeding a unified SIEM.
Automated Onboarding
Subscription/account vending should be automated via a self-service portal or pipeline. Manual provisioning is a bottleneck and an error source.
Anti-Patterns to Avoid
Having reviewed dozens of landing zones across organisations at various stages of maturity, the same anti-patterns appear repeatedly:
- The "Hub Without Governance" Problem: Hub-and-spoke architecture deployed, but no Azure Policy or SCPs enforcing traffic routing. Spoke owners bypass the hub entirely.
- Long-lived credentials: Service principals with passwords stored in pipelines. Replace with Workload Identity Federation (WIF) and managed identities from day one.
- Monolithic Terraform: A single 10,000-line Terraform root module. Split into composable modules with clear boundaries: networking, identity, management, and workload.
- The "Cloud Native" Assumption: Assuming every workload will be containerised. Landing zones must support legacy lift-and-shift alongside cloud-native workloads.
The Terraform Module Strategy
For multi-cloud IaC at scale, I recommend a three-layer module library:
modules/
├── foundation/
│ ├── azure-management-group/
│ ├── aws-organizations-ou/
│ └── gcp-folder-structure/
├── networking/
│ ├── azure-hub-spoke/
│ ├── aws-transit-gateway/
│ └── gcp-shared-vpc/
└── security/
├── azure-policy-baseline/
├── aws-scp-baseline/
└── gcp-org-policy-baseline/Each module is independently versioned using semantic versioning. Breaking changes increment the major version. Modules are published to a private registry (Azure Artifacts or Terraform Cloud) and consumed via version constraints in landing zone root modules.
Cross-Cloud Identity Federation
The identity layer is the hardest to get right across clouds. The solution I've standardised on is using Microsoft Entra ID as the root identity provider, federated to AWS IAM Identity Centre and GCP Workforce Identity Federation via SAML 2.0 / OIDC. This means:
- Single user directory: no local cloud accounts
- Conditional Access policies enforced at the Entra layer before cloud access
- PIM-enabled just-in-time access for all privileged roles across clouds
- Unified audit trail aggregated to Sentinel from all three clouds
Conclusion
A well-designed multi-cloud landing zone is not a one-time project — it's a living platform that evolves with your organisation. The key is to get the governance, identity, and networking foundations right before onboarding workloads. The cost of retrofitting these foundations at scale is orders of magnitude greater than getting them right from day one.
If you're planning a multi-cloud landing zone for your organisation and would like to discuss the approach, feel free to get in touch.
20+ years of enterprise technology leadership across cloud, infrastructure, and digital workplace. Passionate about sharing practitioner knowledge and advancing the profession.