G-gen の杉村です。当記事では Google Cloud（旧称 GCP）の Virtual Private Cloud（VPC）について徹底解説します。当記事は、VPC の基本的な仕様を解説した「基本編」に続く「応用編」です。

基本編へのリンク

当記事は VPC の細かい仕様を解説した「応用編」です。以下の基本的な仕様については基本編で扱っていますので、そちらの記事をご参照ください。

Virtual Private Cloud (VPC) とは
ネットワークとサブネット
オンプレミスや他のクラウドとの接続
ルート
ファイアウォール（Cloud NGFW）
インターネットとのアクセス
Google Cloud サービスへのプライベートサービスアクセス
VPC フローログ
ファイアウォールルールのログ
VPC ネットワークの監査ログ
料金

blog.g-gen.co.jp

VPC 間通信・サブネット間通信

同一 VPC 内のサブネット間通信

同一 VPC ネットワーク内のサブネット間の通信のポイントは、「同一 VPC ネットワーク内のサブネット同士は、互いに通信できる」「リージョンが異なっても通信可能」という点です。この柔軟性が Google Cloud の VPC の特徴です。

VPC 間の通信

異なる VPC ネットワーク同士を通信させるには、いくつか方法があります。

VPC ネットワークピアリングで接続する
Cloud VPN で接続する
VM（Compute Engine）を構築して、2つのサブネットにそれぞれ NIC を作成する。VM を仮想ルーターとして利用する
Network Connectivity Center の VPC スポーク機能を使う

1つ目の VPC ネットワークピアリングでは、推移的ピアリングができない（いわゆる2ホップ制限）という制約があります。これについては後述します。

2つ目の Cloud VPN では、カスタムルート広報により、推移的な VPC 間通信が可能です。こちらについても後述します。

3つ目のパターンは、IDS（Intrusion Detection System）やファイアウォール等の仮想アプライアンスを VM で構築するパターンでよく利用されます。VPC ネットワーク間通信の経路のネクストホップをその VM にすることで、VPC 間で通信されるパケットをインラインで検査することができます。この方法は仮想アプライアンス VM の運用・管理が必要になり、運用や設計の複雑化に繋がるため、かなり高度なセキュリティが必要なときのみ用いられるべきといえます。

参考 : 複数のネットワークインターフェース

4つ目の Network Connectivity Center という Google Cloud プロダクトの VPC スポーク機能は、3つ以上の VPC を接続したいときに有用です。n:n で VPC ネットワークピアリングを構成しなくても、容易にフルメッシュ接続が実現できます。詳細は以下の記事の「VPC 間接続 (VPC スポーク)」の項をご参照ください。

blog.g-gen.co.jp

VPC ネットワークピアリング

VPC ネットワークピアリングとは

VPC ネットワークピアリング（または単にピアリング）は、異なる VPC ネットワーク同士を接続できる機能です。

ピアリングで接続されたネットワーク同士は、Internal IP（Private IP）アドレスで相互に通信することができます。

また、異なるプロジェクトや異なる組織に所属する VPC ネットワーク同士でも接続することが可能です。VPC ネットワークピアリングの確立には、双方の VPC でお互いにコネクションを作成する必要があります。

参考 : VPC ネットワークピアリング

利点

異なる VPC に所属する Compute Engine VM 同士は、ピアリングを使わなくても External IP（Public IP）アドレスを使えば相互に通信できますが、External IP アドレスを使った通信に比べ、 VPC ピアリングでは以下の利点があります。

低レイテンシ
VM に External IP アドレスを持たせる必要がないためよりセキュア
同一リージョン、同一ゾーンの VM 同士の通信に限り、VPC の下り（Egress）料金が発生しない

VM 間通信時に発生するネットワーク料金については、以下の公式料金表をご参照ください。

参考 : Google Cloud 内の VM 間データ転送の料金

制限

VPC ネットワークピアリングには、以下のような制限があります。

推移的ピアリングはできない（いわゆる2ホップ制限。ある VPC をまたいでその先にいる VPC とは通信できない）
VPC ネットワークピアリングは1:1で作成する。3つ以上の VPC を接続するには、フルメッシュでピアリングコネクションを作成する必要がある
接続する VPC ネットワーク同士は CIDR が重複してはいけない

1つ目の推移的ピアリングの不可という制約は、以下の図のとおりです。A、B、C の3つの VPC ネットワークが、B を中央にして VPC ネットワークピアリングで接続されています。A と C は互いには繋がっていない状態です。このような状態では、A と C は通信することができません。

