💬

Google Cloud のネットワーク技術を基礎知識から振り返ってみる

に公開
Network
Google Cloud
VPC
アドベントカレンダー
tech

こんにちは、クラウドエース 第一開発部の阿部です。
この記事は JP_Google Developer Experts Advent Calendar 2025 の 9 日目の記事です。

はじめに

去年の Google Cloud Next '24 で AI エージェントという概念が発表されて以来、Gemini をはじめとして、生成 AI 関連の技術が世間の注目を集めてきていると強く感じています。
ただ、様々な生成 AI の技術が登場している中で、私が案件に携わる際に改めて重要だと感じているのが、Google Cloud のネットワーク技術の基礎です。
AI エージェントを PoC で利用する場合は、ネットワーク層をあまり気にせずに進められることも多いですが、本格的に既存システムとの連携を考慮したり、本番環境のデータアクセスを設計する場合には、生成 AI が動作するアプリケーション層だけでなく、その下にあるネットワーク層の設計も重要になるためです。

そこで、この記事では Google Cloud のネットワーク技術の基礎について振り返ってみたいと思います。

Google Cloud のネットワークの基礎知識

Google Cloud のネットワークは、Andromeda と呼ばれるグローバルに分散された高性能なソフトウェア定義ネットワーク (SDN) を基盤としています。
いわゆる VPC (Virtual Private Cloud) と呼ばれる仮想ネットワークを作成し、サブネットなどのリソースを構成していきます。(以降、VPC ネットワークと表記します。)

VPC (Virtual Private Cloud) と構成するリソース

Google Cloud の VPC ネットワークは AWS や Azure とは異なり、グローバルリソース(全リージョン)として設計されています。
また、VPC ネットワークには IP アドレス範囲を定義できません。
リージョンや IP アドレス範囲は、 VPC ネットワーク内に作成するサブネットが持つ形となります。

VPC ネットワーク

VPC ネットワークは、Google Cloud 上で仮想ネットワークを作成するためのリソースです。
VPC ネットワークでは、主に「サブネット作成モード」「動的ルーティングモード」「最大転送単位(MTU)」を設定します。

サブネット作成モード

サブネット作成モードでは自動モードとカスタムモードの 2 種類を設定します。
自動モードでは、VPC ネットワーク作成時に各リージョンに自動的にサブネットが作成されます。
カスタムモードでは、利用者自身が必要なリージョンにサブネットを作成します。
default ネットワークは自動モードで作成されています。

動的ルーティングモード

動的ルーティングモードは、Cloud Router を利用する際のルーティング情報の伝播方法を設定します。
グローバルモードとリージョンモードの 2 種類があり、デフォルトはリージョンモードです。
この設定は Cloud Router を利用するネットワーク間接続を行う場合にのみ影響します。

最大転送単位(MTU)

最大転送単位(MTU) は、VPC ネットワーク内で転送可能な最大パケットサイズを設定します。
デフォルトは 1460 バイトです。必要に応じて 1500、8500、8896 バイトに変更可能です。
これも通常は変更不要ですが、ハイブリッド接続でオンプレミス側の MTU と合わせる必要がある場合などに変更します。
また、特定の高性能アプリケーションで MTU を大きくすることでパフォーマンスが向上する場合があります。

作成時のおすすめ設定

通常の構築では、VPC ネットワークのサブネット作成モード以外は変更しないことが多いです。
サブネット作成モードは必ず「カスタムモード」を選択し、サブネットは自分で作成することをおすすめします。

VPC サブネット

VPC サブネットは、VPC ネットワーク内に作成されるリージョン単位のリソースです。
サブネットには主に IP アドレス範囲 (CIDR ブロック) を定義します。
IP アドレス範囲にはプライマリ CIDR ブロックとセカンダリ CIDR ブロックを定義できます。

