Multi-CloudArchitectureadvanced

Multi-Cloud Landing Zones

Guide to designing landing zones across AWS, Azure, GCP, and OCI covering account structure, network hub-and-spoke topology, centralized logging, security guardrails, and infrastructure as code.

CloudToolStack Team26 min readPublished Mar 14, 2026

Prerequisites

Experience managing cloud environments at an organizational level
Understanding of IAM, networking, and logging across at least one provider
Basic Terraform knowledge for infrastructure as code examples

Multi-Cloud Landing Zones

A landing zone is the foundational architecture that establishes the account structure, networking topology, identity management, security guardrails, and operational tooling for a cloud environment. It is the "first thing you build" before deploying any workloads. A well-designed landing zone ensures consistent governance, security compliance, cost management, and operational efficiency from day one.

Every cloud provider has its own landing zone framework: AWS Landing Zone / Control Tower, Azure Landing Zones (Enterprise Scale), GCP Cloud Foundation Toolkit, and OCI Landing Zones. While the concepts are similar, the implementation details differ significantly because each provider has a different resource hierarchy, policy model, and networking architecture.

This guide covers the architectural patterns for each provider, how to structure accounts, subscriptions, and projects, network hub-and-spoke topologies, centralized logging and monitoring, security baseline configuration, and practical Terraform examples for automating landing zone deployment. We also discuss strategies for organizations that need to maintain consistent landing zone patterns across multiple clouds.

Why Landing Zones Matter

Without a landing zone, teams create accounts and resources ad hoc, leading to inconsistent security configurations, ungoverned spending, networking conflicts, and operational blind spots. Retrofitting governance onto an existing environment is 10x harder than designing it in from the start. Every organization above a few dozen cloud resources should invest in a proper landing zone.

Resource Hierarchy Comparison

Level	AWS	Azure	GCP	OCI
Top Level	Organization	Tenant (Entra ID)	Organization	Tenancy
Grouping	Organizational Units (OUs)	Management Groups	Folders	Compartments (nested)
Workload Boundary	Account	Subscription	Project	Compartment
Resource Container	Account (flat)	Resource Group	Project (flat)	Compartment (nested)
Policy Scope	SCP at OU/Account	Azure Policy at MG/Sub/RG	Org Policy at Org/Folder/Project	IAM Policy at Compartment
Nesting Depth	5 levels of OUs	6 levels of MGs	10 levels of Folders	6 levels of Compartments

AWS Landing Zone Architecture

AWS recommends using AWS Control Tower to set up a multi-account landing zone. Control Tower automates the creation of a well-architected multi-account environment with guardrails, logging, and identity management. The core architecture uses dedicated accounts for security, logging, shared services, and workloads.

Recommended AWS OU Structure

AWS Organization Structure

Organization Root
├── Security OU
│   ├── Security Tooling Account (GuardDuty, Security Hub, Config)
│   └── Log Archive Account (CloudTrail, Config logs, VPC Flow Logs)
├── Infrastructure OU
│   ├── Network Hub Account (Transit Gateway, DNS, VPN/DX)
│   └── Shared Services Account (CI/CD, artifact repos, AMI factory)
├── Workloads OU
│   ├── Production OU
│   │   ├── App-A Production Account
│   │   └── App-B Production Account
│   └── Non-Production OU
│       ├── App-A Dev Account
│       ├── App-A Staging Account
│       └── App-B Dev Account
├── Sandbox OU (experimentation, limited budget)
│   └── Developer Sandbox Accounts
└── Suspended OU (decommissioned accounts)

bash

# Enable AWS Control Tower (via console recommended, CLI for reference)
# Control Tower creates: Management Account, Log Archive, Audit Account

# Create an OU
aws organizations create-organizational-unit \
  --parent-id r-root \
  --name "Workloads"

# Create a new account in the organization
aws organizations create-account \
  --email "app-a-prod@example.com" \
  --account-name "App-A Production"

# Move account to the correct OU
aws organizations move-account \
  --account-id 111111111111 \
  --source-parent-id r-root \
  --destination-parent-id ou-xxxxx-workloads

# Apply a Service Control Policy (guardrail)
aws organizations create-policy \
  --name "DenyLeaveOrganization" \
  --type SERVICE_CONTROL_POLICY \
  --content '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }]
  }'

# Attach SCP to an OU
aws organizations attach-policy \
  --policy-id p-xxxxxxxx \
  --target-id ou-xxxxx-workloads

Azure Landing Zone Architecture

Azure's Enterprise Scale Landing Zone uses management groups to organize subscriptions, Azure Policy for governance, and a hub-and-spoke network topology. Microsoft provides reference architectures through the Cloud Adoption Framework (CAF) and deployable Terraform/Bicep modules.

Azure Management Group Structure

