A landing zone is the baseline environment you stand up before production workloads: a tenancy tree, identity, shared networking, logging, and guardrails that new accounts or subscriptions inherit. AWS implements this with Organizations, organizational units, and often Control Tower. Azure names it explicitly in the Cloud Adoption Framework as a platform landing zone plus application landing zones. Google Cloud uses the organization, folder, and project hierarchy, often with a host project for Shared VPC. Alibaba Cloud uses Resource Directory folders and member accounts. Documentation as of 2026-08-30.

The tree and inheritance are below. How many accounts to vend is the multi-account guide.

Mechanism, per provider

Microsoft’s current CAF page splits the idea in two. The platform landing zone is the centralized foundation: governance, security, and shared resources. An application landing zone is where a workload team deploys. Microsoft states that most organizations should have one platform landing zone per Microsoft Entra tenant. Application landing-zone subscriptions are placed under management groups such as Corp, Online, or Local so they inherit Azure Policy.

AWS does not use the same two-noun split in Organizations itself. The documented tree is root, organizational units, a management account, and member accounts. Excluding the root, the OU hierarchy can be five levels deep. Service control policies set the maximum permissions available to IAM principals in member accounts. Resource control policies set the maximum permissions on resources. Neither policy type is a grant. IAM still has to allow the action. AWS documents that SCPs do not apply to the management account.

Control Tower is an AWS service that deploys a landing zone on top of Organizations (logging archive account, audit account, preventive and detective controls). The Security Reference Architecture describes a similar multi-account pattern without requiring Control Tower.

Google Cloud’s documented hierarchy is organization, folders, projects, then service resources. IAM allow policies inherit downward. Shared VPC, documented separately, puts the network in a host project and attaches service projects so application teams do not each own a VPC.

Alibaba Cloud Resource Directory uses a management account, a Root folder, nested folders, and members. Access control policies restrict what RAM can later grant. They do not grant access. Documented default limits include 100 folders (excluding Root), five nesting levels, and 50 members, with some limits adjustable by quota.

Read the tree you have

Azure portal path: Management groups > Tenant root group. CLI:

az account management-group hierarchy show \
  --name <tenant-root-or-mg-id> \
  --query "{name:name,children:children[].{name:name,type:type}}"

Look for a platform set (identity, connectivity, management) and a landing-zones set that holds workload subscriptions. If every subscription sits directly under the tenant root, Policy and RBAC have no intermediate scope.

AWS:

aws organizations list-roots --output table
aws organizations list-organizational-units-for-parent \
  --parent-id r-xxxx \
  --output table
aws organizations list-accounts \
  --query 'Accounts[].{Id:Id,Name:Name,Status:Status}' \
  --output table

Status=ACTIVE is a live member. SUSPENDED is closed or payment-blocked. If every account is parented at the root, you have no OU-level SCP target.

Google Cloud:

gcloud resource-manager folders list --organization=ORGANIZATION_ID
gcloud projects list --filter="parent.id:FOLDER_ID"

An organization with projects and no folders is valid documented structure. It is a poor policy inheritance design. Engineering recommendation: put environment or business folders between the organization and projects before you attach org policies.

Alibaba Cloud console: Resource Management > Resource Directory > Resource Directory. Confirm the management account is not also a workload member, and that access control policies are attached to folders rather than copied by hand into every RAM policy.

Risks and limitations

A landing zone accelerator is not a completed design. Azure’s page lists Microsoft accelerators and custom builds. AWS Control Tower controls do not cover every service. Google Cloud Shared VPC still requires you to decide which subnets service projects may use. Alibaba Cloud folder and member quotas are real; a large estate hits them.

If the first landing zone is a single shared account with a VPC and a naming convention, you built a sandbox. The blast radius is still the whole estate.

Guardrails also fail in documented ways. AWS SCPs skip the management account. Alibaba Cloud access control policies skip the management account. Azure Policy does not replace Azure RBAC. Google Cloud folder IAM does not replace project-level grants you later add.

The structural next page is how to split accounts and subscriptions without copying a US retail reference architecture. See Multi-account and multi-subscription structure.

Official sources