それ以外に、サブネットには以下のような設定があります。

  • サブネットの目的 (Purpose)
  • IP スタックタイプ (IPv4、IPv6、デュアルスタックを選択)
  • プライベート Google アクセス
  • フローログ
  • ハイブリッドサブネット

IP アドレス範囲 (CIDR ブロック)

IP アドレス範囲 (CIDR ブロック) は、サブネット内で利用する IP アドレスの範囲を指定します。
通常はプライマリ IP アドレス範囲のみを指定しますが、Google Kubernetes Engine (GKE) の VPC ネイティブ クラスタを利用する場合などはセカンダリ IP アドレス範囲も指定します。
IP アドレス範囲は拡大する場合のみ後から変更可能で、縮小や全く異なる範囲への変更はできません。

サブネットの IP アドレス範囲は、定義した場合に予約されるアドレスを考慮して設計する必要があります。
予約されるアドレスは以下の通りです。

  • 最初のホストアドレス (ネットワークアドレス)
  • 最初のホストアドレス +1 (デフォルトゲートウェイ)
  • 最後から 2 番目のアドレス (予約済みアドレス)
  • ブロードキャストアドレス

サブネットの目的 (Purpose)

VPC サブネットは、Compute Engine 等のコンピューティングリソースを配置するための一般的なサブネット以外に、特定の目的で利用するためのサブネットも作成可能です。

  • ロードバランサのプロキシ用サブネット
  • Private Service Connect 用サブネット
  • プライベート NAT 用サブネット
  • ピア移行用サブネット

これらサブネットの目的は作成時のみ指定可能で、後から変更できません。
詳細な説明は割愛しますが、特定のネットワーク機能を利用する場合に必要になることがあります。

IP スタックタイプ

IP スタックタイプは、サブネットで利用する IP (Internet Protocol) のバージョンを設定します。
IPv4、IPv6、デュアルスタック (IPv4 + IPv6) の 3 種類から選択可能です。
通常は IPv4 を選択しますが、IPv6 対応が必要な場合は IPv6 またはデュアルスタックを選択します。
IPv6 アドレスのみを選択する場合は、そのサブネット上で利用するリソースも IPv6 のみで通信できるように設計する必要があります。

プライベート Google アクセス

プライベート Google アクセスは、VPC サブネット内のリソースがパブリック IP アドレスを持っていなくても Google Cloud のサービスにアクセスできるようにする機能です。
Google Cloud のサービスとは、 Cloud Storage、BigQuery といった *.googleapis.com のエンドポイントを持つマネージドサービスを指します。
また、Google API でアクセス可能なサービス(Google Workspace API など)も含まれます。
通常は有効にしてよいですが、セキュリティ上不用意に Google のサービスにアクセスさせたくないケースでは無効にします。

フローログ

フローログは、VPC サブネット内のリソース間の通信ログを収集する機能です。
フローログを有効にすると、VPC のサブネットを通過するトラフィックの情報が Cloud Logging に記録されます。
フローログの情報には、送信元と宛先の IP アドレス、ポート番号、プロトコルの情報などが含まれます。
また、メタデータ情報として、VPC ネットワーク名、サブネット名、インスタンス ID なども含まれます。

なお、以前はフローログを設定する際にサブネット毎にオプション設定する必要がありましたが、現在は Network Management API を利用して、組織全体やプロジェクト全体でフローログの設定を一括管理できるようになっています。
サブネット毎の設定は今後 Network Management API に統合されていく予定です。
よって、フローログを有効にする場合は、サブネットで設定せず、Network Management API で設定することをおすすめします。

ハイブリッドサブネット

ハイブリッドサブネットは、オンプレミス環境と Google Cloud をシームレスに接続するためのサブネットです。
これは Proxy ARP を利用して、オンプレミス環境の IP アドレス範囲と Google Cloud 環境の IP アドレス範囲を共有することで実現しています。
通常は使用しませんが、オンプレミス環境から Google Cloud へサーバを移行する際などに一時的に利用されることがあります。

作成時のおすすめ設定