Tenant Root Group
├── Platform
│   ├── Management (Log Analytics, Automation, Sentinel)
│   ├── Identity (Domain Controllers, Entra ID Connect)
│   └── Connectivity (Hub VNet, ExpressRoute, Firewall, DNS)
├── Landing Zones
│   ├── Corp (internal apps, private endpoints)
│   │   ├── App-A Production Subscription
│   │   └── App-B Production Subscription
│   └── Online (internet-facing apps)
│       ├── Web-App-A Subscription
│       └── Web-App-B Subscription
├── Sandbox (developer experimentation)
│   └── Developer Subscriptions
└── Decommissioned

bash

# Create management groups
az account management-group create --name "Platform" --display-name "Platform"
az account management-group create --name "LandingZones" --display-name "Landing Zones"
az account management-group create --name "Corp" --display-name "Corp" \
  --parent "LandingZones"
az account management-group create --name "Online" --display-name "Online" \
  --parent "LandingZones"

# Move a subscription into a management group
az account management-group subscription add \
  --name "Corp" \
  --subscription SUBSCRIPTION_ID

# Apply Azure Policy at management group scope
az policy assignment create \
  --name "require-tag-environment" \
  --display-name "Require Environment Tag" \
  --scope "/providers/Microsoft.Management/managementGroups/LandingZones" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99" \
  --params '{"tagName": {"value": "Environment"}}'

# Deploy Azure Landing Zone accelerator (Terraform)
# git clone https://github.com/Azure/terraform-azurerm-caf-enterprise-scale
# cd terraform-azurerm-caf-enterprise-scale
# terraform init && terraform apply

GCP Landing Zone Architecture

GCP uses an organization, folders, and projects hierarchy. The Cloud Foundation Toolkit provides Terraform modules for deploying a well-architected foundation. GCP's Shared VPC model allows a centralized networking team to manage VPC networks while granting projects access to specific subnets.

GCP Folder Structure

Organization (example.com)
├── Common Folder
│   ├── networking-host-project (Shared VPC host)
│   ├── logging-project (centralized logs)
│   ├── security-project (SCC, KMS, Secret Manager)
│   └── cicd-project (Cloud Build, Artifact Registry)
├── Production Folder
│   ├── app-a-prod (service project, attached to Shared VPC)
│   └── app-b-prod (service project)
├── Non-Production Folder
│   ├── app-a-dev (service project)
│   ├── app-a-staging (service project)
│   └── app-b-dev (service project)
├── Sandbox Folder (developer experimentation)
│   └── developer-sandbox-projects
└── Archive Folder (deprecated projects)

bash

# Create folders
gcloud resource-manager folders create \
  --display-name="Common" \
  --organization=ORG_ID

gcloud resource-manager folders create \
  --display-name="Production" \
  --organization=ORG_ID

gcloud resource-manager folders create \
  --display-name="Non-Production" \
  --organization=ORG_ID

# Create a project in the Production folder
gcloud projects create app-a-prod \
  --folder=PROD_FOLDER_ID \
  --name="App A Production"

# Set organization policies (guardrails)
gcloud resource-manager org-policies set-policy \
  --organization=ORG_ID policy.yaml

# Restrict allowed regions
gcloud org-policies set-policy --organization=ORG_ID - << 'EOF'
constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - in:us-locations
    - in:eu-locations
EOF

# Disable external IP on VMs (force private networking)
gcloud org-policies set-policy --organization=ORG_ID - << 'EOF'
constraint: constraints/compute.vmExternalIpAccess
listPolicy:
  allValues: DENY
EOF

# Set up Shared VPC
gcloud compute shared-vpc enable networking-host-project
gcloud compute shared-vpc associated-projects add app-a-prod \
  --host-project=networking-host-project

OCI Landing Zone Architecture

OCI uses compartments as its primary organizational mechanism. Unlike the other providers which use separate accounts/subscriptions, OCI compartments exist within a single tenancy and can be nested up to 6 levels deep. Oracle provides the CIS Landing Zone as a Terraform module that implements CIS Oracle Cloud benchmark recommendations.

bash

# Create compartment hierarchy
oci iam compartment create \
  --compartment-id TENANCY_OCID \
  --name "Security" \
  --description "Security and audit resources"

oci iam compartment create \
  --compartment-id TENANCY_OCID \
  --name "Network" \
  --description "Hub VCN, DRG, FastConnect"

oci iam compartment create \
  --compartment-id TENANCY_OCID \
  --name "Production" \
  --description "Production workloads"

oci iam compartment create \
  --compartment-id PROD_COMPARTMENT_OCID \
  --name "App-A" \
  --description "Application A production"

# Create IAM policies for compartment access
oci iam policy create \
  --compartment-id TENANCY_OCID \
  --name "network-admin-policy" \
  --statements '[
    "Allow group NetworkAdmins to manage virtual-network-family in compartment Network",
    "Allow group NetworkAdmins to manage drg-family in compartment Network",
    "Allow group NetworkAdmins to read all-resources in tenancy"
  ]'

Network Hub-and-Spoke Topology

All four providers recommend a hub-and-spoke network topology for landing zones. The hub provides centralized connectivity (VPN, interconnect, firewall, DNS) and each spoke contains workload resources. Spokes communicate with each other through the hub, enforcing central security inspection.

