Google Cloud resource hierarchy

The resource hierarchy in Google Cloud begins with the organization, serving as the root node. It is advisable for businesses to have a single root node, unless specific circumstances dictate otherwise. Folders and projects are used to define lower levels of the hierarchy, allowing for the creation of nested folders to construct the desired structure. Projects, which host workloads, can be created at any level within the hierarchy.

Decide a resource hierarchy for your Google Cloud landing zone

Hierarchy Based on Application Environments

In many organizations, distinct policies and access controls are established for different application environments such as development, production, and testing. Adopting a hierarchy based on application environments simplifies management and configuration by employing standardized policies for each environment. For instance, production environments may have more rigorous security policies compared to testing environments.

Utilize an application environment-based hierarchy when the following conditions are met:

• You have separate application environments with distinct policy and administration requirements.
• You have use cases that necessitate highly customized security or audit requirements.
• Different Identity and Access Management (IAM) roles are required to access Google Cloud resources in different environments.

Avoid this hierarchy if the following conditions apply:

• You do not operate multiple application environments.
• There are no varying application dependencies or business processes across environments.
• There are significant policy differences among regions, teams, or applications.

The diagram below illustrates an example hierarchy for a fictitious financial technology company, example.com.

Decide a resource hierarchy for your Google Cloud landing zone

As shown in the aforementioned diagram, example.com maintains three distinct application environments with different policies, access controls, regulatory requirements, and processes. These environments are:

• Development and QA environment: Managed by internal employees and consultants, this environment entails continuous code deployment and quality assurance. It is not accessible to business consumers. Integration and authentication requirements are less stringent than the production environment, and developers are assigned suitable roles with appropriate permissions. The Development and QA environment exclusively caters to standard application offerings from example.com.
• Testing environment: Dedicated to regression and application testing, this environment supports example.com clients who utilize the company's APIs for their B2B offerings. example.com creates two project types for this purpose:
  • Internal testing projects for internal regression, performance, and configuration related to B2B offerings.
  • Client UAT projects with multi-tenant support, allowing B2B clients to validate their configurations and align with example.com requirements for user experience, branding, workflows, reports, and more.
• Production environment: This environment hosts validated, accepted, and launched product offerings. It adheres to Payment Card Industry Data Security Standard (PCI DSS) regulations, employs hardware security modules (HSMs), and integrates with third-party processors for authentication and payment settlements. The audit and compliance teams play crucial roles in this environment, which boasts tightly controlled access primarily via automated deployment processes.

Hierarchy Based on Regions or Subsidiaries

Certain organizations operate across multiple regions or have subsidiaries conducting business in different geographical locations as a result of mergers or acquisitions. These organizations require a resource hierarchy that leverages Google Cloud's scalability and management options while maintaining the autonomy of regions or subsidiaries with distinct processes and policies. In this hierarchy, subsidiaries or regions serve as the highest-level folders. Deployment procedures typically focus on specific regions.

Opt for a hierarchy based on regions or subsidiaries if the following conditions apply:

• Regions or subsidiaries operate independently.
• Regions or subsidiaries have different operational backbones, digital platform offerings, and processes.
• Your business adheres to different regulatory and compliance standards for regions or subsidiaries.

The following diagram illustrates an example hierarchy of a global organization with two subsidiaries and a holding group structured by regions.

Decide a resource hierarchy for your Google Cloud landing zone

In the above diagram, the hierarchy structure is as follows:

• The first level consists of the folders Subsidiary 1 and Subsidiary 2, representing the two subsidiaries of the company. These folders have distinct access permissions and policies compared to the rest of the organization. Each subsidiary utilizes IAM to restrict access to their projects and Google Cloud resources.
• The folder Holding group represents groups that have common high-level policies across regions.
• The folder Bootstrap represents the common resources required for deploying the Google Cloud infrastructure, as described in the security foundations blueprint.
• Within the Holding group folder, on the second level, there are the following folders:
  • APAC, EMEA, and Americas folders represent various regions within the group, each with its own governance, access permissions, and policies.
  • The Shared infrastructure folder represents resources used globally across all regions.
• Each folder contains various projects responsible for the resources associated with the respective subsidiaries or regions.

Additional folders can be added to separate different legal entities, departments, and teams within the organization.

Hierarchy Based on an Accountability Framework

A hierarchy based on an accountability framework is most suitable when your products operate independently, and organizational units have clearly defined teams responsible for the lifecycle of each product. In these organizations, product owners take accountability for the entire product lifecycle, including processes, support, policies, and access rights. The products within your organization are diverse, with only a few organization-wide guidelines in place.

Consider implementing this hierarchy when the following conditions are met:

• Your organization has clear ownership and accountability for each product.
• Your workloads are independent and do not share many common policies.
• Your processes and external developer platforms are offered as services or product offerings.

The following diagram presents an example hierarchy for an ecommerce platform provider.

Decide a resource hierarchy for your Google Cloud landing zone

The above diagram demonstrates the following hierarchy structure:

• The first level includes folders named Ecommerce Modules and Logistics and Warehousing Modules, representing modules within the platform offering that require the same access permissions and policies throughout the product lifecycle.
• The Reconciliation and Billing folder represents the product teams responsible for end-to-end modules for specific business components within the platform offering.
• The Bootstrap folder represents the common resources required for deploying the Google Cloud infrastructure, as described in the security foundations blueprint.
• Each folder contains various projects that house the independent modules managed by different product teams.

References

https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy