<p>Google's <a href="https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations" rel="nofollow noreferrer">recommended best practice</a> is to create an <a href="https://cloud.google.com/resource-manager/docs/creating-managing-organization" rel="nofollow noreferrer">Organisation</a> within GCP so that you get access to <a href="https://cloud.google.com/resource-manager/docs/creating-managing-folders" rel="nofollow noreferrer">folders</a>, then model the hierarchy of your organisation within GCP:</p>

<p><a href="https://i.sstatic.net/KGoYd.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/KGoYd.png" alt="Sample Organisation Structure"></a> </p>

<p>Some guidance/rules:</p>

<ol>
<li>there should only be one organisation that represents the entire organisation; configuring directory sync is very painful otherwise.</li>
<li>folders should represent business units</li>
<li>projects should represent instances of an app or component</li>
<li>use different projects for each environment, because each environment is generally an instance of an app or component</li>
<li>fully qualify the names of each folder or project, because GCP often doesn't show the full path to the project.  Consider there are intentionally two applications named <code>mgmt-prod</code> in the above diagram.  However, because they are called <code>amido-ops-pmo-mgmt-prod</code> and <code>amido-people-mgmt-prod</code> it's easy to tell just from the project name what they are.</li>
</ol>

<p>The significant advantage of this model is that you can create a group called <code>TechOps</code> and give it audit or read permission at the Organisation level. Those people will have access to the entire estate.  Equally, you can also grant granular permissions at the folder and project level based upon business requirements.</p>

CC BY-SA 4.0
2021-06-03T03:18:20.660Z
Hi Richard, you suggest only 1 org, however is there any benefit to separate orgs for different environments? The only reason I can think is from a security perspective if an account was to be compromised they would only gain access to that single environment and not a single account that might have permissions across multiple environments at any given time.
Ari
CC BY-SA 4.0
2021-06-16T12:11:33.680Z
You can implement segregation of duties through the hierarchical folder model, it's likely that there will always be some kind of account that has access to all environments, you're goal however should be those organisational admin accounts are never used operationally. Having multiple organisations is possible, although you will have to register and manage a separate Google Cloud Identity directory which might cause you some headaches from a single sign in perspective.  IMHO multiple organisations is overkill.
Richard Slater
CC BY-SA 4.0
2019-10-25T10:50:51.957Z
2019-10-25T10:50:51.957Z
Richard Slater
<p>We have two projects: production and staging. Later runs dev, qa also. And for billing purpose, we tag resources accordingly. </p>

CC BY-SA 3.0
2018-03-01T18:33:58.570Z
2018-03-01T18:33:58.570Z
Hungry Mind
<p>Speaking primarily from the Google App Engine (GAE) perspective.</p>

<p>My preference is for environment-driven project split. This might be of interest: <a href="https://stackoverflow.com/questions/43218971/advantages-of-implementing-ci-cd-environments-at-gae-project-app-level-vs-servic">Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?</a></p>

<p>I wouldn't go for architecturally-driven project split unless there are serious reasons for doing so (if you feel you have such reasons you should ask with details):</p>

<ul>
<li>probably difficult (if not impossible) to avoid inter-project bandwidth charges</li>
<li>added configuration complexity for inter-operation between projects (GCP pretty much considers them completely isolated/standalone, except maybe for shared IAM permissions). Possibly relevant: <a href="https://stackoverflow.com/questions/48962493/google-app-engine-access-cross-project-resources">Google app engine access cross project resources</a></li>
</ul>

<p>Depending on the GCP products used there may be sufficient support for architectural splits inside the same project. At least GAE does IMHO.</p>

<p>My GAE apps are all standalone and do not use inter-networking at all, so no costs from this perspective. There are still networking (bandwidth) costs for accessing various GCP-provided infra/services, but those are irellevant/unavoidable from the project split perspective.</p>

CC BY-SA 4.0
2018-02-28T18:16:56.670Z
2019-10-25T02:19:04.197Z
2019-10-25T02:19:04.197Z
Dan Cornilescu
<p>I have recently inherited the previous director of devops duties in managing a transition from Heroku/AWS to GCP. I'm wondering what is best practice for organizing projects in GCP.</p>

