Skip to main content

GCP resource hierarchy

· 2 min read



  • A company size of 200 people seperated into 10 teams.
  • Administer can have the company-wide policy to limit GCP account.
  • Easy way to switch user to the other team.
  • Single login page for user to login
  • Each team wants its own access to its resources.
  • Also, different environment for specific purpose.
  • Sometimes, they need temporarily cooperation between teams.
  • For auditing, bills should be seperated by each team.


  • Google Group to grouping user by team or functionality.
  • Nesting group to organize members within the team.
  • GCP folder to have hiearchy architecture.
  • Set IAM role by Google Group email
  • Set Organization Policy on GCP folder limit resource.
  • Using seperated GCP folder for different enviroment, producion, staging...... .


graph LR R[Organization root] --> A[Team A folder] R[Organization root] --> B[Team B folder] A[Company folder] --> A1[Team A production folder] A[Company folder] --> A2[Team A staging folder] B[Company folder] --> B1[Team B production folder] B[Company folder] --> B2[Team B staging folder] R[Organization root] --> P[playground folder]

Nested Google Group

graph LR subgraph A [Team A Google Group] A1[Team A production Google Group] A2[Team A staging Google Group] end

IAM relationship between Google Group and Google project

graph LR A[Team A Google Group] -- Folder Admin/Owner -->AF[Team A folder] A1[Team A production Google Group] -- Folder Admin/Owner -->A1F[Team A production folder] A2[Team A production Google Group] -- Folder Admin/Owner -->A2F[Team A staging folder] P[playground Google Group] -- Folder Admin/Owner -->PF[Team B playground folder]


Create service account per GCP project as Terraform repo's credential.

graph LR; A[A GCP project] --> AT[A Terraform repo]; AT[A Terraform repo] --> A[A GCP project]; B[B GCP project] --> BT[B Terraform repo]; BT[B Terraform repo] --> B[B GCP project];