Resource Hierarchy
Resource hierarchy in Google Cloud provides a structured way to organize resources, enforce access control, and manage billing visibility. A well designed hierarchy is critical for governance, security, and long term scalability.
Without a defined hierarchy, organizations often face isolated projects, inconsistent access policies, limited visibility, and fragmented billing.
What is Resource Manager
Resource Manager is the service used to build and manage the Google Cloud resource hierarchy. It serves two primary purposes:
- Organize cloud resources to match organizational structure and workflows
- Act as a centralized point for applying IAM and organization policies
Resource Manager also enables centralized billing and usage reporting across projects.
Resource hierarchy components
Google Cloud resource hierarchy consists of three main containers.
Organization
The organization is the root node of the hierarchy. It represents the company and is created when a domain is verified using Cloud Identity. All folders and projects exist under the organization node.
Folders
Folders are used to group projects logically. They allow IAM and organization policies to be applied consistently across multiple projects. Folders are commonly used to represent teams, environments, or business units.
Projects
Projects contain actual Google Cloud resources such as virtual machines, databases, and storage. Projects are the primary boundary for IAM enforcement and service enablement.
IAM inheritance model
IAM policies follow a top down inheritance model.
- Policies applied at the organization level are inherited by all folders and projects
- Policies applied at a folder level are inherited by child folders and projects
- Policies applied at the project level apply only to that project
Inheritance is additive only. Permissions granted at a parent level cannot be denied at a lower level.
Common hierarchy patterns
There is no single correct hierarchy design. The right pattern depends on how the organization manages teams, environments, and billing.
Team oriented hierarchy
Organization
Teams
Environments
Projects
This model works well when teams own their environments and billing is shared.
Business unit oriented hierarchy
Organization
Business units
Teams
Environments
Projects
This pattern is useful when billing and ownership need to be separated by business unit.
Environment oriented hierarchy
Organization
Environments
Business units or teams
Projects
This model is effective when strong environment isolation is required.
Designing the right hierarchy
When designing a hierarchy, consider:
- How teams are structured
- How environments are separated
- How billing should be tracked
- Where policies should be enforced
A good hierarchy minimizes duplication, simplifies access management, and supports future growth.
Provisioning the hierarchy
The Setup your Foundation workflow in the Google Cloud Console helps visualize and deploy the resource hierarchy.
This workflow allows:
- Previewing the hierarchy before deployment
- Customizing team and environment names
- Creating shared projects for networking, logging, and monitoring
- Assigning IAM roles to groups at folder and project levels
Configurations can be saved, reviewed, and deployed using the console or Terraform.
Deployment and validation
Provisioning typically takes around thirty minutes. After deployment, validation includes:
- Reviewing folders and projects in Resource Manager
- Verifying IAM role bindings at each level
- Confirming billing and policy inheritance
Outcome
A well implemented resource hierarchy provides consistent governance, centralized access control, and clear billing management. It enables organizations to scale securely on Google Cloud while maintaining visibility and control.