第一次使用 Google Cloud，需要先理解项目、组织、账号和资源之间的关系

第一次使用 Google Cloud，很多用户最容易混淆的并不是具体的云服务，而是 Google Cloud 本身的资源管理体系。账号、组织、文件夹、项目、资源以及计费账户分别承担不同职责，如果没有先理解这些概念之间的关系，后续进行权限配置、资源部署、成本管理和安全策略设置时，很容易出现概念混乱。

Google Cloud 的资源管理体系并不是简单的“账号下面创建项目，项目下面创建服务器”这么简单。对于企业环境，更准确的理解方式是将它分成两个相互关联的体系：一套负责身份和权限，另一套负责资源的层级组织。

Google Cloud 的资源层级通常可以表示为：

Organization → Folder → Project → Service Resources

其中 Organization 是组织层级的根节点，Folder 是可选的分组层级，Project 是绝大多数 Google Cloud 服务资源的直接管理边界，而 Compute Engine 虚拟机、Cloud Storage 存储桶、Pub/Sub 主题等具体服务资源则位于 Project 之下。Google 官方文档明确指出，除最高层的 Organization 外，资源层级中的资源都有父级；Folder 可以包含其他 Folder 或 Project，而具体服务资源属于 Project。

账号首先解决的是“你是谁”

这里首先需要纠正一个容易产生误解的概念：Google 账号并不是 Google Cloud 资源层级中的一个父级节点。

用户通过 Google 账号、Google Workspace 身份、Cloud Identity 身份，或者其他受支持的身份形式进行身份验证。Google Cloud 的 IAM（Identity and Access Management）则根据这个身份，也就是 principal，判断用户、群组或服务账号拥有哪些权限。

因此，“账号”主要回答的是：

你是谁？

而 Google Cloud 的资源层级回答的是：

你可以管理哪些资源？

例如，一个企业员工可以使用公司 Google Workspace 账号登录 Google Cloud，然后通过 IAM 获得某个 Project 的权限。另一个员工也可以使用自己的账号访问同一个 Project，但两人的角色可能完全不同。

因此，不应该把“一个账号对应一个项目”或者“一个账号拥有独立的一套资源”作为 Google Cloud 的基本架构来理解。

一个用户身份可以被授予多个 Project、Folder 甚至 Organization 层级的权限；同一个 Project 也可以由多个用户、群组和服务账号共同管理。

Organization 是企业云环境的根节点

对于使用 Google Workspace 或 Cloud Identity 的企业，Organization 是 Google Cloud 资源层级的最高节点。

Organization 通常代表一个企业、机构或者其他组织实体，是 Folder 和 Project 的上级资源。组织级别可以设置 IAM 权限和 Organization Policy 等管理策略，这些策略可以沿资源层级向下继承。

因此，Organization 主要解决的是企业级的集中管理问题。

例如，一家公司可能拥有几十甚至几百个 Google Cloud Project。如果每个 Project 都完全独立管理，那么企业很难统一实施安全政策、权限控制和合规要求。

在 Organization 层级设置相应策略后，可以让这些政策向下作用于 Folder、Project 以及更低层级的资源。

需要注意的是，Organization 并不是一个“超级项目”，也不是用来直接运行虚拟机或者部署应用程序的地方。它更接近整个 Google Cloud 企业资源体系的根节点和治理层。

对于没有企业 Organization 的个人用户，Project 可以处于没有 Organization 的层级中。Google 官方也明确区分了有 Organization 和没有 Organization 的 Project。

Folder 是大型组织中的中间管理层

原文中所谓的“组织单位（Organization Unit）”容易让人联想到 Google Workspace 中的 Organizational Unit，但在 Google Cloud 的资源层级中，正确的概念是 Folder。

Folder 是 Organization 与 Project 之间的可选层级。

一个 Folder 可以包含多个 Project，也可以继续包含其他 Folder。因此，大型企业可以根据部门、地区、业务线或者环境进行组织。

例如：

Organization