サブネットの設定は、利用するユースケースに応じて異なりますが、以下のような点に注意するとよいでしょう。

  • サブネットの目的は、通常のコンピューティングリソース用では「なし」を選択
  • IP スタックタイプは、通常は「IPv4」を選択 (IPv6 対応が必要な場合は「デュアルスタック」をおすすめ)
  • プライベート Google アクセスは特に理由がなければ「有効化」を選択 (セキュリティ要件に応じて判断)
  • フローログは Network Management API で一括管理することを検討 (サブネット毎の設定は非推奨)

ファイアウォールポリシー (Cloud NGFW)

VPC ネットワーク内のトラフィックの許可・拒否を制御するためのリソースです。
従来は VPC ファイアウォールルールを使用していましたが、現在はファイアウォールポリシー (Cloud NGFW) が推奨されています。(参考)

ファイアウォールポリシーは VPC ファイアウォールルールと比較して、以下のような利点があります。

  • 一元的な管理: 複数の VPC ネットワークや、組織全体のネットワークに対して一元的にポリシーを適用可能
  • 柔軟なルール: IP アドレスベースのルールに加えて、位置情報や FQDN ベースのルールも設定可能 (Standard tier 以上)
  • 高度なセキュリティ機能: 侵入検知および防止(IPS) や TLS インスペクションなどの高度なセキュリティ機能を利用可能 (Premium tier のみ)

ただし、 Standard tier や Premium tier の機能を利用する場合は追加料金が発生するため、コスト面も考慮して選択する必要があります。
ファイアウォールポリシーについては、詳細に説明しようと思うと非常に長くなってしまうため、ここでは概要の説明にとどめます。

ルート

Google Cloud の VPC ネットワーク内でトラフィックの経路を制御するためのリソースです。
ルートは Google Cloud では案外忘れられがちなリソースです。というのは、 VPC ネットワークを作成するとデフォルトでいくつかのルートが自動的に作成されるためです。
自動的に作成されるルートは以下の通りです。

  • VPC サブネットルート: 各サブネットの IP アドレス範囲へのルート
  • デフォルトインターネットゲートウェイルート: VPC サブネットから 0.0.0.0/0 へのルート

このうち、 VPC サブネットルートは削除できず、VPC 上で常に有効です。
デフォルトインターネットゲートウェイルートは削除可能で、必要に応じてカスタムルートに置き換えることができます。

また、上記以外に以下のようなルートが存在します。

  • 静的ルート: 利用者が手動で作成するルート
  • 動的ルート: Cloud Router を利用して自動的に学習されるルート
  • ピアリングサブネットルート: VPC ピアリング接続を通じて学習されるルート
  • NCC ルート: Network Connectivity Center の VPC スポークを通じて学習されるルート

利用者が任意で設定出来るのは静的ルートのみで、その他のルートは特定のネットワーク接続を利用する場合に自動的に追加されます。
また、静的ルートは VPC サブネットルート、ピアリングサブネットルート、NCC ルートと重複するように設定することはできません。

他のクラウドプロバイダの VPC と比較して、Google Cloud の VPC のルートはシステムが自動的に管理する部分が多いため、利用者が手動で設定するケースは少ないです。
一方で、システムが自動的に管理するルートの挙動を理解しておかないと、何かルートの問題が発生した際に原因の特定が難しくなるため、注意が必要です。

Cloud NAT

Cloud NAT は、VPC ネットワーク内のプライベート IP アドレスを持つリソースがインターネットにアクセスするためのマネージド型 NAT サービスです。
Cloud NAT は Cloud Router とともに作成する必要がありますが、ここでは Cloud NAT に焦点を当てて説明します。

