Multi-Cloud Landing Zone Design: An Azure, AWS, and Google Cloud Checklist
A landing zone is the governed foundation in which cloud workloads are deployed and operated. Azure, AWS, and Google Cloud use different resource models and services, but architecture teams face the same core decisions: ownership boundaries, identity, network topology, policy, evidence, cost accountability, and a repeatable path for onboarding workloads. The goal is not to make three clouds look identical. It is to create a coherent operating model while preserving the native strengths and constraints of each platform.
1. Define why each cloud is in scope
Start with workloads and business constraints rather than a blanket multi-cloud mandate. Record the capability, customer, regulatory, resilience, commercial, or acquisition requirement that places a workload on a particular provider. This prevents duplicate platforms from becoming an unmanaged default.
For each workload, name the accountable owner, data classification, recovery expectation, geographic requirements, dependencies, and exit considerations. A cloud decision should be reviewable as part of architecture governance, not hidden inside a deployment ticket.
- Workload purpose and business owner
- Cloud-placement rationale and decision date
- Data, residency, resilience, and recovery requirements
- Dependencies, portability needs, and exit constraints
2. Design the resource hierarchy before workloads arrive
Decide how organizational units, management groups, subscriptions, accounts, folders, and projects will reflect ownership and policy boundaries. Keep the hierarchy understandable enough for access reviews, cost allocation, incident response, and automated provisioning.
Azure separates centralized platform landing zones from application landing zones. AWS Control Tower uses a multi-account structure with organizational units and shared audit and log-archive capabilities. Google Cloud landing-zone guidance places similar emphasis on resource hierarchy and centralized foundations. Use those native constructs deliberately instead of forcing one provider’s hierarchy onto another.
- Platform, security, shared-service, sandbox, and workload boundaries
- Production and non-production separation
- Naming, tagging, labels, and ownership metadata
- Automated subscription, account, or project provisioning
3. Establish identity and privileged-access boundaries
Choose the workforce identity source, federation pattern, workload-identity model, and emergency-access process before enabling broad self-service. Map job responsibilities to roles and keep persistent administrative access narrow.
NIST Zero Trust guidance treats identity, devices, workloads, and resources as part of an end-to-end access model rather than trusting network location alone. Apply that principle through explicit authentication, short-lived credentials where supported, least-privilege authorization, privileged-access review, and logs that connect actions to accountable identities.
- Federation and single sign-on architecture
- Human, service, workload, and automation identities
- Privileged roles, approval paths, and emergency access
- Credential rotation, session controls, and access-review evidence
4. Choose network and data boundaries from traffic requirements
Document which workloads must communicate, which paths require inspection, where private connectivity is needed, and how on-premises, partner, internet, and cross-cloud traffic will be handled. Avoid a single flat network that turns convenience into uncontrolled reachability.
Google Cloud documents several landing-zone patterns, including environment-specific Shared VPC and hub-and-spoke designs. The useful lesson across providers is to select topology from explicit connectivity and control requirements, then test routing, name resolution, egress, inspection, and failure behavior before production onboarding.
- Environment and workload segmentation
- Ingress, egress, private service, and hybrid-connectivity paths
- DNS, certificate, address-space, and firewall ownership
- Data classification, encryption, key management, and transfer controls
5. Turn governance into deployable controls and evidence
Translate policy into versioned controls that can be tested and released. Define required logging, approved regions and services, encryption expectations, backup coverage, vulnerability processes, public-access restrictions, and exception handling. Preventive controls should be paired with detective visibility so operators can understand both blocked actions and drift.
AWS Control Tower distinguishes preventive and detective controls within its landing-zone model, while Azure emphasizes policy-driven governance inherited through its hierarchy. Across platforms, record the control objective, implementation, owner, evidence source, exception process, and review cadence rather than relying on an unlabeled collection of rules.
- Central audit, security, network, and application logging
- Policy-as-code and infrastructure-as-code repositories
- Control ownership, evidence retention, and exception workflow
- Budgets, quotas, anomaly detection, and cost-allocation reporting
6. Operate the landing zone as an internal platform
A landing zone should provide a supported path for teams to deploy safely: documented workload patterns, automated environment creation, approved modules, observability defaults, security checks, and a clear support model. Standardization is valuable when it removes repeated decisions without preventing justified workload-specific design.
Validate the platform with representative workloads and failure scenarios. Test identity, network reachability, logging, policy enforcement, backup and restore, incident access, cost ownership, and teardown. Maintain a roadmap for provider changes and control improvements so the foundation can evolve without leaving workload teams on incompatible versions.
- Published workload-onboarding contract and service catalog
- Reusable, versioned deployment modules
- Acceptance tests and operational readiness review
- Upgrade, deprecation, incident, and platform-support procedures