→ 加拿大业务 Folder
→ 美国业务 Folder
→ 数据科学 Folder
→ 生产环境 Folder
→ 开发测试 Folder

Folder 的真正价值不只是“整理项目”，更重要的是可以成为权限和组织策略的管理边界。

例如，公司可以在某个 Folder 层级授予一个团队相应权限，那么这些权限可以按照 IAM 的继承机制作用于该 Folder 下的子资源。这样就不需要逐个 Project 重复配置相同的权限。

不过，Folder 并不是所有用户都必须使用的结构。Google 官方也建议根据实际管理需求选择合适的层级。对于规模较小的环境，完全可以保持简单的 Organization → Project 结构，而没有必要为了“看起来专业”建立复杂的 Folder 层级。

Project 是 Google Cloud 中非常重要的管理边界

Project 是第一次使用 Google Cloud 时最需要理解的概念之一。

绝大多数 Google Cloud 服务都需要依附于 Project 使用。Compute Engine 虚拟机、Cloud Storage、Pub/Sub、BigQuery 等服务资源通常都位于某个 Project 之下。

Project 不只是一个“文件夹”，它同时承担多项重要职责。

首先，Project 是很多 Google Cloud API 和服务启用的基础。其次，IAM 权限可以在 Project 层级设置。再次，Project 是资源组织、成本分析以及许多配额和服务配置的重要边界。

Google 官方将 Project 描述为 Google Cloud 中的基础组织实体，服务级资源以 Project 作为父级。

因此，实际部署应用时，通常不是直接在 Organization 下面创建一台虚拟机，而是先创建 Project，然后在 Project 中启用所需 API，再创建 Compute Engine 实例、数据库、存储桶等具体资源。

Project 还具有自己的 Project ID 和 Project Number。Project ID 通常由用户在创建项目时指定，而 Project Number 则由 Google Cloud 自动分配，两者用途不同。

Resource 才是实际运行服务的对象

Project 下面才是用户真正部署和使用的服务资源。

例如：

Compute Engine 虚拟机是一种资源。

Cloud Storage 存储桶是一种资源。

BigQuery 数据集是一种资源。

Pub/Sub 主题和订阅也是资源。

这些资源并不是孤立存在的，而是属于相应的 Project。

这种结构带来的一个重要好处是，企业可以围绕 Project 组织一组具有共同生命周期、权限和成本管理需求的资源。

例如，一个电商网站可以建立一个生产 Project，把计算、网络、数据库、存储以及监控相关资源放在一起；同时建立一个独立的开发 Project，用于测试新的程序和配置。

这样做的目的并不是简单地“隔离服务器”，而是建立清晰的管理边界。

IAM 权限不是简单地存在于账号里面

另一个非常重要的概念是 IAM。

IAM 并不是简单地给“账号”设置一个全局权限，而是通过 principal + role + resource 的方式控制访问。

例如，可以把某个用户或者 Google Group 授予一个 Project 的特定角色，也可以在 Folder 或 Organization 层级授予角色。

Google Cloud 的 IAM 权限具有层级继承特征。如果一个主体在 Organization 或 Folder 层级获得某项允许策略，相应权限可以继承到下面的资源。Project 层级的权限也可以继续作用于该 Project 中支持 IAM 的子资源。

因此，权限管理真正需要考虑的不是“这个账号属于哪个项目”，而是：

这个身份在什么资源层级拥有哪个角色？

这也是企业进行最小权限管理时必须理解的核心概念。

Billing Account 与 Project 不是上下级关系

计费也是新用户非常容易混淆的地方。

Cloud Billing Account 并不是 Project 的父级资源，也不是“账号的余额账户”。它是一个独立的计费实体，可以关联一个或多个 Project。

Project 产生的符合计费条件的使用量，会被计入与该 Project 关联的 Cloud Billing Account。Google 官方明确说明，一个 Billing Account 可以关联多个 Project，而 Project 的使用费用由所关联的 Billing Account 支付。

因此，可以把它理解为：

Project负责组织和管理资源，Billing Account负责承担这些资源产生的费用。

