こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムを裏から支えている私ですが、クラウドのネットワーク設計、特にGCP（Google Cloud）の「VPC（仮想プライベートクラウド）」周りは、最初は覚えることが多くて圧倒されてしまいますよね。
「複数のプロジェクトで安全にネットワークを共有したい」
「でも、セキュリティの管理者は一元化したいし、開発チームは自由にサーバーを立てたい」
そんな現場の切実な悩みを鮮やかに解決してくれるのが、今回取り上げる「Shared VPC（共有VPC）」です。ホストプロジェクトとサービスプロジェクトという、ちょっと聞き慣れない役割分担の仕組みについて、パケットが飛び交う裏側のストーリーを交えながら、一歩ずつ一緒に紐解いていきましょう！
—
1. 共有VPCってなに？身近な例えでイメージしよう
いきなりGCPの難しい用語から入るのはやめましょう。まずは私たちの身の回りの世界に置き換えて考えてみます。
想像してみてください。あなたは大きなお城（ひとつの企業組織）の総務部長です。
お城の中には、「開発部」「経理部」「マーケティング部」といったたくさんの部署（サービスプロジェクト）があります。
もし、すべての部署が勝手に自分たちの城壁（ネットワーク）を築き、勝手に門（ファイアウォール）を作ったらどうなるでしょうか？
「あっちの門は鍵が空いている！」「泥棒が侵入しやすい死角がある！」と、セキュリティ担当者は頭を抱えてしまいますよね。
そこで、「セキュリティや道路の舗装（VPCネットワークやファイアウォール）は、専門家であるインフラチームが一括して管理する。ただし、道路の端っこに各部署の小さなお店（Compute Engineなどのリソース）を建ててもいいよ」という仕組みを作りました。
これが、GCPにおけるShared VPC（共有VPC）の考え方です。
- ホストプロジェクト: 道路や水道管（VPCやサブネット、ファイアウォール）を一括管理する、インフラ管理者のためのプロジェクト。
- サービスプロジェクト: その道路の恩恵を受けながら、実際にアプリを動かすサーバーやデータベースを置く、各開発チームのプロジェクト。
このモデルを導入することで、ネットワークの管理権限と、日々の開発作業の権限をきれいに切り分けることができるんです。
—
2. ホストプロジェクトとサービスプロジェクトの「権限委譲」の魔法
「ネットワークを共有するって言っても、勝手に他の部署のサーバーと通信できちゃったりして、セキュリティ的に危なくないの？」
そんな心配をした方、素晴らしい着眼点です！SREとしても、そこは一番気をつけるポイントです。
GCPの共有VPCでは、ホストプロジェクトの管理者が「どのサービスプロジェクトに、どの道路（サブネット）を使わせるか」を細かくコントロール（権限委譲）できるようになっています。
ここで重要なのが、GCPの権限管理システムであるIAM（Identity and Access Management）の仕組みです。
郵便配達員（パケット）に例えてみましょう。
サービスプロジェクトで作られたサーバー（A君としましょう）が、同じ共有VPC内の別のサーバー（B君）に手紙を送りたいとします。
1. A君は、ホストプロジェクト側であらかじめ許可されたサブネットの道路を使って手紙を出します。
2. このとき、A君には「ネットワーク管理者」ではなく、あくまで「この道路を使う権利（付与されたIAMロール）」だけが与えられています。
3. だから、A君が勝手に道路の幅を広げたり（新しいサブネットを作ったり）、検問所（ファイアウォール）を勝手に撤去したりすることは絶対にできません。
このように、「管理は一元化し、利用は安全に切り分ける」というのが、共有VPCの最大の魅力です。
—
3. 【実践】Terraformで構築する共有VPCの基本設計
理屈が分かったところで、実際のインフラ構築の現場でどのように設定するのか、コードを見てみましょう。ここでは、インフラ界の共通言語であるTerraformを使って、ホストプロジェクトとサービスプロジェクトを繋ぐ基本の設定を覗いてみます。
もちろん、実務でそのままコピー＆ペーストして使えるよう、丁寧に日本語のコメントを添えておきますね！
# ==========================================
# 1. ホストプロジェクト側の設定
# ==========================================
# ホストプロジェクト上でVPCネットワークを作成します
resource "google_compute_network" "shared_vpc_network" {
project = "my-host-project-123" # ホストプロジェクトのID
name = "prod-shared-vpc" # VPCネットワークの名前
auto_create_subnetworks = false # 自動サブネット作成はオフにし、手動で厳密に管理します
}
# サービスプロジェクトに開放するサブネットを作成します
resource "google_compute_subnetwork" "shared_subnet" {
project = "my-host-project-123"
name = "app-tier-subnet-tokyo"
ip_cidr_range = "10.100.0.0/24" # このサブネット内のIPアドレス空間
region = "asia-northeast1" # 東京リージョン
network = google_compute_network.shared_vpc_network.id
}
# このプロジェクトを「共有VPCのホスト」として有効化します
resource "google_compute_shared_vpc_host" "host" {
project = "my-host-project-123"
}
# ==========================================
# 2. サービスプロジェクトとの結合設定
# ==========================================
# サービスプロジェクトをホストプロジェクトに紐付けます
resource "google_compute_shared_vpc_service_project" "service1" {
host_project = google_compute_shared_vpc_host.host.project
service_project = "my-service-project-456" # 連携させたい開発チームのプロジェクトID
}
# ==========================================
# 3. 権限（IAM）の委譲設定
# ==========================================
# サービスプロジェクトのサービスアカウントに、サブネットを使う権利を与えます
resource "google_compute_subnetwork_iam_member" "subnet_user" {
project = "my-host-project-123"
region = google_compute_subnetwork.shared_subnet.region
subnetwork = google_compute_subnetwork.shared_subnet.name
# 「ネットワークユーザー」というロールを付与するのがポイントです
role = "roles/compute.networkUser"
# 例：サービスプロジェクトのデフォルトサービスアカウントを指定
member = "serviceAccount:my-service-project-456@appspot.gserviceaccount.com"
}コードのポイント解説
auto_create_subnetworks = false: これにより、意図しないIPアドレスの自動割り当てを防ぎ、IPアドレスの枯渇を防ぐ堅実な設計ができます。roles/compute.networkUser: サービスプロジェクト側のリソース（仮想マシンなど）が、ホスト側のサブネット上でIPアドレスを借りて通信するために絶対に必要な権限です。ここを忘れると、サーバーを立ててもネットワークに繋がらない！という現場あるあるのトラブルに直面するので要注意です。
—
4. 現場のSREが教える、設計時の落とし穴とアドバイス
最後に、私たちが実際の商用環境で共有VPCを設計・運用する中で得た、ちょっとしたリアルな知見（教訓）をいくつかシェアしておきますね。
1. IPアドレス（CIDR）の計画は慎重に！
共有VPCのサブネットは、複数のサービスプロジェクトから「相乗り」して使われます。後から「IPアドレスが足りなくなったから広げたい！」となると、ネットワークの再設計が必要になり大惨事になります。最初に十分な広さ（大きめのプレフィックス）を確保しておきましょう。
2. ファイアウォールルールの命名規則を統一する
ホストプロジェクトには、全サービスプロジェクト分のファイアウォールが集約されます。「どれがどのチームのためのルールか分からない…」とならないよう、allow-serviceA-to-db のように明確なプレフィックスをつけるルールをチーム内で徹底しましょう。
3. 権限管理の「誰が責任を持つか」を明確に
インフラチームがホストプロジェクトを守り、開発チームがサービスプロジェクトのアプリを守る。この境界線（責任分界点）が曖昧になると、セキュリティインシデントが発生した際に原因追跡が難しくなります。
—
まとめ
いかがでしたでしょうか？
「Shared VPC（共有VPC）」という言葉を聞くと、なんだか難しそうな要塞の図面を思い浮かべるかもしれませんが、本質は「安全な道路（ネットワーク）の管理をインフラ専門家に任せ、その上で各チームが自由にのびのびとお店（アプリ）を開くための優しい仕組み」です。
GCPのネットワーク基礎を学ぶ上で、このホストとサービスの概念を理解しておくと、今後のアーキテクチャ設計の見通しが劇的に良くなります。
一歩ずつ、確実に知識を血肉にして、自信を持ってクラウドインフラを使いこなしていきましょう！あなたのSREライフを応援しています。
コメント