Management groups vs AWS Organizations vs GCP folders
This is the layer above the bill — the roof of the org tree, where you set one rule and let gravity carry it down to everything below.
New to cloud? CAMPUX is a free, build-first course. Start here →
Azure management groups, AWS Organizations with OUs, and GCP folders all do the same top-of-the-tree job: group the billing boundaries below them and push policy and billing rollup downward by inheritance. So the clean mapping is management group ≈ OU ≈ folder, and Azure Policy ≈ SCP ≈ Org Policy. But the enforcement models are not the same, an SCP can only deny, and where the tree binds to identity differs on all three. Map the shape, then re-learn what "policy" means on each.
One layer down from here is the billing boundary — subscription, account, project. This is the layer above it: the place you go when you have more than one of those boxes and you want to govern them as a group instead of one at a time. Every cloud gives you a tree here, and the trees genuinely rhyme. The trap is assuming the policy engines hanging off those trees behave the same. They don't, and that's most of this article.
What each one actually is
Same job on all three — a grouping node that sits above the billing boundary, that policy and billing roll through by inheritance. Set a rule at a node and everything nested under it gets that rule, without you touching each box. The differences are in what they group and how they attach to the rest of the cloud.
Azure management groups
A management group is a container for subscriptions and for other management groups — so you build a small tree of them, with the subscription sitting at the bottom of that tree. You apply Azure Policy and RBAC at a management group and it flows down to every subscription beneath it. The important structural fact: this tree lives under your Entra tenant but is a separate thing from identity, and there's a single root management group with every subscription parked under a default group whether you built one or not. You can nest up to six levels below the root.
AWS Organizations
On AWS the tree is the Organization, and the grouping node inside it is the organizational unit — the OU. Accounts sit in OUs; OUs nest under the organization root. The guardrail engine here is the Service Control Policy, an SCP, which you attach to an OU (or the root) and which every account underneath inherits. One thing to hold onto: the Organization is created from and tied to a single management account — the old "master"/payer account — so the whole tree hangs off one privileged account rather than off the identity directory.
GCP folders
GCP gives you an Organization at the top and folders as the grouping node beneath it; projects sit in folders, and folders can nest. Guardrails come from Org Policy, which is constraint-based — you enable or configure specific constraints (block external IPs, restrict which regions are allowed) at a folder or the organization and they inherit down. The catch that trips people: the GCP Organization node is bound to your Cloud Identity or Google Workspace domain. No verified domain, no organization — and therefore no folders. You cannot opt out of that the way you can just start grouping on Azure.
| Trait | Azure | AWS | GCP |
|---|---|---|---|
| Grouping node | Management group | Organizational unit (OU) | Folder |
| What it groups | Subscriptions | Accounts | Projects |
| Guardrail engine | Azure Policy | Service Control Policy (SCP) | Org Policy |
| Enforcement model | Deny, audit, and modify/deploy | Deny-only (caps permissions) | Constraint-based (on/off guardrails) |
| Bound to | Entra tenant, kept separate from identity | A single management (payer) account | A verified Cloud Identity / Workspace domain |
| Defaults & nesting | Root + default group; up to 6 levels | Org root; several levels of OUs | Org node; several levels of folders |
The tree is the easy part — every cloud has one and they rhyme. What "apply a policy here" actually does is where the three of them quietly part ways.
The clean mapping, before the leaks
Say it once so it sticks, because this part really does map: a management group is an OU is a folder. All three are a node you hang billing boundaries off, all three inherit downward, all three exist so you can govern many boxes as a group. And Azure Policy at a management group lines up with an SCP on an OU lines up with an Org Policy on a folder — same position in the tree, same "set it high, inherit it low" idea. If someone asks you the one-line equivalent in an interview, that's the answer. Then they'll ask a follow-up, and the follow-up is where you earn it.
The three places the map lies
Same as the hub warns for every layer: the words line up, the mechanics don't. Three leaks here, and the middle one is the one that actually burns people.
Azure management groups form a tree that lives under your Entra tenant but stays deliberately separate from identity — the hierarchy and the directory are two systems. AWS OUs live inside the Organization, and the Organization is tied to one management (payer) account, so the whole tree hangs off a single privileged account rather than the directory. GCP's Organization is bound to your Cloud Identity or Workspace domain, which means you literally cannot have a GCP org — or any folders — without a verified domain. People come to GCP expecting to "just group two projects" and hit a domain-verification wall on day one. Same tree, three very different roots.
This is the one to slow down on. An AWS SCP is a deny-only guardrail: it sets the ceiling of what an account is ever allowed to do, and it grants nothing on its own — you still need IAM underneath to actually permit anything. Azure Policy is broader: it can deny, but it can also audit (flag non-compliant resources without blocking) and even modify or deploy to bring resources into line. GCP Org Policy is constraint-based — a catalogue of specific guardrails you switch on or configure. So "we enforce policy at the top" is a true sentence on all three and means three different things. Assume SCP behaviour on Azure and you'll miss half of what Azure Policy can do; assume Azure behaviour on AWS and you'll expect an SCP to grant access it never grants.
Azure hands you a root management group and parks every subscription under a default group automatically, and lets you nest up to six levels deep — so a tree exists whether you built one or not. AWS and GCP don't give you that same free default: you create the Organization, then build the OUs or folders you want, and the nesting depth allowed differs from Azure's six. Don't copy a six-level Azure design onto AWS or GCP by reflex, and don't assume the "default" node you rely on in Azure has a twin on the others. Check the current per-cloud limit before you design something deep.
How they nest
Same skeleton, top to bottom, with this layer as the roof over the billing boundary:
- Azure: Tenant → management groups → subscription → resource group → resource.
- AWS: Organization → OUs → account → (tags, no native group) → resource.
- GCP: Organization → folders → project → resource.
The bold layer is what this article is about; the layer directly under it is the billing boundary, and the one under that is the resource container. Read the tree as three floors: govern-here at the top, pay-here in the middle, put-things-here at the bottom. Every cloud has all three floors; only the names and the enforcement rules on the top floor change.
So how should you actually use this layer?
Same instinct on all three: build the tree around how you want to govern and bill, not around your org chart for its own sake. A common shape is a node for production and a node for non-production near the top, then teams or environments below, so a policy set once at "production" covers every box that's production. On Azure you draw that with management groups and hang Azure Policy and RBAC off the nodes; on AWS with OUs and SCPs; on GCP with folders and Org Policy. The design is the same; only what "policy" can do at each node changes.
If you're learning this for the first time, do it on Azure, where the management-group tree is a plain visible thing you can walk, and Azure Policy shows you deny, audit, and remediate side by side — so you feel the full range before you meet the narrower SCP model on AWS. That's the order we teach it in the subscriptions and groups class, right before the RBAC and Azure Policy class. And if the whole three-cloud skeleton is still fuzzy, the cross-cloud class lays it out, with Class One underneath it for the ground floor.
Common questions
Is an Azure management group the same as an AWS OU or a GCP folder?
For the job they do, yes — all three are a grouping node near the top of the tree that policy and billing inherit through, so you set a rule once and everything underneath gets it. That's the clean mapping: a management group is roughly an AWS organizational unit is roughly a GCP folder. Where they stop being the same is what sits beneath them and how they bind to identity. A management group groups subscriptions, an OU groups accounts, a folder groups projects, and only Azure keeps this tree fully separate from the identity directory.
Is Azure Policy the same as an AWS SCP or a GCP Org Policy?
They all inherit down the tree, but they enforce differently, and this is the trap. An AWS Service Control Policy is deny-only — it caps the maximum permissions an account can ever have, it never grants anything. Azure Policy is broader: it can deny, but it can also audit, and it can modify or deploy resources to bring them into compliance. GCP Org Policy is constraint-based — you turn specific guardrails on or off, like blocking public IPs. Same position in the tree, three different enforcement models. Don't assume "policy at the top" means the same thing.
Do you need a domain to create the org tree on each cloud?
Only GCP forces it. A GCP Organization is bound to your Cloud Identity or Google Workspace account, so you cannot create the organization node — and therefore folders — without a verified domain. This surprises people who just wanted to group a couple of projects. Azure management groups live under your Entra tenant, which already exists, so there's nothing extra to verify. AWS creates the Organization from your management (payer) account with no domain step. The GCP domain requirement is the one that blocks people on day one.
How deep can you nest management groups, OUs, and folders?
The limits and defaults differ, so don't carry the number across. Azure lets you nest management groups up to six levels deep beneath the root, and every subscription automatically sits under a default management group whether you asked for one or not. AWS lets you nest OUs several levels under the organization root. GCP lets you nest folders several levels under the organization. Check the current per-cloud limit before you design a deep tree — and remember Azure gives you a root and a default group for free, which the others don't do the same way.