Cloud NAT は以下のような特徴があります。

  • フルマネージド: VPC のルート設定やスケーリングを自動的に管理
  • 高可用性: VPC に特定のインスタンスが配置されるわけではなく、VPC ネットワーク(Andromeda) によって提供されるため、高可用性を実現
  • リージョン単位の設定: Cloud NAT はリージョン単位で設定され、同じリージョン内の複数のサブネットにまたがって利用可能
  • IP アドレスの柔軟な割り当て: 静的 IP アドレスまたはエフェメラル IP アドレスを利用可能。静的 IP アドレスは単一または複数割り当て可能

Cloud NAT は、VPC ネットワーク内のリソースがインターネットにアクセスする際に、パブリック IP アドレスを持たない場合に特に有用です。
デフォルト設定でも十分に機能しますが、必要に応じて以下のような設定も可能です。

  • ソースエンドポイントのタイプ
  • ソース IP バージョン
  • ソースのサブネット
  • 高度な設定

ソースエンドポイントのタイプ

ソースエンドポイントのタイプは、「VM インスタンス、GKE ノード、サーバーレス」と「マネージドプロキシロードバランサ」の 2 種類から選択可能です。
通常は「VM インスタンス、GKE ノード、サーバーレス」を選択します。
「マネージドプロキシロードバランサ」は、リージョンロードバランサのバックエンドサービスにインターネット NEG を利用する場合に選択します。

ソース IP バージョン

ソース IP バージョンは、NAT 変換に使用する IP アドレスのバージョンを指定します。
既に存在するサブネットの IP バージョンに合わせて選択します。
Cloud NAT では、IPv4、IPv6 いずれの内部 IP アドレスであっても、インターネットアクセス時にはパブリック IPv4 アドレスに変換されます。
IPv4 アドレスを IPv6 アドレスに直接変換する機能はありません。

ソースのサブネット

Cloud NAT では、全てのサブネットを対象にするか、特定のサブネットのみを対象にするかを選択できます。
また、サブネット毎にプライマリ範囲のみにするか、セカンダリ範囲も含めるかを選択できます。
Cloud NAT を利用する目的にもよるのですが、VPC ネットワーク上の全てのリソースを対象にする場合は、「すべてのサブネットのプライマリとセカンダリの範囲」を選択します。
「すべてのサブネットのプライマリとセカンダリの範囲」を選択しておくと、後からサブネットを追加した場合でも自動的に Cloud NAT の対象になります。

高度な設定

高度な設定では、Cloud NAT のロギング設定、動的ポートの割り当て方法、および、接続のタイムアウト設定などを行います。

Cloud NAT のロギング設定は変換されたトラフィックのログや、エラーログを Cloud Logging に出力するための設定です。
NAT 動作のトラブルシューティングに役立ちます。

動的ポートの割り当て方法と接続のタイムアウト設定は、Cloud NAT の動作、および、一般的な NAT の概念を理解している場合を除き、通常はデフォルト設定のままで問題ありません。

VPC ネットワークの設計のポイント

ここまでに説明した VPC ネットワークとその構成要素は以下のようにまとめられます。

VPC ネットワークの構成要素

単一の VPC ネットワークで構成する場合はこれらの要素を組み合わせて設計すれば十分です。

サーバレスサービスから VPC ネットワークへの接続

サーバレスサービスから VPC ネットワークへの接続方法ついても触れておきたいと思います。

サーバレスサービスの紹介

まず、サーバレスサービスとは何かについて簡単に説明します。
サーバレスサービスは、インフラストラクチャの管理を気にせずにアプリケーションを開発・デプロイできるサービスです。
サーバレスサービスに該当する製品は Google Cloud serverless として Google Cloud のドキュメントで紹介されています。
これらサーバレスサービスのネットワーク視点における利点はネットワークの管理が不要なことであり、欠点は既存のネットワーク構成と連携させるには追加の設定が必要になることです。

この記事では、Google Cloud におけるサーバレスサービスとして以下の 3 つをとりあげます。

  • App Engine
  • Cloud Run
  • Cloud Run functions (旧 Cloud Functions)

デフォルトでは上記のサービスは VPC ネットワークと分離された環境で動作しますが、VPC ネットワークと接続するためのオプションを提供しています。