なお推移的な接続を実現させたい場合、Cloud VPN の利用を検討します。Cloud VPN であれば、カスタムルート の Import / Export により、推移的な接続が実現できます。これについては、後述します。

2つ目は、VPC ネットワークピアリングは1:1で接続を作る必要がありますので、3つ以上のネットワークを接続したい場合は、全てのネットワーク間でフルメッシュで接続を作成する必要があります。ある VPC ネットワークに作成できるピアリングコネクションの上限は25個です。

3つ目は、VPC ネットワークピアリングで接続される VPC は、CIDR（IP アドレス帯）が重複してはいけません。ピアリング接続された VPC ネットワーク同士は、サブネットへのルートが自動的に全て交換されるため、選択的にルートを交換させることもできません。IP アドレス帯が重複した VPC ネットワーク同士を接続することを試みると、接続の作成が失敗します。

Cloud VPN による推移的な通信（カスタムルート広報）

Cloud VPN を用いると、以下のような Hub-and-Spoke 型（スター型とも呼ばれる）のネットワークトポロジを構成することが可能です。

このネットワークは VPC (A) をハブとして、オンプレミスサイト、VPC (B)、VPC (C) と接続されています。VPC (A) とオンプレミスは、Cloud VPN（IPsec VPN）で接続されており、VPC 間は VPC ネットワークピアリングで接続されています。

このとき、Cloud Router や VPC ネットワークピアリングがデフォルト設定のままだと、オンプレミスから VPC (B) へといった、ハブ VPC を経由した通信はできず、直接接続されているネットワーク間のみでしか通信できません。

しかし、適切に設定すれば、図右下の表のように相互にネットワーク間通信が実現できます（ただし VPC (B) ⇔ VPC (C) 間の通信は実現できません。前述したとおり、推移的 VPC ピアリングとなっているからです）。

設定方法は、以下のとおりです。

Cloud Router にて、オンプレミスの対向ルーターに広報するルートを明示的に設定する
- デフォルトだと Cloud Router が紐づいている VPC (A) のサブネットの CIDR しか広報されない
- ピアリングで繋がっている VPC (B) と (C) のルートも追加で広報するよう、明示的に設定する
VPC (A) 側の2つのピアリング設定にて、カスタムルートをエクスポートするよう設定する
- これにより対向である VPC (B) および (C) にカスタムルート（オンプレから受け取った 10.0.0.0/8 のルート）が広報される
VPC (B) および (C) のピアリング設定にて、対向である VPC (A) からカスタムルートをインポートするよう設定する
- これにより対向である VPC (A) からカスタムルート（オンプレから受け取った 10.0.0.0/8 のルート）を受け取れる

1つ目の設定をしないと、オンプレミスルーターは VPC (B) と (C) への経路を知ることができません。Cloud Router はデフォルトだと、自分が紐付いている VPC のルートしか、対向ルーターへ広報しないためです。VPC (B) と (C) の経路を対向ルーターへ広報するよう、明示的に設定する必要があります。これをカスタムルート広報（またはカスタムアドバタイズ）といいます。

参考 : カスタムアドバタイズ

2つ目と3つ目の設定をしないと、VPC (B) と (C) はオンプレミスへの経路を知ることができません。カスタムルートのインポート・エクスポートの設定をすることで、VPC (A) がオンプレミスから受け取った 10.0.0.0/8 というルートを、VPC (B) と (C) に教えることができます。

なおここでいうカスタムルートとは、Google Cloud によって自動的に生成されるルート（デフォルトルートやサブネット間のルート）以外の動的 / 静的なルートを指しています。この図でいえば、オンプレミスから BGP で受け取った 10.0.0.0/8 へのルートがカスタムルートになります。

参考 : ルートのタイプ

上記のような一通りの設定を済ますと、VPC (A) をハブとした相互通信が可能になります。

共有 VPC

共有 VPC とは

共有 VPC（Shared VPC）機能を使うと、ある Google Cloud プロジェクトに配置した VPC ネットワークを、他のプロジェクトに共有することができます。

共有された側のプロジェクトでは、共有された VPC ネットワーク内に、VM 等のリソースを配置することができます。ルートやファイアウォールなどの設定は、共有元のプロジェクトでしか変更できないため、ネットワークセキュリティの管理を集約して一元化することができます。

なお API 名や IAM ロールなどにおいて、共有 VPC は xpn と表現されることがあります（roles/compute.xpnAdmin など）。

参考 : 共有 VPC

ホストプロジェクトとサービスプロジェクト

共有 VPC を設計する際は、1つのホストプロジェクトを決めます。

