As you develop your applications and workloads on Google Cloud, you create the following resource types:
- Container resources help you organize and control access. These resources include organizations, folders, and projects.
- Service resources are fundamental components that make up Google Cloud products and services. These resources include Compute Engine virtual machines (VMs) and Google Kubernetes Engine clusters.
You use container resources to organize service resources in a hierarchy. This structure helps you establish ownership and control access.
Organize and manage hierarchically
To isolate resources from each other and limit access to users, you can group and manage resources as a single unit. You do this using the following structure, known as the resource hierarchy:
- Organization: Represents your company, and serves as the root of your resource hierarchy.
- Folders: An optional grouping mechanism you can use to isolate groups of projects. For example, you might create folders for legal entities, departments, or teams.
- Projects: The base-level organizing entity that contains your service resources.
For a detailed overview of the resource hierarchy, see Resource hierarchy.
To learn how to use the resource hierarchy to manage access, see Using resource hierarchy for access control.
Organization: Create the root of your hierarchy
An organization is the root node of the hierarchy, under which you create all other resources. The access policies you apply to your organization are applied to all other resources. This means that you can apply an access control at the organization level instead of duplicating and managing the same control across all projects.
When you create an organization resource, underlying projects belong to the organization, instead of the users who create projects. This means that projects and their underlying resources can continue to exist, even if a user is removed.
Folders: Isolate groups of projects
You can use folders to create isolation boundaries between projects. For example, you might have distinct project collections for department or team. Folders can contain projects and subfolders. You can apply access controls to ensure that users in one team cannot access resources in folders assigned to another team.
Projects: Isolate resources
Google Cloud resources must belong to a project, which is an organizing entity that helps you isolate and control access to resources. For example, you might create distinct projects for development and production environments.
A project contains settings, permissions, and other metadata that describe your applications. Resources within a single project can work together by communicating through an internal network, subject to regions-and-zones rules. A project can't access another project's resources unless you use Shared VPC or VPC Network Peering.
Name and reference your projects
You use identifiers to reference your projects in commands and API calls. Each Google Cloud project has the following identifiers:
- Project name: A name that you provide.
- Project ID: An identifier that you can provide or Google Cloud can provide for you. Each project ID is unique across Google Cloud. After you delete a project, its ID can never be used again.
- Project number: Provided by Google Cloud.
For more information, see Creating and managing projects.