Multi-account and multi-subscription structure

The production landing-zone decisions that sit on top of this tree are in Designing a production landing zone.

Assumptions

• You can list Organizations accounts, Azure management groups and subscriptions, or Google Cloud folders and projects.
• This is the isolation tree, not the full landing-zone product set (Control Tower, CAF accelerators).
• Platform accounts (Security, Logging, Identity, Connectivity) are the split you will make, greenfield or brownfield.
• Alibaba Resource Directory members are out of scope except as a pointer to the Alibaba APAC page.

Why the unit of isolation is an account, not a VPC

An AWS account is a resource, IAM and billing boundary. A member account belongs to one organization. SCPs attached to an OU limit principals in those member accounts. They do not limit principals in the management account. Azure subscriptions inherit Azure Policy from management groups. Google Cloud projects inherit organization policies from folders. A VPC, VNet or Shared VPC network is a connectivity boundary. It is a poor substitute for an account boundary when someone needs AdministratorAccess.

If two systems share an account, they share IAM mistakes, service quotas and the blast radius of a leaked key. If they share only a hub network, they share routes and DNS, which is usually what you wanted.

A tree that matches how you apply policy

AWS’s organizing whitepaper groups accounts into Security, Infrastructure and Workloads OUs, with production and non-production nested under workloads. Azure’s landing-zone hierarchy uses platform management groups (Identity, Connectivity, Management, Security) and application landing zones under Corp, Online or Local. Google Cloud typically uses folders for environment or business unit, then projects for each deployable unit.

Name the OU, management group or folder after the policy you will attach, not after the current org chart. Org charts change. “No internet gateway in production” does not.

Sandbox and decommissioned branches belong in the tree. A leftover account in the root inherits every root SCP and every root exemption. That is how production controls leak into experiments, or the reverse.

Read the tree you have

aws organizations describe-organization
aws organizations list-accounts --output table
aws organizations list-parents --child-id 123456789012

describe-organization returns FeatureSet. ALL means you can attach SCPs and enable trusted access. CONSOLIDATED_BILLING means you have a payer account and almost no governance. list-parents for a given account shows whether it sits under an OU or directly under the root. Accounts under the root are the ones nobody decided how to govern.

Azure equivalent:

az account management-group list --query "[].{name:name,displayName:displayName}" -o table
az account list --query "[].{name:name,id:id,state:state}" -o table

Google Cloud equivalent:

gcloud organizations list
gcloud projects list --filter='parent.id:FOLDER_OR_ORG_ID'

Interpret empty parent on a Google Cloud project as “this project is not in your landing-zone tree.” Interpret an Azure subscription that appears in az account list but not under any management group as the same problem.

How many accounts is enough

Use a new AWS account, Azure subscription or Google Cloud project when you need a different:

• Security blast radius (production vs a contractor sandbox)
• Billing owner (a product line that must see its own invoice)
• Quota pool (a batch farm that would starve an API)
• Policy set (a PCI folder that forbids public IPs)

Do not use a new account for every container. Kubernetes namespaces and IAM roles handle that finer split. Do not keep production and a shared CI runner in the same account because “we only have two engineers.” The runner’s role will eventually be able to read production secrets.

Platform accounts stay few: Log Archive, Security Tooling, Identity, Network Hub, Shared Services. Workload accounts grow. Control Tower Account Factory and Azure subscription vending exist so growth does not mean copying a production account by hand.

Billing follows the tree, then tags

Consolidated billing on AWS, a billing account on Google Cloud, and an Enterprise Agreement or Microsoft Customer Agreement on Azure roll charges to a payer. They do not tell you which product incurred NAT or GPU spend. After the account split, apply the tag dictionary in Cloud tagging and cost allocation. Account-level allocation is still the cleanest chargeback line you will get.

Alibaba Cloud’s equivalent unit is a Resource Directory member under a folder, not an AWS account. Use Alibaba Cloud architecture for APAC workloads if that is the control plane.

Risks and limitations

You cannot change which AWS account is the management account. You cannot move a Google Cloud project across organizations without a migration. Azure subscriptions can move between management groups, which is useful and also a way to escape a policy set without a ticket.

Invited AWS accounts must accept an Organizations handshake. Invited Alibaba Cloud accounts keep their root users. Those invited identities are a different risk from resource accounts created inside the directory.

SCPs, Azure Policy and organization policies deny API calls. They do not delete unused accounts. Closed or disabled accounts still confuse humans who read the tree. Review Status and state in the commands above on a schedule.

Provider-specific architecture notes: AWS, Azure, Google Cloud. Terms are in the cloud glossary.