このホストプロジェクトが、共有 VPC の「親」となり、 VPC ネットワーク自体の設定、サブネットの追加・削除、セカンダリアドレスレンジの設定、ファイアウォールルールの設定などを行うことができます。

そして共有された VPC を利用する「子」プロジェクトがサービスプロジェクトです。サービスプロジェクトは、共有 VPC に対して Compute Engine の VM 等のリソースを配置して利用することができます。

なお、プロジェクトはホストプロジェクトであると同時にサービスプロジェクトになることはできません。

共有 VPC 管理者

共有 VPC 管理者（Shared VPC Admin）は、共有 VPC を管理する Google アカウントです。

共有 VPC 管理者が、ホストプロジェクトにしたいプロジェクトにおいて、ホストプロジェクトを有効化します。さらに、共有先のプロジェクトをサービスプロジェクトとして追加することができます。

共有を受けたサービスプロジェクト側は、その VPC ネットワークのサブネットに対して、VM 等を構築することができます。

その他

共有 VPC には、他にいくつかの重要な概念があります。

組織のポリシー（ホストプロジェクトになれるプロジェクトを制限可能）
IAM（ホスト側、サービス側）
コスト（Egress traffic cost はサービスプロジェクト側に課金）

詳細は、公式ドキュメントをご参照ください。

参考 : 共有 VPC

サーバーレス VPC アクセス

サーバーレス VPC アクセスとは

サーバーレス VPC アクセスとは、Cloud Run、App Engine（Standard）、Cloud Run functions などのサーバーレス実行環境から VPC ネットワーク内のリソースにアクセスするための仕組みです。

サーバーレス VPC アクセスを設定すると、VPC 内にコネクターが作成されます。コネクターは、VPC ネットワーク内の専用サブネットとコネクタインスタンスで構成されています。このコネクタインスタンスは Compute Engine のコンソールからは見えない、Google によって管理される VM です。

Cloud Run などのサーバーレス環境で実行されるプログラムから、VPC ネットワーク内の Compute Engine VM にリクエストを投げようとすると、通常はインターネット経由で、VM の Public IP アドレスへ通信することになります。Cloud Run services 等の作成時に接続先コネクターを指定することで、Private IP アドレス宛のパケットがコネクター経由で VPC ネットワークにルーティングされるようになります（Public IP アドレス宛てのパケットは、引き続きインターネット経由で送信されます）。

参考 : サーバーレス VPC アクセス

ユースケース

例として Cloud Run、App Engine（Standard）、Cloud Run functions で実行するプログラムから、以下のリソースへアクセスを行うとき等に、サーバーレス VPC アクセスの利用を検討します。

Memorystore にデータをキャッシュする
Compute Engine VM でホストされた Web API へアクセスする
オンプレミスのデータベースに Cloud VPN や Cloud Interconnect を経由してアクセスする

コネクター

前述の通りコネクターは、VPC ネットワーク内の専用サブネットとコネクタインスタンスを指します。

コネクターの作成時には /28 のプレフィクスで新しいサブネットを作成するか、作成済みで未使用の /28 のサブネットを指定します。

またコネクター作成時に、コネクタインスタンスの min-instances と max-instances を指定して、スケールの最小値・最大値を指定します。ただし2025年3月現在の仕様として、インスタンス数の変動はスケールアウトのみとなっており、スケールインはされません。またコネクタ作成後は min-instances と max-instances の値を変更することはできません。インスタンス数が多いと、その分の料金が発生します。なお min-instances の設定可能最小値は2、max-instances の設定可能最大値は10です。

コネクタインスタンスは f1-micro、e2-micro、e2-standard-4 から選択します。左記の順に1台あたりのスループットが高くなりますが、利用料金も高くなります。1台あたりで処理可能な帯域は、以下のとおりです。

マシンタイプ	1 台あたりの帯域
f1-micro	50 Mbps
e2-micro	100 Mbps
e2-standard-4	1,600 Mbps

サーバーレス VPC アクセスの料金

コネクタインスタンスのマシンタイプと、インスタンス数に応じて課金されます。料金単価は、Compute Engine VM の通常の料金表を参照します。

例として2025年3月現在の東京リージョンで、マシンタイプを f1-micro、min-instances を2として、スケールアウトが発生することなく1ヶ月間利用した場合、利用料金は $13.432/月です。

参考 : VM インスタンスの料金

Direct VPC Egress

サーバーレス VPC アクセスより後発の機能として、Cloud Run には Direct VPC Egress があります。Cloud Run で Direct VPC Egress を有効化すると、サーバーレス VPC アクセスコネクタを使用せずに VPC ネットワークにトラフィックを送信できるようになります。

