After we have outlined the importance of a Landing Zone for a successful cloud journey in the first part and having discussed Cloud Identity and its federation with Active Directory and Entra ID, now it is time to move to next part of our Landing Zone series – Resource hierarchies.
The Google Cloud is an excellent choice for your cloud journey – and the resource hierarchy is certainly one of the (many) reasons for it.
What is a resource hierarchy?
Let’s begin with what a resource hierarchy actually is.
In Google Cloud, a resource hierarchy is a structured framework that organizes all the resources (like VM instances, storage buckets, databases) you use on Google Cloud Platform (GCP). This structure is crucial for managing and administering your resources, especially as it pertains to organizing, managing access and permissions, and tracking costs. The hierarchy provides a clear, logical structure for grouping and segregating resources, facilitating governance, and cost management across an organization.
The hierarchy levels, from broadest to most specific, are:
1. Organization: The top-level container that represents your company. It is the root node in the Google Cloud resource hierarchy and provides centralized visibility and control over all GCP resources. Organizations are associated with a Google Workspace or Cloud Identity account.
2. Folders: Folders can contain projects or other folders, allowing you to group projects that share common attributes, such as the same team, application, environment (development, test, production), or other categorizations relevant to your organization. Folders help you manage access control and policies at a more granular level than the organization.
3. Projects: Projects are the fundamental grouping of resources and services in GCP. Every resource belongs to a project. Projects serve as a basis for enabling and using GCP services like compute engines, storage buckets, and database services, tracking and managing Google Cloud costs, managing permissions, and enabling billing. They can be used to represent logical divisions like different environments (prod, dev, test) or different parts of your organization.
4. Resources: At the bottom of the hierarchy, resources are the individual GCP services and components you use, such as Compute Engine instances, Cloud Storage buckets, or BigQuery datasets. Resources inherit policies and permissions from the project they are part of and can have additional policies applied directly to them.
This hierarchy allows you to apply permissions and policies at the level that makes the most sense. For example, you can set broad policies at the organization level (applicable to all resources within the organization), more specific policies at the folder or project level, and highly specific policies at the resource level. The structure also simplifies billing and resource management by allowing you to group and manage resources based on your organization’s operational needs and structure.
The following picture depicts a resource hiarchy in the Google Cloud:
What are design considerations for a resource hiarchary?
Designing a resource hierarchy in Google Cloud requires careful planning and consideration to ensure it effectively meets your organization’s needs for governance, cost management, security, and compliance. The design should be scalable, flexible, and capable of adapting to future changes in your organization or technology strategy. Here are some key considerations:
1. Organization Structure
Align the hierarchy with your organization’s structure to facilitate management and operational efficiency.
Consider how different departments, teams, or business units will use Google Cloud resources and how you can best structure projects and folders to reflect these use cases.
2. Resource Management and Governance
Plan for how resources will be managed, including who will have administrative control at various levels of the hierarchy.
Determine how to implement policies for resource usage, access control, and cost management effectively across the hierarchy.
3. Access Control and Security
Use the principle of least privilege to manage permissions; grant users only the access they need to perform their roles.
Structure your hierarchy to simplify the management of IAM policies and ensure secure access to resources.
Consider using folders to delegate administrative responsibilities and segregate environments (e.g., development, staging, production) for enhanced security.
4. Billing and Cost Management
Organize projects in a way that aligns with your billing and budgetary requirements.
Utilize folders to group projects by cost center or department to simplify billing management.
Leverage billing accounts and subaccounts effectively to manage and track costs.
5. Compliance and Regulatory Requirements
Ensure your resource hierarchy supports compliance with relevant laws and regulations.
Structure your hierarchy to isolate resources subject to specific regulatory requirements, facilitating easier compliance audits and controls.
6. Scalability and Flexibility
Design for future growth; consider how new teams, projects, or services can be added to the hierarchy without major reorganizations.
Ensure the hierarchy allows for flexibility in resource management, scaling, and reorganization as needed.
7. Environment Segregation
Clearly segregate resources for different environments (development, testing, production) to prevent unintended access or changes to critical systems.
Use projects or folders to isolate environments, applying policies and permissions accordingly to manage access and resource deployment.
8. Naming Conventions
Establish clear naming conventions for projects, folders, and resources to improve clarity and manageability.
Use meaningful names that reflect the resource’s purpose, environment, and associated team or department.
9. Policy Inheritance
Understand how policies are inherited in the hierarchy and design your structure to leverage this for efficient policy management.
Plan how to apply organization-wide policies (e.g., security policies) and how to override these policies at lower levels when necessary.
Are there any best practices and patterns?
So, as you can see, designing a resource hierarchy can be challenging at first sight. Fortunately, there are some patterns that can be widely seen as discussed above. As they are important, let’s recap some of them:
- Isolate environments into separate projects or folders. As a pattern you can zse folders to group projects by environment, then apply environment-specific policies at the folder level.
- Centralize logging and monitoring to a dedicated project. As a pattern, create a “shared services” project for centralized logging, monitoring, and auditing. Use aggregated log sinks to collect logs from all projects.
- Structure projects in a way that aligns with organizational billing and budgetary needs. The pattern would be to assign a billing account to projects or folders based on budgetary ownership.
- Design projects around logical groupings of resources that share the same lifecycle, security requirements, and team. In this case the pattern is Create projects based on applications, microservices, or teams, rather than a single monolithic project for all resources.
