Enterprise Cloud Hierarchy: AWS, Azure, and GCP Side by Side

01

The problem every enterprise hits on day two

Day one in the cloud is simple. You create an account, spin up a server, and get something running. It is fast, it is empowering, and it feels like the future.

Day two is when reality arrives. A second team wants access. A third team spins up their own environment. Someone in finance asks: "Who is spending what?" Someone in security asks: "Who has access to what?" And an architect asks the question that should have come first: "How are we going to structure all of this?"

Every major cloud provider has solved this with a hierarchy. A tree structure that lets enterprises group resources, apply policies at scale, and consolidate billing — without losing the autonomy that individual teams need to move fast. The hierarchy is different on each cloud. The mental model is the same.

02

The hierarchy: Organizations, Management Groups, and Folders

Think of it as a company org chart, but for your cloud resources. At the top sits the root — the entity that owns everything. Below it are grouping containers that exist purely to carry policy and structure. At the leaves of the tree sit the actual billing and resource boundaries: AWS accounts, Azure subscriptions, and GCP projects.

Resources — virtual machines, databases, storage buckets — live inside those leaf containers. You cannot deploy a resource directly into a folder or a management group. The grouping layers are for governance, not for creating resoures.

Three clouds, one pattern. The leaf node — the AWS account, the Azure subscription, the GCP project — is always where the billing meter runs and where IAM permissions begin to mean something concrete. Everything above that leaf is governance scaffolding: a place to attach policies that cascade down.

03

AWS: Organizations, OUs, and SCPs

AWS launched Organizations in 2017 specifically to address enterprise multi-account sprawl. Before it existed, teams managed accounts in isolation — each with its own billing, its own IAM configuration, and no shared governance layer.

The structure

At the top sits the Management Account (formerly called the master account). This account owns the organisation and should contain nothing except organisational governance — no workloads, no application resources. Treat it as the keys to the kingdom: access should be minimal, audited, and break-glass only.

Below the root node of the organization sit Organisational Units (OUs). These are containers for accounts. OUs can be nested up to five levels deep. A common pattern is to mirror your business structure: a top-level OU for each business unit or environment type, then child OUs for individual applications or teams.

At the leaves sit AWS Accounts. These are the actual billing and resource isolation boundaries. Each account gets its own IAM namespace, its own VPC by default, and its own billing line in consolidated billing. Cross-account access is always explicit — nothing leaks between accounts without a deliberate trust relationship.

Service Control Policies (SCPs)

The most powerful governance mechanism in AWS Organizations is the Service Control Policy (SCP). SCPs are JSON IAM-like policies attached to OUs or accounts. They define the maximum permissions any principal inside that OU can ever have — they are a ceiling, not a grant.

SCPs do not apply to the Management Account itself. They do not grant permissions — they only restrict. The effective permission of any principal is the intersection of what their IAM policies allow and what their SCP permits.

AWS Control Tower

For enterprises starting fresh, AWS Control Tower is the recommended way to set up this structure. It provisions a Landing Zone — a pre-built OU structure, a set of baseline SCPs called guardrails, and mandatory accounts for logging and auditing — in a few hours rather than weeks of manual configuration.

If you already have an existing Organisation with many accounts, Control Tower can be enrolled incrementally. It does not require a greenfield start.

04

Azure: Management Groups and Policy

Azure's equivalent of AWS Organizations is the Management Group hierarchy, anchored to an Entra ID Tenant (formerly Azure Active Directory). The tenant is a container for all the identities — every human and workload identity in your enterprise lives here.

The structure

The Root Management Group is created automatically when you first use Management Groups in a tenant. It is the parent of everything. Below it, you create Management Groups to mirror your organisation — by business unit, geography, environment, or application portfolio, depending on your needs.

The billing boundary in Azure is the Subscription. A subscription belongs to exactly one Management Group. Resources live inside subscriptions, further grouped into Resource Groups — which are logical containers within a subscription, not separate billing entities. Resource Groups are organisational only; costs roll up to the subscription.

Azure Policy

Where AWS uses SCPs as a deny ceiling, Azure uses Azure Policy. Policies can audit, deny, or auto-remediate resources that do not comply with organisational rules. They can be attached at any level of the hierarchy and inherit downward.

Initiatives (also called Policy Sets) are bundles of related policies deployed together — equivalent to attaching multiple SCPs in a package. Azure ships built-in initiatives for common frameworks: CIS Benchmarks, NIST SP 800-53, PCI-DSS, and ISO 27001.

RBAC in Azure

Azure Role-Based Access Control (RBAC) assignments can be made at any scope: Management Group, Subscription, Resource Group, or individual resource. Assignments inherit downward. A role assigned at the Management Group level applies to every subscription and resource within it. This is powerful — but it means your RBAC design must be deliberate. Over-privileged assignments at a high scope propagate widely and it could affect your environment in a negative manner.

05

GCP: Organization, Folders, and Projects

Google Cloud's hierarchy starts with a requirement that does not exist on the other clouds: you must have a Google Workspace or Cloud Identity domain before you can create an Organisation node. This is the identity anchor — GCP does not let you stand up an enterprise hierarchy without a managed identity store underneath it.

The structure

