Multi-Cloud Landing Zones & Governance Handbook

What Is a Landing Zone

A landing zone is a pre-configured, multi-account cloud environment that enforces security, identity, network, and compliance baselines before any application workload lands. It is infrastructure-as-policy: the goal is to make the right thing the easy thing.

Core Outcomes a Landing Zone Must Deliver

• Account isolation between workloads and environments
• Consistent identity and least-privilege access controls enforced by default
• Network segmentation with controlled egress and ingress
• Enforced security guardrails — both preventative and detective
• Audit trails and observability from day one, not retrofitted
• Self-service account onboarding for teams without bypassing controls

Account / Subscription / Project Structure

Organize cloud accounts into an organizational hierarchy that reflects risk, compliance, and team boundaries — not feature boundaries.

Recommended Hierarchy

Structural Rules

• One account/subscription per environment per workload boundary — no mixing
• Security and log archive accounts owned by the platform team; never delegated
• Sandbox accounts must have hard billing caps and auto-expiry policies
• Never mix production and non-production workloads in the same account
• All new accounts created through the vending machine pipeline, never the console

Identity & Access Hierarchy

Core Principles

• Centralize IdP — never create cloud-local users for humans
• Use short-lived credentials; eliminate long-lived access keys entirely
• Apply least privilege at every layer: org, account, resource, and action
• Separate duty between platform team (account management) and application teams (workload IAM)
• MFA required for all human console access without exception

Role Tier Structure

Network Foundations

Hub-and-Spoke Topology

All spoke VPCs/VNets connect to a hub that owns shared services. Spokes never peer directly with each other.

Egress Control Standards

IP Addressing Standards

• Allocate non-overlapping RFC 1918 ranges per environment tier at landing zone creation
• Reserve a /16 per tier to allow future spoke growth without re-addressing
• Maintain a central IPAM record (AWS VPC IPAM, Azure VNet Manager, or equivalent)
• Never reuse CIDR ranges previously routed to on-premises
• Enable VPC/VNet flow logs on all subnets at creation time, not retroactively

Security Baselines

Security baselines are guardrails the landing zone enforces on every account automatically. Preventative guardrails block non-compliant actions; detective guardrails alert on non-compliant state.

Preventative Guardrails

Detective Guardrails

Mandatory Logging

All accounts must ship the following to the centralized log archive account from day one:

• Management plane / audit events (CloudTrail, Activity Log, Cloud Audit Logs)
• VPC / VNet flow logs
• DNS query logs
• Authentication events: login, role assumption, privilege escalation
• Config change events

DNS & Connectivity Standards

DNS Architecture

• Deploy private hosted zones per VPC/VNet; internal services resolve by name, never by IP
• Central DNS resolvers in hub VPC/VNet handle cross-spoke and on-premises resolution
• Internal names must not resolve from the public internet (no split-horizon leakage)
• DNS over HTTPS is not permitted for workloads — all queries route through the controlled resolver

Private Endpoint Policy

• All PaaS services (object storage, databases, queues, key management) must use private endpoints
• Disable the public endpoint on every PaaS resource after the private endpoint is confirmed healthy
• Private endpoint DNS entries must be registered in the central private zone automatically at creation
• Do not rely on manual DNS record management — automate via IaC or event-driven pipeline

Cloud-Native Landing Zone Tooling

AWS: Control Tower + Account Factory for Terraform

• AWS Control Tower provides pre-built OU structure, SCPs, Config rules, and Account Factory for self-service provisioning
• Extend with Account Factory for Terraform (AFT) for IaC-managed account vending with customizations
• Deploy AWS Security Hub aggregator in the security account to consolidate cross-account findings
• Enroll all new accounts via Control Tower Account Factory — never create accounts manually in the console

Azure: Azure Landing Zones (ALZ)

• Microsoft reference architecture at Azure/ALZ-Bicep covers management groups, policies, hub networking, and monitoring
• Management group hierarchy: Root → Platform → Landing Zones → Sandbox
• Built-in policy initiatives enforce logging, Defender for Cloud, encryption, and region restrictions automatically
• Deploy via Azure DevOps or GitHub Actions pipeline using Bicep or Terraform modules, not the portal

GCP: Cloud Foundation Fabric

• Google Cloud Foundation Fabric (GoogleCloudPlatform/cloud-foundation-fabric) is the reference Terraform implementation
• Resource hierarchy: Organization → Folders (per environment) → Projects
• Enforced via Org Policy Constraints applied at folder level, inherited by all projects
• Use GCP Project Factory (Terraform) for self-service project vending with guardrail inheritance

Patterns Common to All Providers

Governance Operating Model

A landing zone without a governance loop decays. Establish clear ownership and a review cadence before day one.

Role Ownership

Review Cadence

Exception Process

1. Application team submits exception request with business justification and compensating controls
2. Security team reviews and classifies as accepted risk or rejected within 5 business days
3. Accepted exceptions are time-boxed (maximum 90 days) and tracked in a risk register
4. Exceptions automatically expire; teams must re-justify to extend

Cloud Mappings

Implementation Checklist

Organization & Structure

• Root organization / tenant created and documented
• OU / management group hierarchy matches security domains (Security, Infrastructure, Workloads, Sandbox)
• Account vending machine pipeline operational — no manual account creation
• Break-glass account exists, stored in secrets manager, alerts on every use
• Sandbox accounts have billing caps and auto-expiry configured

Identity & Access

• All human access via federated SSO — no cloud-local users for humans
• MFA enforced for all human access without exception
• No long-lived access keys for humans or CI/CD pipelines
• CI/CD pipelines use OIDC workload identity federation
• Workload runtime uses instance profile / managed identity / WIF
• Quarterly access review scheduled and owned

Network

• Hub VPC/VNet deployed in dedicated infrastructure account
• Non-overlapping CIDR ranges allocated and recorded in IPAM
• Flow logs enabled on all VPCs/VNets at creation
• All internet egress proxied through centralized firewall
• Spokes do not peer directly with each other
• Private endpoints deployed for all PaaS services in production
• Private DNS zones registered and resolvable from all spokes

Security Baselines

• SCP / Azure Policy / Org Policy applied at root preventing public storage
• Encryption at rest required by policy for all new storage resources
• Allowed regions restricted by policy
• All accounts enrolled in Security Hub / Defender for Cloud / Security Command Center
• Centralized log archive account operational; retention policy enforced (1 yr hot / 7 yr cold)
• Alert configured for root / global admin login activity

Governance

• Platform, Security, and FinOps ownership documented and acknowledged
• Compliance dashboard visible to platform and security teams continuously
• Exception process documented and accessible to application teams
• Review cadence (quarterly, semi-annual, annual) scheduled in team calendar
• Landing zone version upgrade process defined and owned