一个企业完全可以拥有多个 Project，并让它们使用同一个中央 Billing Account。

例如，一家公司可以拥有：

生产 Project
开发 Project
数据分析 Project
AI 训练 Project

这些 Project 可以全部关联到同一个企业 Billing Account。

当然，企业也可以根据业务、财务或者治理需求使用多个 Billing Account。

Project 之间并不是绝对无法共享资源

原文还有一个需要修正的重要观点：不能简单地说“项目之间的资源无法直接共享”。

Google Cloud 中确实存在 Project 边界，但不同服务支持的资源共享方式不同。

例如，一些网络、IAM、存储、数据分析以及其他服务可以通过不同机制实现跨 Project 的访问或协作。

因此，更准确的说法是：

Project 是重要的资源和权限管理边界，但不是所有跨 Project 的资源访问都被禁止。

真正决定能否跨 Project 访问的是具体服务的资源模型、IAM 权限、组织策略以及相关配置。

这也是为什么企业设计 Project 架构时，不应该仅仅为了“隔离”而无限增加 Project。

配额也不能简单理解为组织统一分配

Google Cloud 中存在大量 Quota 和使用限制，但配额并不是简单地由 Organization 统一设置一个总数字，然后平均分给所有 Project。

不同服务的配额作用范围和管理方式可能不同，一些配额与 Project、区域、API 或具体服务有关。

因此，在部署大型计算任务时，需要根据具体服务查看相应的 quota 和 limit，而不能假定“组织设置一个总配额即可控制所有项目”。

Google Cloud Resource Manager 本身也有与 Project、Folder 等资源管理相关的限制。

第一次使用 Google Cloud，应该怎样理解这套体系

如果只是个人学习或者进行小型项目，实际上不需要一开始就设计复杂的企业架构。

最简单的理解方式是：

Google 账号 / 用户身份 → 负责证明你是谁

Organization → 企业资源体系的根节点，可选于个人场景

Folder → 用于组织多个 Project，可选

Project → 主要的资源、权限、API 和成本管理边界

Resource → 真正运行的云服务对象

Billing Account → 为一个或多个 Project 承担费用

其中，IAM 则贯穿整个体系，用于决定不同身份能够访问哪些资源。

因此，一个比较典型的企业环境可以表示为：

Google Workspace / Cloud Identity 身份

↓

Organization

↓

Folder

↓

Project

↓

Compute Engine / Cloud Storage / BigQuery / Pub/Sub 等资源

与此同时：

Cloud Billing Account → 关联一个或多个 Project

而 IAM 则可以在 Organization、Folder、Project 以及部分具体资源层级设置权限，并根据资源层级向下继承。

真正重要的是资源边界，而不是层级越复杂越好

Google Cloud 的资源层级设计，本质上是在解决三个问题：谁拥有资源、谁能够访问资源，以及资源应该如何被组织和管理。

Organization提供企业级治理边界，Folder提供可选的中间管理层，Project提供重要的资源和管理边界，而具体 Service Resources 才承担实际计算、存储、数据库和网络等工作。

对于个人用户或者小型项目，没有必要为了追求企业级架构而建立大量 Folder 和 Project。对于大型企业，则需要根据部门、环境、业务和安全边界合理规划 Project，并通过 Folder、IAM 和 Organization Policy 实现集中治理。

第一次接触 Google Cloud 时，最值得记住的并不是某一个服务的名称，而是这套基本关系：

身份决定“你是谁”，IAM决定“你能做什么”，Organization和Folder决定“资源如何组织”，Project决定“资源在哪个管理边界内”，Resource决定“实际运行什么”，Billing Account则决定“由谁承担费用”。

一旦理解了这几个概念，Google Cloud Console 中看似复杂的各种设置就会变得清晰得多。后续无论是部署虚拟机、建立 Kubernetes 集群、使用 BigQuery，还是运行大规模 AI 工作负载，本质上都可以回到这套资源层级、身份权限和计费体系中进行理解。