Resource Hierarchy

A resource hierarchy organizes cloud resources into administrative and policy scopes. Position affects inherited permissions and governance, but does not alone establish network, performance, failure, or cost isolation. Billing associations and service-specific resource structures can follow different relationships.

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. Organizations has one root, nested OUs, and accounts containing resources. OUs can nest up to five levels below the root. Below accounts, Resource Groups can collect resources using tags or CloudFormation stack membership, alongside service-specific structures. These are not an exact equivalent of Azure’s general resource-group scope.
• Azure. Management groups sit above subscriptions; subscriptions contain resource groups, which contain resources. Management groups can nest up to six levels excluding the root and subscription levels. Each management group or subscription has one parent.
• Google Cloud. Organizations contain optional folders and projects. Projects contain service resources and can include service-specific containers: BigQuery datasets organize tables and views and provide an access-control scope.

Accounts, subscriptions, and projects are useful administrative scopes, not universal isolation guarantees. Check inherited access, cross-boundary grants, network sharing, performance dependencies, and the scope of each quota separately. Separate containers can still depend on the same provider service or region.

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 apply. Evaluate inheritance together with policy type, supported operations, assignment scope, exclusions, and exemptions. An attachment above a resource does not mean every request is covered.
• Who can see and act on it. In some providers a grant above the resource is a real grant — see the next section.
• Which quota it consumes. Limits can apply to projects, regions, networks, instances, or other units. Identify the exact scope and whether an adjustment, cleanup, or workload change can address the limit before splitting the estate.
• How costs are assigned. The hierarchy can help organize reporting, but billing associations, owner mappings, tags, usage records, and shared-cost rules determine the allocation.

These relationships overlap without being identical. When planning a reorganization, separate inherited-policy changes, resource moves, quota effects, and billing changes.

• Moving a project to a different folder or a subscription to a different management group changes inherited policy and grants without itself moving the contained resources to a new project or subscription. Check the particular quota’s scope and any policy changes affecting use; do not treat the hierarchy move as either a resource migration or a quota increase.
• 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

Separate inherited grants from inherited restrictions. A grant can permit covered actions on descendants; a restriction can limit those actions but does not supply the permission itself.

Azure role assignments supported at management group scope inherit downward; custom roles with DataActions cannot be assigned there. Google Cloud organization and folder grants also inherit. The inherited access remains limited to the role’s permissions and applicable conditions and restrictions, so management access does not automatically establish every kind of data access.

An AWS Organizations service control policy supplies a restriction rather than a grant. IAM identity-based or resource-based policies supply access within the applicable restrictions. This contrast concerns SCP inheritance, not all AWS authorization mechanisms.

AWS SCP exceptions include management-account principals and service-linked roles. An external principal using a direct resource-policy grant is not constrained merely by the resource owner’s SCP; assuming a covered role in that account uses a different principal. A hierarchy diagram does not demonstrate complete principal coverage.

Restrictions also need a scope-specific comparison. Google Cloud deny policies support a defined set of permissions. Azure Policy evaluates supported resource and action rules under its modes and effects, including identity-aware conditions; denyAction supports delete rather than arbitrary IAM actions. An organization-wide requirement must be mapped to controls that actually cover its requests.

Reducing a high-level role does not remove independent grants below it. An applicable explicit deny may block a request, but only within its supported scope and subject to its exceptions. Review effective access rather than assuming any top-level restriction means nobody can perform the action. This remains part of least privilege.

Where to put the boundaries

Administrative delegation, security requirements, billing ownership, and quota scope can favor different groupings. Choose the split by those requirements and verify what remains shared.

• What must be separated. Specify the access, performance, network, or failure impact to contain, then verify that the chosen controls provide it.
• 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 policy needs where useful, and revisit the hierarchy when governance requirements or team responsibilities change. Regulatory rules can change too.
• What limits constrain. Check scope, adjustment options, resource cleanup, and workload changes before deciding that more accounts or projects are necessary.

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.

Azure places new subscriptions in the root management group by default, but hierarchy settings can specify a different default management group. Configure the initial baseline and verify placement during provisioning; later movement is not the only way to keep new subscriptions out of the root. Review inherited access and policy when changing either default placement or an existing parent.

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
• AWS, Resource Groups
• Google Cloud, BigQuery datasets
• Microsoft Learn, Azure Policy overview
• Microsoft Learn, denyAction effect
• Microsoft Learn, Protect your resource hierarchy
• Google Cloud, Cloud Quotas