[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eContainer resources (organizations, folders, projects) help organize and control access to service resources like virtual machines and clusters within Google Cloud.\u003c/p\u003e\n"],["\u003cp\u003eThe resource hierarchy starts with an organization as the root, followed by optional folders, and then projects, which are the base-level entity for containing service resources.\u003c/p\u003e\n"],["\u003cp\u003eFolders are used to create isolation boundaries between groups of projects, enabling the management of distinct collections for teams or departments.\u003c/p\u003e\n"],["\u003cp\u003eProjects are essential for isolating and managing access to Google Cloud resources, and each project contains settings, permissions, and metadata for the resources within.\u003c/p\u003e\n"],["\u003cp\u003eEach project has a unique project ID, a user-defined project name, and a Google Cloud-provided project number, all used for identification and management.\u003c/p\u003e\n"]]],[],null,["# Create an ownership hierarchy\n\nAs you develop your applications and workloads on Google Cloud, you\ncreate the following resource types:\n\n- *Container resources* help you organize and control access. These resources include organizations, folders, and projects.\n- *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.\n\nYou use container resources to organize service resources in a hierarchy. This\nstructure helps you establish ownership and control access.\n\nOrganize and manage hierarchically\n----------------------------------\n\nTo isolate resources from each other and limit access to users, you can group\nand manage resources as a single unit. You do this using the following\nstructure, known as the resource hierarchy:\n\n- *Organization*: Represents your company, and serves as the root of your resource hierarchy.\n- *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.\n- *Projects*: The base-level organizing entity that contains your service resources.\n\nFor a detailed overview of the resource hierarchy, see [Resource hierarchy](/resource-manager/docs/cloud-platform-resource-hierarchy).\n\nTo learn how to use the resource hierarchy to manage access, see [Using resource hierarchy for access control](/iam/docs/resource-hierarchy-access-control).\n\n### Organization: Create the root of your hierarchy\n\nAn organization is the root node of the hierarchy, under which you create all\nother resources. The access policies you apply to your organization are applied\nto all other resources. This means that you can apply an access control at\nthe organization level instead of duplicating and managing the same control\nacross all projects.\n\nWhen you create an organization resource, underlying projects belong to the\norganization, instead of the users who create projects. This means that\nprojects and their underlying resources can continue to exist, even if a user\nis removed.\n\n### Folders: Isolate groups of projects\n\nYou can use folders to create isolation boundaries between projects. For\nexample, you might have distinct project collections for department or team.\nFolders can contain projects and subfolders. You can apply access controls to\nensure that users in one team cannot access resources in folders assigned to\nanother team.\n\n### Projects: Isolate resources\n\nGoogle Cloud resources must belong to a project, which is an organizing\nentity that helps you isolate and control access to resources. For example, you\nmight create distinct projects for development and production environments.\n\nA project contains settings, permissions, and other metadata that describe your\napplications. Resources within a single project can work together by\ncommunicating through an internal network, subject to regions-and-zones\nrules. A project can't access another project's resources unless you use\n[Shared VPC](/vpc/docs/shared-vpc) or [VPC Network Peering](/vpc/docs/vpc-peering).\n\n#### Name and reference your projects\n\nYou use identifiers to reference your projects in commands and API calls. Each\nGoogle Cloud project has the following identifiers:\n\n- **Project name**: A name that you provide.\n- **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.\n- **Project number**: Provided by Google Cloud.\n\nFor more information, see [Creating and managing projects](/resource-manager/docs/creating-managing-projects)."]]