Google CloudのVPCを徹底解説!(応用編)

記事タイトルとURLをコピーする

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

基本編へのリンク

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

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

blog.g-gen.co.jp

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

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

同一 VPC 内のサブネット間の通信のポイントは「同一 VPC 内のサブネット同士は通信できる。 リージョンが異なっても通信可能 」だという点です。

この柔軟性が Google Cloud の VPC の特徴です。別リージョンにサブネットを追加すれば、別のリージョンにも簡単に通信を通すことができます。

同一 VPC 内の VM 同士はリージョンが異なっても通信できる

VPC 間の通信

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

  • VPC ピアリングで接続する
  • Cloud VPN で接続する
  • VM (Compute Engine) を構築して 2 つのサブネットにそれぞれ NIC を作成する。 VM を仮想ルーターとして利用する

1 個目の VPC ピアリングでは、 推移的ピアリングができない (いわゆる 2 hop 制限) という制約があります。これは後述します。

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

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

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 型 (スター型とも呼ばれる) のネットワークトポロジを構成することが可能です。

Hub-VPC を中心としたネットワーク

このネットワークは 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 ネットワークに適用するリソースであるのに対し、ファイアウォールポリシーは 「組織」ノードもしくは「フォルダ」ノードに適用するリソースである という点が大きな違いです。

参考ですが、以下は Google Cloud の組織・フォルダ・プロジェクト構成の図です。 Google Cloud ではリソースは階層構造になっています。

Google Cloud のリソースツリー

この中で、ファイアウォール ポリシー は組織 (最上位ノード) やフォルダにアタッチするものです。一方でファイアウォール ルール はあるプロジェクトのある VPC ネットワークにアタッチするものだ、と理解すればよいでしょう。

評価順

ファイアウォールポリシーは上位のノード(組織・フォルダ)から、 下位のノードに向けて順番に 評価されていきます。また基本的なアクセス制御の仕組みはファイアウォールルールと同様ですが、ファイアウォールポリシーでは 許可拒否 に加えて goto_next というアクションが存在します。 goto_next アクションは、許可/拒否を決めずに下位のノードのファイアウォールに評価を委ねるアクションです。 文字だけでは理解が難しいため、以下の図に示します。

ファイアウォールポリシーの評価順

なお組織 / フォルダにアタッチされたファイアウォールポリシーで どのルールにも合致しなかったパケットは goto_next として次のノードに渡され ます。

ファイアウォールポリシーの料金

重要な点としてファイアウォールポリシーの利用は 有償です 。ポリシーの適用対象となる VM 1 台あたり $1 (2022 年 5 月現在。 VM 500 台以下の場合) が課金されるため、 VM 数を意識していないと想定以上の課金となるおそれがあります。

最新の料金は 料金ページ を参照してください。

サーバーレス 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-instancesmax-instances を指定して、スケールの最小値・最大値を指定します。ただし 2022 年 5 月現在の仕様として、インスタンス数の変動はスケールアウトのみとなっており、スケールインはされません。またコネクタ作成後は min-instancesmax-instances の値を変更することはできません。インスタンス数によって料金が異なるため、この仕様は改善が望まれるところです。なお min-instances の設定可能最小値は 2 、 max-instances の設定可能最大値は 10 です。

コネクタインスタンスは f1-microe2-microe2-standard-4 を選択します。左記の順番で 1 台あたりのスループットが高くなりますが料金も高くなります。

マシンタイプごとに 1 台あたり処理可能な帯域は以下のとおりです。

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

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

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

例として 2022 年 5 月現在の東京リージョンでマシンタイプを f1-micromin-instances2 としてスケールアウトが発生することなく 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

blog.g-gen.co.jp

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

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

この機能を利用して、ユーザーは自身の VPC 内にある VM 等でホストしたサービスを公開することができ、また利用者は Private Service Connect エンドポイントを介してこれに Private IP でアクセスすることができます。 AWS でいう AWS PrivateLink 機能に相当するものと言えます。

Private Service Connect エンドポイントが NAT してくれるので、 IP アドレスの重複を気にする必要がありません。

当機能に関する詳細は 公式ドキュメント をご参照ください。

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 )

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

杉村 勇馬 (記事一覧) (Facebook)

クラウドソリューション部 部長

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格11冠。

2022年6月現在、ハマっているものはピーナッツくんの新しいアルバム Walk Through the Stars 。