GCP のリソース階層を AWS と比較する（Organization / Folder / Project 編）
GCP を触り始めたとき、Organization・Folder・Project という階層が何のためにあるのか、そして AWS でいうと何に当たるのかが分かりにくかった。
この記事では、GCP のリソース階層を AWS と1対1で対応づけながら 整理する。結論から言うと、Organization → Folder → Project → リソース は AWS の Organization → OU → Account → リソース とほぼきれいに対応する。
全体像
GCP と AWS の階層は、次のように4段でほぼ1対1に対応する。Mermaid 版も載せておく。
対応表
| 観点 | GCP | AWS | 役割 |
|---|---|---|---|
| 最上位 | Organization | Organization | 全社の根。GCPはWorkspace/Cloud Identityのドメインに1つ紐づく。AWSは管理（マスター）アカウントが頂点 |
| グループ階層 | Folder | OU（Organizational Unit） | 部門・環境ごとの階層的な束ね。どちらも入れ子（ネスト）可能 |
| 分離・課金の境界 | Project | Account | ここが要。リソース・課金・API有効化・IAMの基本単位。GCPのProject ≒ AWSのAccount |
| 実体 | リソース（GCE, GCS, BigQuery…） | リソース（EC2, S3, Redshift…） | 実際に動くサービス群 |
それぞれの役割
Organization（組織）= AWS Organization
- 階層全体の 根（ルート）ノード。
- GCP では Google Workspace または Cloud Identity のドメイン（例:
example.com）に対して1つ自動的に作られる。 - ここに付けた IAM や組織ポリシーは、配下のすべての Folder / Project に継承される（＝全社共通のガバナンスをかける場所）。
- AWS では 管理アカウント（旧マスターアカウント） が頂点となり、組織全体を束ねる。
Folder（フォルダ）= AWS OU
- 部門・チーム・環境（本番/検証）ごとに Project をグループ化 するための中間階層。
-
入れ子（ネスト）可能。例：
Organization → Folder(事業部) → Folder(チーム) → Project。 - Folder 単位で IAM や組織ポリシーをまとめて適用できるので、「この部門配下の全 Project にこのルール」が実現しやすい。
- AWS の OU（Organizational Unit） と同じ役割。OU も入れ子にでき、SCP を OU 単位でかける。
Project（プロジェクト）= AWS Account ★最重要
- GCP で 最も重要な境界。以下すべての基本単位になる。
- 課金（Billing Account を紐づける）
- API の有効化（Project ごとに使うサービスを有効化）
- IAM（権限はこの単位で閉じて管理しやすい）
- リソースの所属（GCE インスタンスや GCS バケットは必ずどこかの Project に属する）
- AWS の Account に相当する。AWS でも課金・分離の基本単位は Account。
- 覚え方：「GCPのProject = AWSのAccount」。これを押さえると設計の事故が激減する。
リソース = リソース
- 実際に動くサービス群。GCE（仮想マシン）、GCS（オブジェクトストレージ）、BigQuery など。
- AWS の EC2 / S3 / Redshift などに対応。
押さえるべき差分（ここが記事の肝）
1. 「境界」を増やす感覚が違う
- AWS：分離したい単位ごとに Account を増やすのが定石（マルチアカウント戦略）。アカウント作成はやや重い操作という感覚。
- GCP：Project を量産する感覚。Project は気軽に作れ、課金・IAM・API の最小境界になる。
「GCPのProject = AWSのAccount」とマッピングすると、AWSのマルチアカウント設計の知識をそのままGCPのマルチプロジェクト設計に流用できる。
2. ポリシーの継承
- GCP は Organization / Folder / Project に IAM と 組織ポリシー（Organization Policy） を継承させる。
- AWS は OU / Account に SCP（Service Control Policy） をかける。
- どちらも「上位で許可の上限を絞り、下位は継承」という考え方は共通。
- （詳細は別記事「IAM とポリシー継承の仕組み」で扱う）
3. 課金の紐づき方
- GCP：Project に Billing Account を紐づける。Project と課金は別オブジェクトで、1つの Billing Account に複数 Project をぶら下げられる。
- AWS：Account 自体が課金単位。Organization の 一括請求（Consolidated Billing） で複数アカウントの請求を管理アカウントに集約する。
まとめ
| GCP | AWS | ひとことで |
|---|---|---|
| Organization | Organization | 全社の根 |
| Folder | OU | 階層的なグループ（入れ子可） |
| Project | Account | 課金・権限・APIの基本境界（最重要） |
| リソース | リソース | 実体 |
- 階層構造はほぼ1対1で対応する。
- 一番大事なのは 「GCPのProject ≒ AWSのAccount」。
- 「上位に付けたポリシーは下位に継承される」という思想も共通。
関連記事：[GCP と AWS で比較する IAM とポリシー継承の仕組み]