G-gen の杉村です。当記事では Google Cloud (旧称 GCP) の Virtual Private Cloud (VPC) について徹底解説します。今回は基本編に続く 応用編 の記事となります。

基本編へのリンク
VPC 間・サブネット間の通信
- 同一 VPC 内のサブネット間通信
- VPC 間の通信
VPC ネットワークピアリング
Cloud VPN による推移的な通信 (カスタムルート広報)
共有 VPC
サーバーレス VPC アクセス
限定公開の Google アクセス / Private Service Connect
- Google Cloud APIs へのプライベート接続
- サードパーティサービスへのアクセス
Packet Mirroring

基本編へのリンク

今回の記事は 応用編 です。以下については基本編で扱っていますので、ご参照ください。

Virtual Private Cloud (VPC) とは
ネットワークとサブネット
オンプレミスや他のクラウドとの接続
ルート
ファイアウォール
インターネットとのアクセス
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 hop 制限) という制約があります。これは後述します。

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

3つ目のパターンは、 IDS (Intrusion Detection System) やファイアウォール系の仮想アプライアンスを VM で構築するパターンでよく利用されます。 VPC 間通信の経路のネクストホップをその VM にすることで、 VPC 間で通信されるパケットを検査することができます。この方法は仮想アプライアンス VM の運用・管理が必要になるため、かなり高度なセキュリティが必要なときのみ用いられるべきです。詳細は公式ドキュメントをご参照ください。

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

blog.g-gen.co.jp

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

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

VPC ネットワークピアリング (あるいは単に VPC ピアリング) は、異なる VPC ネットワーク同士を接続できる機能です。

ピアリングで接続されたネットワーク同士は Internal IP (Private IP) アドレスで通信しあうことができます。

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

利点

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

低レイテンシ
VM に External IP を持たせる必要がないためよりセキュア
(同一リージョン・同一ゾーン同士であれば) VPC の Egress 料金が発生しない

制限

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 による推移的な通信 (カスタムルート広報)

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

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

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

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

設定内容は、以下のとおりです。

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

Google Cloud の共有 VPC とは

共有 VPC (Shared VPC) 機能を使うと、あるプロジェクトに置いた VPC を他のプロジェクトに共有することができます。

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

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

共有 VPC では一つの ホストプロジェクト を決めます。

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

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

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

共有 VPC 管理者

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

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

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

その他

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

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

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

サーバーレス VPC アクセス

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

サーバーレス VPC アクセス は Cloud Run 、 App Engine (Standard) 、 Cloud Functions などサーバーレスの実行環境から VPC 内のリソースにアクセスするための仕組みです。

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

Cloud Run などサーバーレスで実行されたプログラムから、例えば Compute Engine の VM にリクエストを投げようとすると、通常はインターネットから (Public IP) からの通信となってしまいます。 Cloud Run サービス等の作成時にコネクターを指定することで、 Private IP 宛のパケットはコネクター経由で VPC にルーティングされるようになります (Public IP 宛のパケットは引き続きインターネット経由で送信されます) 。

ユースケース

例として Cloud Run 、 App Engine (Standard) 、 Cloud Functions で実行するプログラムから、以下へのアクセスを行うとき等に利用を検討します。

Memorystore にデータを保存 / キャッシュする
Compute Engine の VM の API 等へアクセスする
オンプレミスのデータベースに Cloud VPN や Cloud Interconnect を経由してアクセスする

コネクター

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

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

またコネクター作成時に、コネクタインスタンスの min-instances と max-instances を指定して、スケールの最小値・最大値を指定します。ただし 2022 年 5 月現在の仕様として、インスタンス数の変動はスケールアウトのみとなっており、スケールインはされません。またコネクタ作成後は 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 アクセスの料金

コネクタインスタンスのマシンタイプとインスタンス数に応じて課金されます。

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

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

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

限定公開の Google アクセス と Private Service Connect は、 VPC 内の VM 等から Google Cloud の API へアクセスする際に、 Private IP のみでアクセスできるようにするための仕組みです。

Google Cloud の API はインターネットに口を開けていますので、通常は Public IP でアクセスすることになりますが、これらの機能を使うことで VM 等は Public IP を持つことなく、 Private IP のみで Google API にアクセスでき ます。

「限定公開の Google アクセス」と「 Private Service Connect 」はよく似た機能ですが、サービスとしては前者が先にできたものです。後者は前者の発展版であり、前者の機能を内部で利用しています。

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

blog.g-gen.co.jp

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

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

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

トラフィックは NAT されるため、IP アドレスの重複を気にする必要がありません。

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

当機能に関する詳細は公式ドキュメントや以下の記事を参考にしてください。

blog.g-gen.co.jp

Packet Mirroring

Packet Mirroring とは

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

ポイントは、当機能は 特定インスタンスに出入りするパケット をミラーできる機能である、という点です。 VM はインスタンスタイプごとにネットワーク帯域の上限が決まっていますが、 Packet Mirroring はこの帯域を消費します。

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

ユースケース

主にセキュリティ目的のモニタリング・分析が想定されています。

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

コレクタ宛先

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

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

この背後の 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 )

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