Component	AWS	Azure	GCP	OCI
Hub	Transit Gateway	Hub VNet + Azure Firewall	Shared VPC or NCC	Hub VCN + DRG
Spoke Connection	TGW Attachment	VNet Peering	Shared VPC or Peering	DRG Attachment / Peering
Central Firewall	AWS Network Firewall	Azure Firewall	Cloud NGFW	OCI Network Firewall
DNS	Route 53 Resolver	Private DNS Zones	Cloud DNS (private zones)	Private DNS
Monthly Hub Cost	~$250 (TGW + DNS)	~$1,500 (Firewall + VWAN)	~$200 (NCC + DNS)	~$100 (DRG free, Firewall)

Azure Firewall Cost

Azure Firewall is the most expensive hub component at approximately $912/month for the Standard SKU before data processing charges. For cost-sensitive environments, consider using third-party NVAs (Network Virtual Appliances) on smaller VM sizes, or use NSGs and UDRs for basic traffic filtering without a central firewall. The Azure Firewall Basic SKU ($300/month) is a cheaper alternative for smaller environments.

Centralized Logging

bash

# AWS: Centralized logging with CloudTrail organization trail
aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name org-cloudtrail-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation

# Azure: Centralized Log Analytics workspace
az monitor log-analytics workspace create \
  --workspace-name central-logs \
  --resource-group management-rg \
  --location eastus \
  --retention-time 365

# Configure diagnostic settings to send to central workspace
az monitor diagnostic-settings create \
  --name send-to-central \
  --resource RESOURCE_ID \
  --workspace central-logs \
  --logs '[{"categoryGroup": "allLogs", "enabled": true}]'

# GCP: Organization-level log sink to central project
gcloud logging sinks create org-audit-sink \
  bigquery.googleapis.com/projects/logging-project/datasets/org_audit_logs \
  --organization=ORG_ID \
  --include-children \
  --log-filter='logName:"cloudaudit.googleapis.com"'

# OCI: Enable audit logging (enabled by default)
oci audit config update \
  --compartment-id TENANCY_OCID \
  --retention-period-in-days 365

Landing Zone as Code

main.tf - Multi-cloud landing zone scaffold

# AWS Landing Zone module
module "aws_landing_zone" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"

  account_email = "workload@example.com"
  account_name  = "app-a-prod"
  ou_name       = "Production"

  account_tags = {
    Environment = "production"
    CostCenter  = "engineering"
  }
}

# GCP Landing Zone module
module "gcp_project_factory" {
  source  = "terraform-google-modules/project-factory/google"
  version = "~> 15.0"

  name              = "app-a-prod"
  org_id            = var.gcp_org_id
  folder_id         = var.gcp_prod_folder_id
  billing_account   = var.gcp_billing_account
  shared_vpc        = var.gcp_shared_vpc_project
  shared_vpc_subnets = var.gcp_prod_subnets

  activate_apis = [
    "compute.googleapis.com",
    "container.googleapis.com",
    "run.googleapis.com",
  ]

  labels = {
    environment = "production"
    cost_center = "engineering"
  }
}

Start Small, Iterate

Do not try to build a perfect landing zone on day one. Start with the minimum viable landing zone: organization structure, centralized logging, basic guardrails, and a hub network. Add capabilities (compliance frameworks, advanced networking, automated account provisioning) as your organization matures. A landing zone that blocks developers from doing their work will be circumvented. Balance governance with developer productivity.

AWS Organizations & SCPs GCP Shared VPC Guide IAM Across Clouds

Key Takeaways

1AWS uses Organizations with OUs and accounts; Azure uses Management Groups and Subscriptions; GCP uses Folders and Projects; OCI uses nested Compartments.
2Hub-and-spoke network topology centralizes connectivity, security inspection, and DNS across all providers.
3Azure Firewall is the most expensive hub component (~$912/month); OCI DRG is free; AWS Transit Gateway costs ~$250/month.
4Policy guardrails (SCPs, Azure Policy, Org Policies, OCI Policies) enforce security baselines that project owners cannot override.
5Centralized logging to a dedicated account/project captures audit trails, VPC flow logs, and security events.
6Start with a minimum viable landing zone and iterate; overly restrictive governance will be circumvented.

Frequently Asked Questions

What is a landing zone?

A landing zone is the foundational architecture that establishes account structure, networking, identity management, security guardrails, and operational tooling for a cloud environment. It is the infrastructure you build before deploying workloads, ensuring consistent governance, security, and cost management from day one.

Should I use AWS Control Tower or build my own landing zone?

Use Control Tower if your requirements align with its opinionated defaults (recommended for most organizations). Build custom if you need specific OU structures, non-standard guardrails, or integration with existing governance tools. Control Tower can be customized with Account Factory for Terraform (AFT) for a middle ground.

How do I build a landing zone that works across multiple clouds?

Use Terraform with provider-specific modules for each cloud, managed from a central repository. Standardize naming conventions, tagging strategies, and organizational structures across providers. Use a single identity provider federated to all clouds. Implement centralized logging that aggregates across providers (e.g., to a SIEM).

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.