A production landing zone is the governed multi-account environment you put in place before the first production workload. On AWS that is usually AWS Organizations plus AWS Control Tower, IAM Identity Center, CloudTrail and Config. On Azure it is a platform landing zone under management groups, with Microsoft Entra ID and Azure Policy. On Google Cloud it is an organization resource, folders, Shared VPC and organization policies. Design identity, network isolation, logging and account vending first. Do not treat a single shared account as production-ready. Provider documentation dated 2026-08-30 is the source for each primitive.
If you need the concept without provider mapping, start with What is a landing zone?. This guide covers the decisions a production platform actually has to record.
Assumptions
- You are building or reviewing a multi-account environment. A single shared account is not the target state.
- AWS Organizations (with or without Control Tower), Azure CAF landing zones, or a Google Cloud organization plus Shared VPC are the primitives. Alibaba Resource Directory is on its own page.
- Identity federation, a hub network and logs the workload team cannot empty are day-one requirements, not later tickets.
- Greenfield vending and brownfield drift are both in scope. This is not a Control Tower install walkthrough.
What has to exist before a workload lands
A landing zone is not a region and not a VPC. AWS Control Tower defines it as the multi-account environment that holds organizational units, accounts, users and the controls applied to them. Azure’s Cloud Adoption Framework splits the same idea into a platform landing zone (shared governance and connectivity) and application landing zones (workload subscriptions). Google Cloud’s landing-zone series treats it as the organization resource plus identity, hierarchy, network and security decisions.
Four capabilities have to work on day one:
- A hierarchy you can attach policy to (OUs, management groups or folders).
- A human identity path that is not long-lived IAM users in every account.
- A network pattern that does not default to public IPs for every subnet.
- Immutable logs that the workload team cannot turn off.
Skip any one of those and you will rebuild the foundation after the first audit or the first cost surprise.
Provider primitives (they are not interchangeable)
AWS. AWS Control Tower orchestrates AWS Organizations, AWS Service Catalog and AWS IAM Identity Center. It creates a landing zone, applies preventive and detective controls, and vends accounts through Account Factory. You can also build the same shape with Organizations alone. Control Tower then becomes optional. SCPs do not constrain principals in the management account. Keep workloads out of that account.
Azure. One platform landing zone per Microsoft Entra tenant is the usual pattern. Management groups hold Security, Management, Identity, Connectivity and application landing-zone subscriptions (often under Corp or Online). Azure Policy assignments inherit down the tree. Subscription vending is how workload teams get a new environment without copying a production subscription.
Google Cloud. You need an organization resource and a billing account before the rest of the landing zone exists. Shared VPC host projects hold the networks. Service projects attach to those hosts. Organization policies and VPC Service Controls sit at folder or project scope. Google Cloud documents more than one landing zone in the same organization when a workload has a different network or compliance boundary.
Alibaba Cloud uses Resource Directory, RAM and CEN rather than Organizations or management groups. That mapping lives in Alibaba Cloud architecture for APAC workloads.
Confirm the hierarchy you already have
Read the current tree before you draw a target. On AWS:
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-exampleroot
aws organizations list-accounts --query 'Accounts[].{Id:Id,Name:Name,Status:Status}' --output table
A typical list-roots response is one Root with an Id like r-abcd and an Arn under the management account. list-organizational-units-for-parent then returns Security, Infrastructure and Workloads OUs if someone already followed the AWS multi-account whitepaper. Status: SUSPENDED accounts still sit in the tree and still inherit SCPs until you close or move them. If list-roots returns AWSOrganizationsNotInUseException, you do not have a landing zone. You have a standalone account.
On Azure, az account management-group list -o table shows the same idea as OUs. On Google Cloud, gcloud organizations list and gcloud resource-manager folders list --organization=ORG_ID show the folder tree.
Identity and logging that survive the first incident
Humans should federate through IAM Identity Center, Microsoft Entra ID or Cloud Identity. Workloads should use IAM roles, managed identities or workload identity. Standing access keys in a shared account are not a landing-zone identity model. Break-glass lives in each provider’s native directory. If federation or Identity Center is down and you cannot sign in, use IAM access lockout. See IAM fundamentals for the control-plane difference.
Logging is a control-plane concern, not an application add-on. AWS CloudTrail organization trails and AWS Config recorders belong in a Log Archive or Security account. Azure Monitor and Microsoft Sentinel usually sit in the Management or Security subscription. Google Cloud Logging and Cloud Audit Logs need a destination the service-project owner cannot empty. If the team that deploys the app can disable the trail, the landing zone is incomplete.
Networking belongs in the landing zone, not in the first app ticket
Hub-and-spoke, Shared VPC or a connectivity subscription is a landing-zone decision. If every application team creates its own internet gateway and NAT, you will pay for duplicate egress and you will have no inspection point. The topology is covered in hub-and-spoke cloud networking. The account layout that holds those hubs is covered in multi-account and multi-subscription structure.
Risks and limitations
Control Tower, Azure landing-zone accelerators and the Google Cloud Terraform example foundation encode defaults. They do not encode your data-residency rule, your RTO or your tagging dictionary. Drift is normal: someone will create an account outside Account Factory or a subscription outside the management-group path. Detect that with Organizations, Azure Resource Graph or Cloud Asset Inventory, not with a slide that says the landing zone is done.
SCPs, Azure Policy and organization policies deny actions. They do not invent missing network routes or missing log sinks. A green Control Tower dashboard can still sit in front of a flat VPC with public subnets.
AWS Well-Architected is a review lens, not a landing-zone product. Use it after the hierarchy, identity and logging exist.
If you want a written review of an existing estate rather than a greenfield build, that is cloud architecture consulting. Terms used here are in the cloud glossary.