The Organisation is the root. It is automatically created when your Workspace or Cloud Identity domain is linked. Below the Organisation sit Folders, which are the GCP equivalent of OUs and Management Groups. Folders can be nested — a Folder can contain other Folders, up to ten levels deep.

The leaf node — the Project — is where all GCP resources live. A project has its own billing account link, its own API enablement, its own IAM namespace, and its own quota limits. There is no resource without a project. Every Cloud Storage bucket, every Compute Engine VM, every Cloud Run service belongs to a project.

Organisation Policies and IAM inheritance

GCP's governance layer is Organisation Policy — a set of constraints that can be attached at the Organisation, Folder, or Project level. Constraints are boolean (allow/deny) or list-based (allowed values). They cascade downward unless explicitly overridden at a lower level.

06

Side-by-side comparison

The conceptual model is parallel enough that you can map the layers directly. The differences are in the details — how policy works, where identity lives, and what the leaf node gives you.

07

Cross-enterprise access: federated identity vs native IAM

No enterprise runs a single application. People need access across accounts, subscriptions, and projects. Applications need to call APIs in other environments. And external partners need scoped, auditable entry points. Each cloud solves this differently — but every approach falls into one of two patterns: native role assumption or federated identity from an external IdP.

Pattern 1 — Native role assumption (cloud-native IAM trust)

In this pattern, identities inside one cloud boundary assume roles in another. No external identity provider is involved. Trust is established between cloud principals directly. This is more applicable in scenarios where resource in one account/subscription/project has to access resources in the other account/subscription/project.

Pattern 2 — Federated identity from an enterprise IdP

Most enterprises already have an identity provider — Microsoft Entra ID, Okta, Ping Identity, or an on-premises Active Directory. The preferred approach is to use that existing IdP as the source of truth and federate it into all three clouds, rather than maintaining separate identities in each cloud's native IAM. This is applicable for human access to the cloud area.

AWS: IAM Identity Center

IAM Identity Center (formerly AWS SSO) is the recommended way to manage human access across all accounts in an AWS Organisation. You connect your external IdP, sync groups, define Permission Sets (which are IAM role templates), and then assign those sets to accounts. Users get a single portal URL, log in once with their corporate credentials, and see exactly the accounts and roles they have access to. No IAM users. No permanent credentials.

Azure: Entra ID and RBAC

Azure has a significant structural advantage here: if your enterprise is already using Microsoft 365, your Entra ID tenant is also your Azure identity root. Groups created in Entra ID — the same groups used for Teams, SharePoint, and Exchange — can be directly assigned Azure RBAC roles. There is no separate sync step. If your enterprise uses a non-Microsoft IdP (Okta, Ping), you configure external federation into Entra ID, which then acts as the broker for all Azure resource access.

GCP: Workforce Identity Federation

Workforce Identity Federation is GCP's mechanism for connecting external IdPs to human access. Rather than downloading service account keys or creating Cloud Identity accounts for every user, Workforce Identity lets your users authenticate with your corporate IdP and exchange that assertion for short-lived GCP access tokens. Attribute mapping lets you control which IdP groups translate to which GCP IAM bindings — keeping your source of truth in the IdP, not inside GCP's IAM.

08

Billing boundaries and consolidated cost management

The hierarchy is not just about access control — it is the foundation for how you see and manage your cloud spend. All three clouds consolidate billing at the root, but the mechanics differ.

09

Account boundary recommendation: one account per app per env

This is the question most enterprises get wrong in year one and spend years unwinding: how many accounts (or subscriptions, or projects) should we have?

The answer that AWS, Microsoft, and Google all converge on in their enterprise reference architectures is: one billing boundary per application per environment. Separate production from staging from development — and separate each application from every other application — at the account level, not just the VPC or the tag level.

Why not a shared account?

The temptation is to create one account per environment — a single production account for everything, a single dev account for everything. It feels easier to manage. In practice, it creates three problems that compound over time.

• Blast radius. A misconfigured IAM policy, a runaway lambda, or a storage bucket with wrong permissions in a shared account can affect every application in that account simultaneously. Separate accounts are separate fault domains.
• Billing opacity. Tags can attribute costs, but tags get forgotten, drift, and are not enforceable in all services. An account boundary is a hard billing boundary — the cost of an account is unambiguous.
• IAM entanglement. In a shared account, every team's IAM roles live in the same namespace. Cross-team resource access becomes an increasingly complex web of policies. In separate accounts, IAM starts clean for each application.

How many accounts is too many?

A common objection is: "We have fifty applications. That means 200 accounts. That is unmanageable." This objection reflects the old mental model — where each account required manual setup and manual IAM configuration. With Landing Zone automation, an account is a unit of infrastructure provisioned from a template in minutes. The overhead per account in a well-automated Landing Zone is near zero.

AWS's own enterprise customers routinely operate organisations with 1,000 or more accounts. GCP enterprises run thousands of projects. Azure enterprises run hundreds of subscriptions. The hierarchy and automation layer are designed to handle this scale.

Naming convention

Adopt a consistent naming convention before your first account is created. A pattern like {org}-{app}-{env} — for example acme-payments-prod — makes accounts searchable, auditable, and self-documenting. The convention needs to be enforced at provisioning time, not retroactively applied.

Useful Resources

• Designing an AWS Landing Zone
• Designing a Secure and Effective AWS IAM Model
• Designing a Google Cloud Landing Zone

---

Where to start