Direct VPC Egress ではコネクタインスタンスの料金が発生しないことに加え、より低レイテンシーで通信することができます。制限に抵触しない場合は、Cloud Run ではまず、Direct VPC Egress の利用を検討します。詳細は以下を参照してください。

blog.g-gen.co.jp

限定公開の Google アクセス / Private Service Connect

Google Cloud APIs へのプライベート接続

限定公開の Google アクセスと Private Service Connect は、 VPC ネットワーク内の VM 等から Google Cloud の API へアクセスする際に、Private IP アドレスでアクセスするための仕組みです。

Google Cloud APIs はインターネットからの接続を受け付けますので、通常は Public IP アドレスでアクセスすることになりますが、限定公開の Google アクセスや Private Service Connect を使うことで、VM 等は Public IP アドレスを持つことなく、Private IP アドレスで Google Cloud APIs にアクセスできます。

限定公開の Google アクセスと Private Service Connect はよく似た機能ですが、後者のほうが後発であり、より充実した機能を持っています。

詳細はそれぞれ、以下の記事で紹介していますので、ご参照ください。

blog.g-gen.co.jp

サードパーティサービスへのアクセス

Private Service Connect にはもう1つの機能があります。それはサードパーティサービスへのプライベート接続です。

この機能により、Google Cloud ユーザーは、VPC ネットワークピアリングや Cloud VPN を使うことなく、自身の VM でホストしたサービスを他の Google Cloud ユーザーに公開することができます。公開されたサービスへは、Private Service Connect エンドポイントを介して、Private IP アドレスでアクセスすることができます。

トラフィックは NAT されるため、サービス利用者と IP アドレスが重複することを気にする必要がありません。

参考として、当機能は AWS でいう AWS PrivateLink に相当します。

当機能に関する詳細はは、以下の記事を参考にしてください。

blog.g-gen.co.jp

Packet Mirroring

Packet Mirroring とは

Packet Mirroring（パケットミラーリング）とは、指定のインスタンスに出入りするパケットをキャプチャ・複製し、別のインスタンスに対して送信する機能です。

当機能は、VPC ネットワークのある地点でパケットを監視するのではなく、特定インスタンスに出入りするパケットをミラーします。

また、VM はインスタンスタイプごとにネットワーク帯域の上限が決まっていますが、Packet Mirroring はこの帯域を消費します。

Packet Mirroring では、サブネット全体やネットワークタグを指定して、複数のインスタンスをまとめて対象にすることもできます。

参考 : Packet Mirroring

ユースケース

Packet Mirroring は、主にセキュリティ目的のモニタリングと分析で使用することが想定されています。

また場合によっては、パケットの詳細な解析が必要なネットワークのトラブルシューティングにも活用できます。

コレクタ宛先

Packet Mirroring は、指定インスタンスからパケットを複製して、コレクタ宛先（collector destination）に送信します。

コレクタ宛先は Internal TCP/UDP Load Balancer とその背後の VM（パケット分析用）で構成されます。宛先 VM はロードバランサーの背後にあるため、冗長化したり、マネージドインスタンスグループによる Autoscaling を利用することができます。

コレクタ宛先となる VM にパケットを解析する仕組みを配置することで、リアルタイムにパケットを分析することができます。

フィルタリング

Packet Mirroring は、すべてのパケットをキャプチャすることもできますが、以下の軸でフィルタすることもできます。

プロトコル
IP アドレス範囲（CIDR）
トラフィックの方向 ... 上り（Ingress）のみ / 下り（Egress）のみ / 両方

このフィルタは、パケットミラーリングポリシーで設定します。パケットミラーリングポリシーは複数設定でき、優先度は一定のルールに基づいて判断されます。

プロトコルが重複 → 最も狭い IP アドレス範囲のルールが優先（10.240.1.0/24:ALL > 10.240.0.0/16:TCP）
IP アドレス範囲が完全に一致 → 最も特定されているプロトコルが優先（10.240.1.0/24:TCP > 10.240.1.0/24:ALL）

これにより、あるインスタンスのパケットが複数のポリシーに一致してしまったときにどのポリシーが適用されるかが決定され、パケットがミラーされるか無視されるかが決まります。

アーキテクチャのベストプラクティス

以下の公式ドキュメントには、VPC 設計におけるベストプラクティスや、リファレンスアーキテクチャが掲載されています。

参考 : VPC 設計のためのおすすめの方法とリファレンスアーキテクチャ