Cloud architecture is the set of durable decisions about tenancy, identity, networks, failure domains, and cost ownership that determine how workloads run on a provider. On AWS that starts with accounts under Organizations. On Azure it starts with a Microsoft Entra tenant, management groups, and subscriptions. On Google Cloud it starts with an organization, folders, and projects. On Alibaba Cloud it starts with a Resource Directory. The diagrams differ. The job does not: you are choosing isolation boundaries, blast radius, and who pays the invoice. Documentation as of 2026-08-30.

Enforceable landing-zone defaults are on the production landing-zone guide. This article defines the tenancy decisions underneath those defaults.

What the architecture actually is

A workload needs compute, storage, and a path to users. Architecture is the container around that workload: which account or subscription owns it, which identity can change it, which network it can leave, which region it dies in, and which cost center sees the bill.

AWS documents this as a conversation against the Well-Architected Framework, not as an audit. The framework (publication date 6 November 2024, still the current docs page on 2026-08-30) groups questions under operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Azure’s Cloud Adoption Framework treats the same problem as a landing zone: a platform foundation plus application environments. Google Cloud’s documented unit of work is the project. Every resource you allocate belongs to one. Alibaba Cloud’s Resource Directory is the documented way to put multiple accounts into one tree for permissions, networking, and consolidated billing.

Provider-neutral checklists hide the mechanism. An AWS account is a hard isolation and billing boundary. An Azure subscription is a billing, quota, and RBAC scope under a tenant. A Google Cloud project is a namespace, IAM boundary, and billing attach point. An Alibaba Cloud member account is either a resource account created inside the directory or an invited cloud account. Those are not synonyms.

How to see the structure you already have

On AWS, the management account can list the organization:

aws organizations describe-organization \
  --query '{Id:Id,FeatureSet:FeatureSet,MasterAccountId:MasterAccountId}' \
  --output table

FeatureSet=ALL means the organization can attach policies such as service control policies. CONSOLIDATED_BILLING means shared invoices only. AWS documents that you can later enable all features, but invited member accounts must accept that change. An AccessDeniedException usually means you are in a member account. Documented behavior: SCPs attached at the root apply to member accounts, not to the management account.

On Azure, start at Azure portal > Management groups or:

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

An empty table means the tenant has no management-group hierarchy yet. Subscriptions then sit under those groups and inherit Azure Policy and RBAC from above.

On Google Cloud:

gcloud organizations list
gcloud projects list --format="table(projectId,name,parent.id)"

parent.id tells you whether a project hangs off a folder or the organization. Projects with no parent are common in older estates and they skip folder-level IAM.

On Alibaba Cloud, sign in to Resource Management > Resource Directory, or call GetResourceDirectory with the Alibaba Cloud CLI. Documented limits include one resource directory per eligible management account, five folder levels under Root, and a default of 50 members (quota can be raised).

How to interpret the result

You are looking for a tree, a payer, and a place workloads are not supposed to live. AWS and Alibaba both document that the management account is a poor home for production resources. AWS says SCPs do not constrain principals in the management account. Alibaba says the management account is not a directory member and is not subject to access control policies. Engineering recommendation: keep those accounts nearly empty.

If the tree is one account, one subscription, or one project, you do not have an architecture problem yet. You have an isolation problem that will show up as a shared IAM blast radius and a single invoice you cannot split.

Risks and limitations

Well-Architected, CAF, and Resource Directory docs describe intended structure. They do not invent the network, the identity provider, or the tag policy for you. A diagram copied from a US workshop often places regions you will never use and skips APAC data-residency constraints. Start from choosing a primary cloud region for APAC workloads when users or data are in APAC.

Most architecture reviews stall because they score services and skip tenancy. Fix the account, subscription, project, or directory tree before you argue about Kubernetes versus functions.

The next design step is a production landing zone, which is the first place those decisions become enforceable. See Designing a production landing zone.

Official sources