みなさん、こんにちは。
日々の開発やインフラ運用において、AWS（Amazon Web Services）に慣れ親しんでいるエンジニアは非常に多いと思います。しかし、ビジネスの要件やプロダクトの特性に応じて、Google Cloud（GCP）を採用、あるいはマルチクラウドとして併用するケースが急速に増えています。
その際に多くのエンジニアが最初に突き当たる壁が、「AWSのあの概念は、GCPだとどう表現するのか？」という、クラウド間の「お作法や思想の違い」です。
今回は、お渡しいただいた実務資料の組織設計思想をベースに、AWSエンジニアがスムーズにGCPのインフラ設計を理解できるよう、「組織・プロジェクトの階層構造」と、GCP最大の強みであるネットワーク機能「Shared VPC（共有VPC）」の本質を解説します。
1. 組織構造の対比：AWS Organizations vs GCP Resource Hierarchy
AWSで複数環境（開発・ステージング・本番など）や複数部門を安全に分離する際、AWS Organizations を使ってアカウントを分割し、OU（組織単位） でグループ化するのが標準的です。
GCPでも同様の「リソース階層（Resource Hierarchy）」という概念が存在しますが、そのマッピングは以下のようになります。
| レイヤー | AWSの概念 | Google Cloud（GCP）の概念 | 役割・特徴 |
|---|---|---|---|
| 最上位 | AWS Organizations | 組織 (Organization) | 企業やドメイン全体のルート。すべてのリソースの頂点。 |
| グループ | OU (Organizational Unit) | フォルダ (Folder) | 部門や環境（本番/開発）ごとにリソースを括る箱。ネスト可能。 |
| 境界線 | AWS アカウント (Account) | プロジェクト (Project) | 最大の思想の違い。 課金やAPI、リソースを隔離する基本単位。 |
【解説と補足】「プロジェクト」はAWSアカウントより気軽に作る
AWSエンジニアが最も誤解しやすいのが「プロジェクト」の粒度です。
AWSアカウントの作成は（Control Tower等で自動化されてきたとはいえ）依然としてある程度の重みがありますが、GCPのプロジェクトは「数クリック、またはコード1行で数秒で払い出せる」ほど軽量です。
そのため、GCPでは「1つの大きなシステムの中で、フロントエンド、バックエンド、データ分析基盤ごとにそれぞれプロジェクトを分ける」といった、より細粒度なリソース隔離を気軽に行うのがベストプラクティスとされています。
2. ネットワークの断絶を解消する「Shared VPC」の衝撃
プロジェクトを細かく分けると、1つの課題が浮上します。それは「プロジェクトを跨いだ社内通信（プライベート通信）をどう綺麗に繋ぐか」という問題です。
AWSであれば、アカウント間でVPC同士を繋ぐために VPC Peering を網の目のように張るか、Transit Gateway (TGW) を中央に配してルーティングを制御するのが一般的です。しかし、これらはルートテーブルの管理やCIDR（IP帯）の重複回避など、設計・運用の手札が多くなりがちです。
GCPはこの問題を、「Shared VPC（共有VPC）」という極めて強力な機能でエレガントに解決します。
【Shared VPCの構造イメージ】
🔗 ホストプロジェクト（中央のネットワーク管理領域）
└── 🌐 Shared VPC (10.0.0.0/16)
├── 🟢 サブネットA (10.0.1.0/24) ──► サービスプロジェクトA (開発チーム用)へ割り当て
└── 🔵 サブネットB (10.0.2.0/24) ──► サービスプロジェクトB (本番チーム用)へ割り当て
Shared VPCの仕組み
Shared VPCでは、インフラ・ネットワーク担当者が管理する「ホストプロジェクト」に巨大なVPC（共有VPC）を1つ作成します。
そして、そのVPC内に切った「サブネット（IP帯）」の利用権限だけを、開発チームが触る「サービスプロジェクト」に対して個別に払い出します。
これにより、開発チームは自分たちのプロジェクト内でVM（Compute Engine）やGKE（Kubernetes）を立ち上げる際、自動的に中央の共有ネットワークへ安全に参加させることができます。
3. Transit Gatewayとの違い：Shared VPCがもたらす3つのメリット
AWSのTransit Gatewayによるハブ＆スポーク構成と比較したとき、GCPのShared VPCには運用の手白を劇的に減らすメリットがあります。
- ルーティング（ルートテーブル）の管理が不要
AWSのTGWでは、新しくVPCを繋ぐたびにTGWアタッチメントを作成し、双方のルートテーブルにルートを書き込む必要があります。しかしShared VPCは「そもそも1つの同じVPCの別サブネットを覗いているだけ」であるため、プロジェクトを跨いだ通信であってもルート設定を一切変更することなく、最初からプライベートIPのままで通信可能です。 - IPアドレス（CIDR）バッティングの完全な防止
各開発チームに個別にVPCを作らせると、IP帯が被って将来的に相互接続できなくなる事故が起きます。Shared VPCでは、ホストプロジェクト側で一元的にサブネットを切り出すため、設計段階でIPの重複が物理的に発生しません。 - ガバナンスと自由度の両立（最小権限の原則）
ネットワークの根幹（ファイアウォールルール、Cloud NAT、インターコネクト等の外部接続）はホストプロジェクト側でインフラ組織が堅牢にロックできます。一方で、開発チームにはサービスプロジェクト内で「インスタンスを自由に立てる権限」だけを渡せるため、セキュリティの統制と開発の俊敏性を完璧に両立できます。
4. 初期設計における注意点とガードレール
実務でShared VPCを導入するにあたり、ネタ元資料の思想をさらに発展させた設計上の注意点を2点補足します。
- 環境（Production/Staging/Development）の境界線
「すべてのプロジェクトを1つのShared VPCに入れたほうが楽では？」と考えがちですが、本番環境と開発環境はShared VPC自体を完全に分ける（ホストプロジェクト自体を分ける）べきです。なぜなら、VPCが同じであれば、ファイアウォールルールの設定ミス一つで開発環境のテストエゴから本番環境のデータベースへ通信が通ってしまうリスクが排除できないからです。 - IAM（Identity and Access Management）の役割定義
ホストプロジェクト側のネットワーク管理責任者にはcompute.networkAdmin権限を、サービスプロジェクト側の開発者にはサブネットに対するcompute.networkUser権限を付与します。この役割分割をインフラのコード（Terraformなど）で初期設定時に強制することが、美しいGCP運用への第一歩となります。
まとめ：クラウドの個性を理解して美しいアーキテクチャを
AWSとGCPは、どちらも優れた先進的なパブリッククラウドですが、そのネットワークや組織に関する設計思想には明確な違いがあります。
- AWSは、自律性の高い複数のVPCを、Transit Gatewayなどの高度なルーティングインフラで「後からスマートに繋ぐ」のが得意です。
- GCPは、最初からリソースがグローバルかつフラットであることを前提としており、Shared VPCを使って「1つの大きなネットワーク空間をみんなで安全にシェアする」というアプローチを取ります。
この違いを理解しておくと、「AWSではこうやっていたから、GCPならShared VPCを使ってこう設計すれば綺麗に収まるな」という引き出しが増え、マルチクラウド環境でのアーキテクトとしての実力が一層強固になります。ぜひ、新規のシステム設計やGCP移行の際の参考にしてみてください。