Resource Hierarchy

A resource hierarchy is the tree of containers a cloud provider puts your resources in. Its nodes are where policy, permissions, and billing attach; its leaves are the resources themselves. Every provider has one, the shapes differ, and where a resource sits in it decides more about that resource than most of its own settings do. Descriptions here follow the AWS, Microsoft, and Google Cloud documentation, checked in September 2026.

Trees of different shapes

The names are provider-specific and the structures are genuinely different, so the mapping is approximate rather than a translation table.

• AWS. An organization is “a hierarchical, tree-like structure with a root at the top and organizational units nested under the root,” and there is “only one root.” Accounts sit in OUs, and an account is “a container for your AWS resources.” OUs nest — “excluding the root and AWS accounts created in the lowest OUs, your hierarchy can be five levels deep” — and below the account there is no further container.
• Azure. Management groups are “a governance scope above subscriptions,” where “the governance conditions that you apply cascade by inheritance to all associated subscriptions.” A subscription holds resource groups, which hold resources. The tree “can support up to six levels of depth” above subscriptions, and “each management group and subscription can support only one parent.”
• Google Cloud. “The hierarchy consists of the organization (root) at the top, followed by folders (optional) for grouping, and then projects, which contain the actual service resources.” The project is mandatory: “you need a project resource to use Google Cloud.”

The level worth identifying in any of them is the one that is a hard boundary — the account, the subscription, the project. That is where isolation and most quotas live, and it is the level whose count you will argue about.

What each level decides

The useful question about a hierarchy is not how deep it goes but what attaches where. Position decides several things at once, and they do not all move together.

• Which policies reach the resource. Anything attached above it applies, which is what makes a grouping level useful in the first place.
• Who can see and act on it. In some providers a grant above the resource is a real grant — see the next section.
• Which quotas it counts against. Limits are counted per boundary, so an estate that outgrows a limit is split rather than tuned.
• Whose cost it is. Cost reporting follows the tree, which is why the structure is a finance artifact as much as a technical one.

They are decided by position, which is why hierarchies are hard to redesign — but they do not all change together, and being precise about which move changes what saves a lot of wasted planning.

• Moving a boundary to a different parent — a project into another folder, a subscription under another management group — changes what it inherits: policies and grants from above. The boundary itself, its resources, and its own quotas are unaffected.
• Moving a resource to a different boundary is a different and usually harder operation, and is not supported for every resource type. This is the move that changes quota accounting and, often, identifiers.
• Changing who pays is separate again. Billing association is not the same relationship as the container tree — in Google Cloud a billing account sits outside the resource hierarchy and is linked to projects — so a reorganization can leave cost reporting exactly where it was, or vice versa.

What makes redesign expensive, then, is rarely the move itself: it is the policies, access grants, and reports that were written against the old position and have to be found.

Inheritance is not the same in every provider

This is the difference that surprises people moving between clouds, and it is worth stating as a direction rather than a feature.

Azure and Google Cloud inherit allow. Azure: “any Azure role can be assigned to a management group that inherits down the hierarchy to the resources.” Google Cloud: “IAM roles granted on a folder resource are inherited by all project and folder resources in that folder.” One grant high in the tree therefore hands out access to everything beneath it.

AWS does not inherit grants. What attaches to a root or OU is a service control policy, and “SCPs do not grant permissions to the IAM users and IAM roles in your organization. No permissions are granted by an SCP.” Access is granted inside each account instead.

Restriction from above is a separate mechanism, and all three have one — which is the part most comparisons get wrong. Google Cloud deny policies attach to “an organization, folder, or project,” are “also effective for all resources inside” that node, and take precedence: “IAM always checks relevant deny policies before checking relevant allow policies.” Their scope is limited — “only some permissions can be denied” — so the list of supported permissions is what to check before relying on one.

A broad grant near the top is a much larger mistake where allow is inherited, so the review around those grants should be heavier. And tightening a grant is not the same as blocking: reducing a high-level role assignment leaves permissions granted lower down in place, which is why an explicit deny from above — an SCP, or a deny policy where the permission is supported — is the mechanism for nobody may do this, whatever they were granted. Neither arrangement removes the need for least privilege; they change where the answer is written.

One exemption is documented and easy to miss. An AWS authorization policy on the root “applies to all organizational units (OUs) and member accounts in the organization. It does not apply to the management account in the organization.” A hierarchy is not a guarantee that every principal is covered.

Where to put the boundaries

Since the boundary carries isolation, quotas, and billing, the questions that decide how finely to split often disagree with each other, which is why the answer is a judgment rather than a formula.

• What must not reach what. The strongest reason for a separate boundary, and the one to satisfy first.
• Who operates it. A team that deploys independently is easier to serve with its own boundary than with a shared one and a naming convention.
• Which rules apply. Group by governance regime rather than by organizational chart: teams reorganize, and the rules for regulated data do not.
• What the limits force. Sometimes the split is not a design choice at all but a quota, which is worth discovering before the estate is built.

Start smaller than the target and leave room: a root, a few grouping nodes for the governance regimes you actually have, and boundaries per workload and environment. Deep trees built in advance for an organization that does not exist yet are the common failure, because every level is a place policy can hide.

An operational detail from the Azure documentation generalizes. New subscriptions “automatically default to the root management group when they’re created.” Wherever a provider has a default landing spot, resources will accumulate there unless something moves them, so the process that places a new boundary in the tree is part of the design rather than an afterthought.

How the hierarchy fits with identity, network topology, and guardrails in a prepared environment is covered under landing zone. How the three providers’ trees compare, and what that means when moving between them, is worked through in The Diagram Ports and the Design Does Not.

References: AWS Organizations User Guide, Terminology and concepts; AWS Organizations User Guide, Service control policies; Microsoft Learn, Organize your resources with management groups; Google Cloud, Resource hierarchy; Google Cloud, Deny policies.