Serverless VPC Access

サーバレスサービスを VPC ネットワークに接続するためのオプションの 1 つとして、Serverless VPC Access があります。
これは、VPC サブネットに対して Serverless VPC Access コネクタリソースを作成し、コネクタがサブネットの IP アドレス範囲から IP アドレスを使用することで、サーバレスサービスが VPC ネットワーク内のリソースにアクセスできるようにする仕組みです。
Serverless VPC Access は内部的に NAT 用インスタンスを使用しているため、通信の有無にかかわらず NAT 用インスタンスのコストが発生します。
また、Serverless VPC Access の内部 NAT インスタンスはトラフィックに比例してスケールする仕組みですが、スケールアップした後、自動的にスケールダウンする仕組みがありません。
スケールダウンさせるためには一度コネクタを削除して再作成する必要があります。

Direct VPC egress

サーバレスサービスを VPC ネットワークに直接接続するための 2 つめのオプションとして、Direct VPC egress があります。
Serverless VPC Access と異なり、NAT 用インスタンスを使用せずに、VPC サブネットの IP アドレスをサーバレスサービスの内部インスタンスと 1:1 対応させて VPC ネットワークへのアウトバウンドトラフィックを直接ルーティングします。
Serverless VPC Access と比較して、Direct VPC egress はコスト効率が高く、レイテンシも低いです。
一方、Direct VPC egress は内部 IP アドレスを 1:1 で対応させるため、サブネットの IP アドレス範囲のサイズによってスケーラビリティが制限される可能性があります。

Serverless VPC Access と Direct VPC egress の比較

公式ドキュメントでは、 Direct VPC egress が推奨されています。
ドキュメントに比較表が掲載されているため、ここでは簡単にまとめます。

Serverless VPC Access と Direct VPC egress の比較

  • ほとんどのユースケースでは Direct VPC egress を推奨
  • 以下のケースでは Serverless VPC Access を使用することを検討
    • VPC ネットワークの IP アドレス範囲の利用効率を最大化したい場合 (IP アドレスの消費を最小限にしたい場合)
    • コストよりもサーバレスサービスのスケーリング効率を優先したい場合 (Direct VPC egress は最大インスタンス数がサブネットのサイズに依存します。また、スケールする際の起動時間が Serverless VPC Access よりも長い傾向があります。)

AI エージェントが、VPC ネットワークを経由してオンプレミス環境のリソースにアクセスするようなユースケースでは、Direct VPC egress を利用するといった選択肢が考えられます。

Vertex AI Agent Engine のネットワーク接続

AI エージェントの実行基盤としては、ADK から直接呼び出せる Vertex AI Agent Engine も選択肢に上がると思います。
しかし、現状 Vertex AI Agent Engine では VPC ネットワークと直接連携するオプションは提供されていません。
そのため、AI エージェントアプリケーションを直接オンプレミス環境のリソースと通信させたい場合は、Cloud Run の利用を検討する必要があります。

VPC ネットワークの接続オプション

ここまでで、VPC ネットワークの基本的な構成要素と、サーバレスサービスから VPC ネットワークへの接続方法について説明しました。
最後に、VPC ネットワーク同士やオンプレミス環境との接続オプションについて紹介します。

VPC ネットワーク接続の主要なオプション

主要な VPC ネットワークの接続オプションとしては、以下の 3 つがあります。

  • VPC ピアリング
  • 共有 VPC
  • Network Connectivity Center (NCC)

VPC ピアリング

VPC ピアリングは、異なる VPC ネットワーク同士を直接接続するためのオプションです。
VPC ピアリングを利用すると、VPC ネットワーク間で VPC サブネットの IP アドレス範囲がピアリングルートとして自動的に学習され、相互に通信できるようになります。
VPC ピアリングはシンプルで設定も容易なため、小規模なシステム同士の内部通信接続に適しています。