<p>Should the be organized by production, staging, and QA environments? Should they be organized by each individual self contained front-end project or middleware project? If so, where do databases live in that function? The middleware project?</p>

<p>You can see how many core questions can lead to adjacent questions.. does anyone have best practices here about how they organize their GCP projects in the enterprise?</p>

<p>Corollary question: how does your project organization affect cost or inter-networking?</p>

<p>Thanks!</p>

<architecture><gcp>
How should GCP projects be organized?
Dan
# How should GCP projects be organized?

(Asked by: username_0 on 2018-02-28)

I have recently inherited the previous director of devops duties in managing a transition from Heroku/AWS to GCP. I'm wondering what is best practice for organizing projects in GCP.

Should the be organized by production, staging, and QA environments? Should they be organized by each individual self contained front-end project or middleware project? If so, where do databases live in that function? The middleware project?

You can see how many core questions can lead to adjacent questions.. does anyone have best practices here about how they organize their GCP projects in the enterprise?

Corollary question: how does your project organization affect cost or inter-networking?

Thanks!

**Tags:** architecture, gcp


---

## 3 answers

### Answer by username_4 on 2018-02-28. Score: 5 | Accepted answer

Speaking primarily from the Google App Engine (GAE) perspective.

My preference is for environment-driven project split. This might be of interest: [Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?](https://stackoverflow.com/questions/43218971/advantages-of-implementing-ci-cd-environments-at-gae-project-app-level-vs-servic)

I wouldn't go for architecturally-driven project split unless there are serious reasons for doing so (if you feel you have such reasons you should ask with details):

* probably difficult (if not impossible) to avoid inter-project bandwidth charges
* added configuration complexity for inter-operation between projects (GCP pretty much considers them completely isolated/standalone, except maybe for shared IAM permissions). Possibly relevant: [Google app engine access cross project resources](https://stackoverflow.com/questions/48962493/google-app-engine-access-cross-project-resources)

Depending on the GCP products used there may be sufficient support for architectural splits inside the same project. At least GAE does IMHO.

My GAE apps are all standalone and do not use inter-networking at all, so no costs from this perspective. There are still networking (bandwidth) costs for accessing various GCP-provided infra/services, but those are irellevant/unavoidable from the project split perspective.


---

### Answer by username_1 on 2019-10-25. Score: 4

Google's [recommended best practice](https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations) is to create an [Organisation](https://cloud.google.com/resource-manager/docs/creating-managing-organization) within GCP so that you get access to [folders](https://cloud.google.com/resource-manager/docs/creating-managing-folders), then model the hierarchy of your organisation within GCP:

[![Sample Organisation Structure](https://i.sstatic.net/KGoYd.png)](https://i.sstatic.net/KGoYd.png)

Some guidance/rules:

1. there should only be one organisation that represents the entire organisation; configuring directory sync is very painful otherwise.
2. folders should represent business units
3. projects should represent instances of an app or component
4. use different projects for each environment, because each environment is generally an instance of an app or component
5. fully qualify the names of each folder or project, because GCP often doesn't show the full path to the project. Consider there are intentionally two applications named `mgmt-prod` in the above diagram. However, because they are called `amido-ops-pmo-mgmt-prod` and `amido-people-mgmt-prod` it's easy to tell just from the project name what they are.

The significant advantage of this model is that you can create a group called `TechOps` and give it audit or read permission at the Organisation level. Those people will have access to the entire estate. Equally, you can also grant granular permissions at the folder and project level based upon business requirements.

> **Comments:**
> **username_2**: Hi Richard, you suggest only 1 org, however is there any benefit to separate orgs for different environments? The only reason I can think is from a security perspective if an account was to be compromised they would only gain access to that single environment and not a single account that might have permissions across multiple environments at any given time.  
> **username_1**: You can implement segregation of duties through the hierarchical folder model, it's likely that there will always be some kind of account that has access to all environments, you're goal however should be those organisational admin accounts are never used operationally. Having multiple organisations is possible, although you will have to register and manage a separate Google Cloud Identity directory which might cause you some headaches from a single sign in perspective.  IMHO multiple organisations is overkill.  

---

### Answer by username_3 on 2018-03-01. Score: 2

We have two projects: production and staging. Later runs dev, qa also. And for billing purpose, we tag resources accordingly.


---

