What is Google Cloud Resource Hierarchy?

Definition

The Google Cloud Resource Hierarchy is the tree-like structure that organizes all Google Cloud resources:

Organization (root)
  ├── Folders (optional, nested up to 10 deep)
  │     └── Projects
  │           └── Resources (VMs, buckets, datasets, etc.)
  └── Projects (directly under org)

IAM bindings, Org Policies, billing, and several other configurations inherit downward through this hierarchy.

In simple terms:

The hierarchy is the skeleton of your Google Cloud environment — and the path your IAM and policy decisions travel.

---

Why It Matters

• Hierarchy design determines blast radius of bindings, policies, and incidents.
• Folders enable environment / team / business unit separation.
• Inherited IAM means a single Org-level binding can affect every project.
• Org Policies cascade down — fewer rules at top, refined at lower levels.
• Billing structure and VPC architecture often follow hierarchy.

---

Hierarchy Components

1. Organization

• The root of the hierarchy.
• Tied to your Cloud Identity / Workspace domain.
• One organization per primary domain.
• Holds top-level IAM, Org Policies, billing, log sinks.

2. Folders

• Logical containers under the Organization.
• Can be nested up to 10 deep.
• Used for: environment separation (Prod / NonProd), team separation, business unit, region, customer (for SaaS), etc.
• Inherit IAM and Org Policies down.

3. Projects

• Where most resources live.
• Have a project ID, project number, billing account, and IAM policy.
• The unit of API enablement, billing, and logical isolation.
• Recommended: small, purpose-driven projects rather than mega-projects.

4. Resources

• The actual GCP services (Compute Engine VMs, Cloud Storage buckets, BigQuery datasets, Cloud SQL instances, etc.).
• Some support resource-level IAM (GCS buckets, BigQuery datasets, Pub/Sub topics).
• Inherit project-level IAM by default.

---

Common Hierarchy Patterns

Environment-Based

Org
├── Folder: Production
│   ├── Folder: Workloads
│   │   ├── Project: prod-app-001
│   │   └── Project: prod-app-002
│   └── Folder: Shared Services
│       └── Project: prod-shared
├── Folder: Non-Production
│   ├── Project: dev-app-001
│   └── Project: staging-app-001
└── Folder: Sandbox
    └── Project: dev-team-sandbox

Business-Unit-Based

Org
├── Folder: Finance
│   ├── Folder: Production
│   └── Folder: Non-Production
├── Folder: Marketing
│   └── ...
└── Folder: Engineering
    └── ...

SaaS / Multi-Tenant

Org
├── Folder: Tenants
│   ├── Folder: Tenant-001
│   └── Folder: Tenant-002
├── Folder: Shared
└── Folder: Internal

---

How IAM Inherits

• IAM bindings on Organization apply to all folders, projects, and resources.
• Folder bindings apply to all descendants.
• Project bindings apply to all resources in the project.
• Resource bindings apply only to that resource.

Effective permissions on a resource = union of all bindings from Org → Folder → Project → Resource.

---

How Org Policies Cascade

Org Policies (separate from IAM — restrict configurations) cascade similarly:

• Set at Org root for org-wide defaults.
• Refine at folder/project level (some policies allow override).
• Examples: iam.disableServiceAccountKeyCreation, compute.requireOsLogin, region restriction, allowed external IP, etc.

---

Folder Use Cases

Environment Separation

• Apply Production folder bindings to fewer principals; stricter Org Policies.
• Sandbox folder allows broader access, more relaxed policies.

Vendor / Partner Isolation

• Folder per vendor; bindings only for that vendor's roles.

Compliance Boundaries

• Folder for PCI-scoped projects, with stricter SCP-equivalent policies.

Acquisition / Project Migration

• Folder for incoming organization to gradually integrate.

---

Common Hierarchy Mistakes

• Flat structure — all projects directly under Org, no folders.
• Org-level Editor / Owner — disastrous blast radius.
• Single mega-project holding everything.
• Inconsistent naming of folders / projects.
• Folders without owners or governance.
• No Org Policies — bare defaults across the org.
• Production and dev mixed in same project.

---

Real-World Examples

1. Hierarchy Refactor for Compliance

A SaaS company moved from flat-projects to a folder-based hierarchy (Prod / NonProd / Tenants). Allowed scoped Org Policies, cleaner IAM, easier audits.

2. Org-Level Owner Cleanup

A startup audit found 5 users with Org-level Owner. Migrated to scoped Folder/Project Owner roles; reduced effective admin count from 12 to 3.

3. Folder for Acquisition

Acquired company's GCP environment moved into a dedicated folder under the parent org; gradually re-mapped IAM and policies.

4. JIT Folder for Vendor

Vendor work granted within a dedicated Vendor-X folder with Folder-level bindings and Deny policies for everything else. Removal post-engagement = folder cleanup.

---

Best Practices

1. Use folders — even small environments benefit from at least Prod / NonProd / Sandbox.
2. Avoid Org-level Owner / Editor; few principals at Org with very specific roles.
3. Bind at smallest scope — resource if supported, otherwise project.
4. Org Policies at Org root for safe defaults; refine at folder level.
5. Document folder purpose and ownership.
6. Naming conventions for folders and projects (e.g., prod-app-name).
7. Project per workload / environment combination — small projects.
8. Centralized log sinks at Org level → dedicated logging project.
9. VPC design aligned with hierarchy (Shared VPC where appropriate).
10. Continuous review of hierarchy and inheritance impacts.

---

Checklist

• Folders used for at least Prod / NonProd separation?
• Org-level Owner / Editor minimized?
• Project per workload / environment?
• Naming conventions in place?
• Org Policies at Org root with appropriate scope?
• Folders documented with owners?
• Centralized logging across hierarchy?
• Periodic review of hierarchy and effective IAM?

---

How Forestall Helps

Forestall visualizes:

• Your full Google Cloud hierarchy.
• Effective IAM at each level.
• Inherited permissions per principal at any node.
• Risk concentrated at high-level bindings.
• Org Policy gaps relative to recommended baselines.

---

Frequently Asked Questions

Can I have multiple organizations?

Each Cloud Identity / Workspace domain has one organization. Multi-domain companies can have multiple.

How deep can folders nest?

Up to 10 levels.

Can I move projects between folders?

Yes — supported with appropriate permissions.

Should production and dev share a project?

No — separate projects for blast radius and IAM clarity.

Are Org Policies the same as IAM?

No — Org Policies restrict configurations (e.g., allowed regions, allowed APIs); IAM controls who can do what. Both cascade through the hierarchy.

---

Conclusion

The Google Cloud Resource Hierarchy is the foundation of GCP governance. A thoughtful design — folders for environment/team/compliance separation, projects per workload, IAM and Org Policies scoped to the right level — limits blast radius and makes least privilege achievable. Continuously review the hierarchy and the inheritance it produces, and Google Cloud stays organized, governable, and secure as it scales.