ただし、VPC ピアリングは以下のような制約があります。

  • 推移的ルーティングを提供していない: 直接ピアリングされている VPC ネットワーク間でのみ通信可能であり、間接的に接続された VPC ネットワークは通信できません。
  • 異なる VPC で重複する IP アドレス範囲を使用できない: A のサブネットで既に使用されている IP アドレス範囲は、 B のサブネットで使用できません。これはアドレス範囲の一部であっても同様です。

上記 2 つの制約は、特に大規模なシステム同士の接続や、複雑なネットワーク構成を管理する場合に問題になることがあります。

VPC ピアリングの概要

共有 VPC

共有 VPC は、複数のプロジェクト間で単一の VPC ネットワークを共有するためのオプションです。
共有 VPC では、ホストプロジェクトに VPC ネットワークを作成し、サービスプロジェクトからその VPC ネットワークを利用できるようにします。
これにより、ネットワーク管理の一元化や、リソース間の通信の簡素化が可能になります。

共有 VPC の概要

Network Connectivity Center (NCC)

Network Connectivity Center (NCC) は、比較的最近登場した VPC ネットワーク接続のオプションです。
NCC は、ハブアンドスポークモデルを採用しており、NCC ハブを中心にスポークリソースを接続することで、複数の VPC ネットワークやハイブリッド接続を管理します。

NCC で異なる VPC ネットワークを接続する場合は、各 VPC ネットワークに VPC スポークを作成して接続し、VPC スポークを NCC ハブに接続します。
NCC VPC スポークは、VPC ピアリングに似た機能を提供しますが、NCC VPC スポークの利点として以下が挙げられます。

  • ハブアンドスポークモデルのため、推移的ルーティングを考慮せずに複数の VPC ネットワークを接続可能
  • VPC スポークにルートエクスポートフィルターを設定できるため、VPC サブネットの IP アドレス範囲の制御が柔軟に設定可能

ただし、NCC は VPC ピアリングとは異なり、追加のコストが発生するため、コスト面も考慮して選択する必要があります。

NCC の概要

Google Cloud 外のネットワークとの接続オプション

最後に、Google Cloud 外のネットワークとの接続オプションについて簡単に触れておきます。

Cloud VPN

Cloud VPN は、IPsec VPN を使用して Google Cloud の VPC ネットワークとオンプレミス環境や他のクラウドプロバイダのネットワークをインターネット経由で接続するサービスです。
インターネット接続でき、IPsec VPN をサポートするルーターがあれば、概ねどの環境とも接続可能です。

Classic VPN と HA VPN の 2 種類が提供されています。
しかし、Classic VPN は段階的に廃止されており、現在は静的ルート設定の VPN 接続のみをサポートしています。
これから新規に VPN 接続を構築する場合は、HA VPN を利用することをおすすめします。

Cloud Interconnect

Cloud Interconnect は、Google Cloud の VPC ネットワークとオンプレミス環境や他のクラウドプロバイダのネットワークを専用線で接続するサービスです。
インターネットを経由しないため、高帯域幅、低レイテンシ、安定した接続が可能です。

Cloud Interconnect には、Dedicated Interconnect と Partner Interconnect 、そして Cross-Cloud Interconnect の 3 種類があります。
(Cross-site Interconnect もありますが、こちらはオンプレミス環境間の接続で使用する Interconnect のため、ここでは割愛します。)

Dedicated Interconnect と Partner Interconnect は、Google Cloud の VPC ネットワークとオンプレミス環境を接続するための専用線接続です。
違いとして、Dedicated Interconnect はコロケーション施設と Google Cloud を直接接続するため、比較的高帯域幅の接続が可能です。
一方、Partner Interconnect は Google Cloud のパートナー事業者を介して接続するため、より柔軟な帯域幅の選択肢があり、Dedicated Interconnect よりも安価に利用できます。

