This document in the Google Cloud Architecture Framework provides best practices to organize and manage your resources in Google Cloud.
Resource hierarchy
Google Cloud resources are arranged hierarchically in organizations, folders, and projects. This hierarchy lets you manage common aspects of your resources like access control, configuration settings, and policies. For best practices to design the hierarchy of your cloud resources, see Decide a resource hierarchy for your Google Cloud landing zone.
Resource labels and tags
This section provides best practices for using labels and tags to organize your Google Cloud resources.
Use a simple folder structure
Folders let you group any combination of projects and subfolders. Create a simple folder structure to organize your Google Cloud resources. You can add more levels as needed to define your resource hierarchy so that it supports your business needs. The folder structure is flexible and extensible.To learn more, see Creating and managing folders.
Use folders and projects to reflect data governance policies
Use folders, subfolders, and projects to separate resources from each other to reflect data governance policies within your organization. For example, you can use a combination of folders and projects to separate financial, human resources, and engineering.
Use projects to group resources that share the same trust boundary. For example, resources for the same product or microservice can belong to the same project. For more information, see Decide a resource hierarchy for your Google Cloud landing zone.
Use tags and labels at the outset of your project
Use labels and tags when you start to use Google Cloud products, even if you don't need them immediately. Adding labels and tags later on can require manual effort that can be error prone and difficult to complete.
A tag provides a way to conditionally allow or deny policies based on whether a resource has a specific tag. A label is a key-value pair that helps you organize your Google Cloud instances. For more information on labels, see requirements for labels, a list of services that support labels, and label formats.
Resource Manager provides labels and tags to help you manage resources, allocate and report on cost, and assign policies to different resources for granular access controls. For example, you can use labels and tags to apply granular access and management principles to different tenant resources and services. For information about VM labels and network tags, see Relationship between VM labels and network tags.
You can use labels for multiple purposes, including the following:
- Managing resource billing: Labels are available in the billing system, which lets you separate cost by labels. For example, you can label different cost centers or budgets.
- Grouping resources by similar characteristics or by relation: You can use labels to separate different application lifecycle stages or environments. For example, you can label production, development, and testing environments.
Assign labels to support cost and billing reporting
To support granular cost and billing reporting based on attributes outside of your integrated reporting structures (like per-project or per-product type), assign labels to resources. Labels can help you allocate consumption to cost centers, departments, specific projects, or internal recharge mechanisms. For more information, see the Cost optimization category.
Avoid creating large numbers of labels
Avoid creating large numbers of labels. We recommend that you create labels primarily at the project level, and that you avoid creating labels at the sub-team level. If you create overly granular labels, it can add noise to your analytics. To learn about common use cases for labels, see Common uses of labels.
Avoid adding sensitive information to labels
Labels aren't designed to handle sensitive information. Don't include sensitive information in labels, including information that might be personally identifiable, like an individual's name or title.
Anonymize information in project names
Follow a project naming pattern like
COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME,
where the placeholders are unique and don't reveal company or application
names. Don't include attributes that can change in the future, for example, a
team name or technology.
Apply tags to model business dimensions
You can apply tags to model additional business dimensions like organization structure, regions, workload types, or cost centers. To learn more about tags, see Tags overview, Tag inheritance, and Creating and managing tags. To learn how to use tags with policies, see Policies and tags. To learn how to use tags to manage access control, see Tags and access control.
Organizational policies
This section provides best practices for configuring governance rules on Google Cloud resources across the cloud resource hierarchy.
Establish project naming conventions
Establish a standardized project naming convention, for example,
SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).
Project names have a 30-character limit.
Although you can apply a prefix like COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG,
project names can become out of date when companies go through reorganizations.
Consider moving identifiable names from project names to project labels.
Automate project creation
To create projects for production and large-scale businesses, use an automated process like the Deployment Manager or the Google Cloud project factory Terraform module. These tools do the following:
- Automatically create development, test, and production environments or projects that have the appropriate permissions.
- Configure logging and monitoring.
The Google Cloud project factory Terraform module helps you to automate the creation of Google Cloud projects. In large enterprises, we recommend that you review and approve projects before you create them in Google Cloud. This process helps to ensure the following:
- Costs can be attributed. For more information, see the Cost optimization category.
- Approvals are in place for data uploads.
- Regulatory or compliance requirements are met.
When you automate the creation and management of Google Cloud projects and resources, you get the benefit of consistency, reproducibility, and testability. Treating your configuration as code lets you version and manage the lifecycle of your configuration together with your software artifacts. Automation lets you support best practices like consistent naming conventions and labeling of resources. As your requirements evolve, automation simplifies project refactoring.
Audit your systems regularly
To ensure that requests for new projects can be audited and approved, integrate with your enterprise's ticketing system or a standalone system that provides auditing.
Configure projects consistently
Configure projects to consistently meet your organization's needs. Include the following when you set up projects:
- Project ID and naming conventions
- Billing account linking
- Networking configuration
- Enabled APIs and services
- Compute Engine access configuration
- Logs export and usage reports
- Project removal lien
Decouple and isolate workloads or environments
Quotas and limits are enforced at the project level. To manage quotas and limits, decouple and isolate workloads or environments at the project level. For more information, see Working with quotas.
Decoupling environments is different from data classification requirements. Separating data from infrastructure can be expensive and complex to implement, so we recommend that you implement data classification based on data sensitivity and compliance requirements.
Enforce billing isolation
Enforce billing isolation to support different billing accounts and cost visibility per workload and environment. For more information, see Create, modify, or close your self-serve Cloud Billing account and Enable, disable, or change billing for a project.
To minimize administrative complexity, use granular access management controls for critical environments at the project level, or for workloads that spread across multiple projects. When you curate access control for critical production applications, you ensure that workloads are secured and managed effectively.
Use the Organization Policy Service to control resources
The Organization Policy Service gives policy administrators centralized and programmatic control over your organization's cloud resources so that they can configure constraints across the resource hierarchy. For more information, see Add an organization policy administrator.
Use the Organization Policy Service to comply with regulatory policies
To meet compliance requirements, use the Organization Policy Service to enforce compliance requirements for resource sharing and access. For example, you can limit sharing with external parties or determine where to deploy cloud resources geographically. Other compliance scenarios include the following:
- Centralizing control to configure restrictions that define how your organization's resources can be used.
- Defining and establishing policies to help your development teams remain within compliance boundaries.
- Helping project owners and their teams make system changes while maintaining regulatory compliance and minimizing concerns about breaking compliance rules.
Limit resource sharing based on domain
A restricted sharing organization policy helps you to prevent Google Cloud resources from being shared with identities outside your organization. For more information, see Restricting identities by domain and Organization policy constraints.
Disable service account and key creation
To help improve security, limit the use of Identity and Access Management (IAM) service accounts and corresponding keys. For more information, see Restricting service account usage.
Restrict the physical location of new resources
Restrict the physical location of newly created resources by restricting resource locations. To see a list of constraints that give you control of your organization's resources, see Organization Policy Service constraints.
What's next
Learn how to choose and manage compute, including the following:
Explore other categories in the Architecture Framework such as reliability, operational excellence, and security, privacy, and compliance.