Cross-Cloud Interconnect は、Google Cloud と他のクラウドプロバイダ (AWS、Azure など) のネットワークを専用線で接続するためのサービスです。
Cross-Cloud Interconnect の登場以前は、パブリッククラウド間の専用線接続はサードパーティのネットワークプロバイダを経由して実現するしかありませんでしたが、Cross-Cloud Interconnect により Google Cloud と他のクラウドプロバイダ間で直接専用線接続が可能になりました。

Google Cloud 外のネットワークとの接続オプションのまとめ

  • Cloud VPN は低コストで比較的容易に接続可能。ただし、帯域幅やレイテンシはインターネットの影響を受ける。
  • Cloud Interconnect は高帯域幅、低レイテンシ、安定した接続が可能。ただし、コストが高く、導入に時間がかかる場合がある。

複雑なネットワーク構成の管理戦略

さて、この記事も書いていて長くなってきました。
最後に、複雑なネットワーク構成を管理するための戦略について簡単に触れておきます。

マルチリージョンシステムを構築する場合のポイント

他のクラウドプロバイダでは、 1 つの VPC が 1 つのリージョンに紐付く設計になっているため、マルチリージョンシステムを構築する場合はリージョン毎に VPC を作成し、VPC ピアリングなどで接続する必要があります。
一方、Google Cloud では VPC ネットワークはグローバルリソースであるため、1 つの VPC ネットワーク内に複数リージョンのサブネットを作成して管理できます。
そのため、マルチリージョンシステムを構築する場合でも、単一の VPC ネットワークで管理できるケースが多いです。
また、ロードバランサもグローバルロードバランサを利用することで比較的容易にマルチリージョンシステムを構築できます。
よって、地理的な要因でネットワーク管理が複雑になるケースは案外少ないと思います。

複数プロジェクト間でネットワークを管理する場合のポイント

Google Cloud でシステム設計をする場合、 Resource Manager の機能を活用して、システムを環境毎の Google Cloud プロジェクトに分割して管理することが一般的です。
また、1 つの環境でも、システムの役割毎にプロジェクトを分割する設計になることもあります。
このように複数プロジェクト間でネットワークを管理する場合は、VPC ネットワーク接続のオプションを適切に選択する必要があります。

  • システム間を疎結合に保つことで、VPC ネットワーク接続を最小限に抑える (サーバレスサービスをフル活用する場合)
  • 共有 VPC を活用して、ネットワーク管理を一元化する (ファイアウォールポリシーの一元管理や、セキュリティアプライアンスの集中配置など)
  • NCC を活用して、複数の VPC ネットワークを効率的に接続・管理する (大規模システムや複雑なネットワーク構成の場合)

上記のポイントを考慮して設計するとよいでしょう。
スモールスタートで設計する場合は、ネットワークの拡張性をあまり考慮せずに設計しがちですが、後からネットワーク構成を変更するのは大変です。
(特に、VPC ピアリングや既に Cloud Interconnect を導入している設計から、NCC ありの設計に変更するのはものすごい労力が必要だと思います。)
特に、Cloud Interconnect を利用する予定があり、複数の VPC で共有して利用する予定がある場合は、将来の拡張性を考慮して NCC を活用して設計することをおすすめします。

公式ドキュメントに、VPC ピアリングや Cloud Interconnect を利用している構成から NCC に移行するためのガイドが掲載されています。

まとめ

この記事では、Google Cloud の VPC ネットワークの基本的な構成要素から、サーバレスサービスの接続方法、VPC ネットワーク間の接続のオプション等について説明しました。
Google Cloud の VPC ネットワークはシンプルなリソースで構成されていながら、柔軟なネットワーク設計が可能です。
しかし、やはり大規模かつ複雑なネットワーク設計になると、設計や管理が難しくなるため、適切なネットワーク接続オプションを選択し、将来の拡張性を考慮した設計を行うことが重要です。

この記事が、Google Cloud の VPC ネットワークの理解と効果的な活用に役立てば幸いです。

Discussion