G-gen の杉村です。Google Cloud（旧称 GCP）の VPC やオンプレミス（専用線・VPN）ネットワークの間でハブアンドスポーク構成を実現するためのフルマネージドサービスである Network Connectivity Center をご紹介します。

概要

Network Connectivity Center とは

Network Connectivity Center とは、Google Cloud の VPC やオンプレミス（専用線・VPN）ネットワークの間でハブアンドスポーク・アーキテクチャを構成するためのフルマネージドサービスです。

ハブには、スポークとして「VPC」「Cloud VPN」「Cloud Interconnect」「Compute Engine VM のルータ仮想アプライアンス（VPC）」を接続できます。これらで接続されたネットワークが、ハブを通して経路交換し、フルメッシュ接続ができるようになります。

参考 : Network Connectivity Center の概要

ハブアンドスポークとは

ハブアンドスポーク（Hub and Spoke）とは、ネットワークのトポロジを表現する用語です。

スポークとは車輪における輻（や）の意味で、車輪の中心から輪に向けて放射状に伸びる棒のことです。

これに見立てて、ハブとなるノードを中心にして放射状にネットワークが配置されるトポロジをハブアンドスポークアーキテクチャと呼びます。

ユースケース

Network Connectivity Center を使って実現可能ないくつかのネットワーク構成をご紹介します。

以下の例では、オンプレミスサイトと複数の VPC と間の通信を実現しています。オンプレミスサイトが複数、また VPC ネットワークが複数あっても、相互に通信を実現することが可能です。

また以下の例では、Google Cloud の VPC である Network A と、オンプレミス拠点であるサイト A、B、C を接続してフルメッシュ通信を実現しています。対応しているリージョンであれば、サイト A、B、C が別々の大陸の異なる国に位置していても、Google のネットワークを利用して通信することが可能です。つまり、地理的に離れたオンプレミスサイト間を、Google の強力なバックボーンネットワークを活用して相互接続することが可能になります。

この図におけるハブとスポークの表現の方法は、先に掲げた「ネットワークにおけるハブアンドスポーク」の図と比べて、直感的ではないかもしれません。これは「Network Connectivity Center のハブとは、パケットが実際に通過する訳ではなく、スポーク間で経路交換をさせるためにグルーピングするためのリソースである」という点に起因します。詳細は後述します。

料金

Network Connectivity Center の料金は以下の2軸で決まります。

スポークの利用料金
データ転送料金
Advanced Data Networking（ADN）料金

前者のスポークの利用料金は、スポークが存在する時間に対する従量課金です。ただし無料枠として3つの VPN スポークと3つの Cloud Interconnect スポークは無料です。それぞれ4つめ以降から課金が発生します。スポークの種類によって単価が異なります。

後者のデータ転送料金は、Google Cloud と外部ネットワークの間で流れるデータサイズに対して課金されます。単価は地域や総データサイズによって異なりますが、例として東京リージョンの Google Cloud と日本国内の外部ネットワークの間における0〜1TiBの範囲内での単価は $0.11/GiB です（2024年11月現在）。

また Advanced Data Networking（ADN）料金は、後述する VPC スポーク間の通信のみで発生する、ハブを介して処理されたデータサイズへの課金のことで、$0.02/GiB です（2024年11月現在）。

最新の料金表や計算例については、以下のドキュメントをご参照ください。

参考 : Pricing

AWS Transit Gateway との違い

他のクラウドサービス経験者が仕様を理解しやすくするために、Amazon Web Services（AWS）の AWS Transit Gateway との違いを簡記します。

Network Connectivity Center と AWS Transit Gateway は共に複数のネットワークを接続してハブアンドスポーク構成を実現するためのフルマネージドサービスです。

AWS Transit Gateway では、Network Connectivity Center よりもより細かいルーティングの制御ができる点が異なります。

観点	Network Connectivity Center	AWS Transit Gateway
対応スポーク	専用線 / VPN / VPC	専用線 / VPN / VPC
ルーティング	フルメッシュ接続が前提だが、広報する経路を一部制御できる	AWS Transit Gateway 自体がルートテーブルを持つ。静的ルートを含む細かいルート設計が可能
課金	時間(h)とデータ容量(GiB)	時間(h)とデータ容量(GiB)

コンポーネント

概要

Network Connectivity Center のコンポーネントには大きく分けて「ハブ」と「スポーク」が存在します。

ハブは、Network Connectivity Center で構築するハブアンドスポークアーキテクチャのネットワークの中心となるコンポーネントです。

ハブは1つのプロジェクトに所属します。また、グローバルリソース（特定のリージョンに所属しないリソース）です。ハブにはほとんど設定項目が存在せず、スポークをグルーピングするためのリソースと考えて差し支えありません。

一方の スポークは、ハブとネットワークを繋ぐリソースです。リージョンリソースであり、1つのVPC ネットワークに所属します。

参考 : 仕組み

スポークの種類（タイプ）

スポークには以下の種類（タイプ）があります。

No	名称	説明
1	VPN トンネル	Cloud VPN（HA VPN）を接続するためのスポーク
2	VLAN アタッチメント	Cloud Interconnect を接続するためのスポーク
3	Router アプライアンス	仮想ルータアプライアンスで確立された VPN を接続したり VPC 同士を接続するためのスポーク
4	VPC	VPC を接続するためのスポーク

上記のようなスポークを作成し「サイト間データ転送」オプションを有効化することで、スポーク同士での通信が可能になります。

なお、VPC タイプ以外の3つのスポークはハイブリッドスポークと総称されます。

各スポークタイプの概要

VPN トンネル タイプのスポークは、その名の通り Cloud VPN トンネルを通して外部ネットワークと接続します。なお Cloud VPN には「Classic VPN」とより新しい「HA VPN」がありますが、後者のみが利用可能です。

VLAN アタッチメント タイプも同様に、Cloud Interconnect リソースである VLAN アタッチメントを通して外部ネットワークと接続します。

Router アプライアンス は、仮想ルータのアプライアンス（Compute Engine VM）を指しています。このスポークを使うパターンは後述します。ルータアプライアンスは、Google が指定する特定のサードパーティが公開するマシンイメージからデプロイする必要があります。

VPC タイプのスポークは、その名の通り複数 VPC 間を接続するためのスポークです。他組織・他プロジェクトの VPC 同士も接続が可能です。

オンプレミスサイトと VPC 間の接続

概要

Network Connectivity Center では、1つのハブに VPC スポークとハイブリッドスポーク（Cloud VPN や Cloud Interconnect）を接続することで、複数の VPC ネットワークと複数のオンプレミスサイトの相互通信が可能です。

参考 : Route exchange with VPC spokes

このように、Network Connectivity Center を使ってオンプレミスサイトと VPC の間の接続を構成するとき、VPC スポークを介してハブに接続する VPC のことをワークロード VPC ネットワークと呼びます。

また、ハイブリッドスポークとしてハブに接続されている Cloud Interconnect VLAN アタッチメントや HA VPN トンネルを持つ VPC のことはルーティング VPC ネットワークと呼びます。

ワークロード VPC ネットワークを「VPC スポーク」として、ルーティング VPC ネットワークを「ハイブリッドスポーク」として、それぞれハブに接続することで、相互通信が可能になります。

また同時に、ルーティング VPC ネットワークを「VPC スポーク」としてハブに接続することも可能です。これによりルーティング VPC ネットワーク内のサブネットへの経路がハブに広報されるため、他のワークロード VPC ネットワークからルーティング VPC ネットワーク内の VM 等への接続が可能になります。

参考 : Route exchange with VPC spokes

ルート伝播

ハブに VPC スポークとハイブリッドスポークを接続すると、ハブのルートテーブルには、接続されたすべての VPC サブネットとオンプレミスサイトの動的ルートが記録されます。

ハブに新しく VPC スポークやハイブリッドスポークが接続されたり、あるいは削除されたとき、ハブのルートテーブルは自動的にルートを学習します。

ハブがハイブリッドスポークから（オンプレミス側から）学んだルートは、VPC スポークに自動的に広報されます。

ハブが VPC スポークから学習した動的ルートは、Import of hub subnets for hybrid spokes を有効化することで、自動的にハイブリッドスポーク（オンプレミス側）に広報されます。このとき --include-import-ranges オプションで、オンプレミス側に広報する IP アドレスレンジを CIDR 形式で指定できます。ALL_IPV4_RANGES 設定値を指定することですべての CIDR を広報することも可能です。

広報するルートを細かくコントロールしたいときは、Import of hub subnets for hybrid spokes を使わずに、Cloud VPN や Cloud Interconnect の Cloud Router でカスタムルート広報を構成することで、明示的にルートを広報することも可能です。

参考 : Import of hub subnets for hybrid spokes

VPC 間接続（VPC スポーク）

概要

VPC タイプのスポークを用いることで、VPC 間のフルメッシュ接続を実現できます。異なる組織・異なるプロジェクトの VPC ネットワーク同士を接続することも可能です。

現在では IPv4 アドレスのみに対応しています。エクスポートフィルタにより特定の IP レンジのみルート交換を除外することも可能です。これにより、特定のサブネットだけをフルメッシュ接続から除外することができます。

参考 : VPC spokes overview

他のプロジェクトとの接続

VPC タイプのスポークでは、異なる組織・異なるプロジェクトの VPC ネットワーク同士を接続することも可能です。

ハブを持つプロジェクトは別のプロジェクトで VPC スポークが作られた場合、作成時は、スポークが非アクティブ状態になります。ハブ側の管理者が承認して初めて、スポークが有効化されます。

VPC ネットワークピアリングとの違い

異なる VPC ネットワーク同士の接続は、Network Connectivity Center を使わなくても VPC ネットワークピアリングを用いることで実現できます。しかし VPC ネットワークピアリングは VPC ネットワーク同士をピアツーピアで繋ぐ機能のため、VPC の数を n とすると n(n-1)/2 のピアリングが必要になります。VPC の数が多くなればなるほど各種上限への抵触リスクと管理オーバヘッドが上昇します。

Network Connectivity Center の VPC スポークを使えば、VPC ネットワークをハブに接続することで容易にフルメッシュ接続を実現できます。また、VM インスタンス数の制限もありません。VPC ネットワークピアリングとの差異に関するその他の情報は以下の公式ガイドをご参照ください。

参考 : Comparison to VPC Network Peering

VPC ネットワークピアリングとの推移的接続

ある VPC が VPC ネットワークピアリング経由で受け取ったルートは、Network Connectivity Center へは再広報されません。以下のような構成を例に取ります。

VPC A と VPC B は、ハブに接続されている
VPC C は、VPC A と VPC ネットワークピアリングで接続されている

上記のような環境では、パケットの到達可能性は以下のようになります。

通信経路	到達可能性
A <-> B	True
A <-> C	True
B <-> C	False

プロデューサー VPC スポークと Private Service Access

プロデューサー VPC スポーク（Producer VPC spokes）を使うと、ハブに接続された各 VPC から、Private Service Access を使う Google Cloud サービスへの接続性を確保することができます。

Private Service Access とは、Cloud SQL や Memorystore、Cloud Build などで用いられる仕組みです。これらのサービスのインスタンスは、Google が管理する VPC ネットワークで起動します。この Google 管理の VPC ネットワークのことを、サービスプロデューサーネットワークと呼びます。サービスプロデューサーネットワークとユーザーの VPC は servicenetworking-googleapis-com という名称の VPC ネットワークピアリングで接続されます。

プロデューサー VPC スポークを設定することで、ハブに接続されたユーザーの VPC からサービスプロデューサーネットワークに推移的にアクセスすることができます。構成は、以下のようになります。

当機能は2024年11月現在、Preview です。

参考 : Producer VPC spokes

制限

代表的な仕様上の制限等を紹介します。全量は公式ドキュメントをご参照ください。

構成の制限
- ハブ経由での VPC ネットワークピアリングへの推移的接続は不可
- 同じハブに接続する VPC 間では IP アドレスの重複は不可（エクスポートフィルタで除外すれば可）
- エクスポートフィルタは VPC スポーク作成時のみ指定可能で、作成後は変更できない
数量の制限（割り当てと制限）
- スポークあたりエクスポートフィルタで指定可能な CIDR レンジ数 : 16個
- プロジェクトあたりの VPC スポーク数の最大値 : 1,000
- ハブあたりのアクティブな VPC スポーク数の最大値 : 250

サイト間データ転送

概要と制限事項

スポークでサイト間データ転送を有効化すると、同じハブに接続されたスポーク同士の間で BGP による経路交換が行われ、フルメッシュの相互通信が可能になります。これにより、例えば米国のオンプレミスサイトと日本のオンプレミスサイトが、Google Cloud のネットワークを介して相互に通信することが可能になります。

ただしあるハブにおいて、オンプレミスサイト間同士のデータ転送を行うには、全てのスポークリソース（VPN トンネル、VLAN アタッチメント、アプライアンス VM）が同じ VPC に所属している必要があります。

またサイト間データ転送は使えるリージョンが制限されています。対応リージョンは日本、韓国、シンガポール、米国、フランス、ドイツ、英国など一部のリージョオンのみです。リージョンの一覧は以下のドキュメントをご参照ください。

参考 : データ転送でサポートされているロケーション

その他の制限事項や考慮事項は、以下を参照してください。

参考 : サイト間データ転送の概要

経路交換とトラフィック

サイト間データ転送が複数スポークで有効化されると、各スポークが BGP で受け取った経路が Network Connectivity Center により全スポークに再広報されます。これによりスポーク同士がフルメッシュでトラフィックをやりとりできるようになります。

実際にパケットがハブを通るわけではなく、Google Cloud の内部ネットワークで折り返して、スポーク間で直接トラフィックがやりとりされます。

参考 : サイト間データ転送によるルート交換

AS 番号

サイト間データ転送では各ネットワークは BGP を用いて経路交換するため、以下の AS 番号（ASN）の要件に従う必要があります。

単一ハブに紐づく Cloud Router は全て同じ AS 番号
各スポーク側は、単一スポーク内では同じ AS 番号
Cloud Router と各スポークは、重複しない AS 番号

参考 : サイト間データ転送の ASN 要件

Router アプライアンスを使った構成

概要

Router アプライアンスタイプのスポークの用途は最も分かりづらいかもしれません。以下のような用途で使われます。

オンプレミス拠点と VPC を接続（サイト-to-クラウド接続）
VPC 間接続

Router アプライアンスタイプのスポークは、Compute Engine VM で動作する仮想ルータアプライアンスをベースリソースとします。

仮想ルータは Google Cloud の指定するサードパーティのイメージファイルから起動します。デプロイされた仮想ルータは Cloud Router と経路交換を行うことができ、これにより他のスポークとの経路交換を実現できます。サードパーティは Cisco、Fortinet、Palo Alto Networks などが対応しており、以下の一覧で確認できます。

参考 : Network Connectivity Center のパートナー

オンプレミス拠点と VPC を接続（サイト-to-クラウド接続）

オンプレミス拠点と複数 VPC の間で経路を交換し、フルメッシュ接続を行うために Router アプライアンスタイプのスポークを利用できます。

Compute Engine VM は複数の VPC ネットワークにまたがってネットワークインターフェイスを持つことができます。これにより仮想ルータ VM は複数 VPC ネットワーク間でパケットのルーティングを行うことができます。

またこの図では、Router アプライアンスがオンプレミスサイトとの IPSec VPN を確立しており、オンプレミスのルータとの経路交換も行っています。仮想ルータは Cloud Router から VPC のプレフィクスを学習して、BGP を使って経路交換を行います。

参考 : サードパーティアプライアンスを使用するサイトツークラウドトポロジ

VPC 間接続

異なる複数の VPC ネットワーク間で接続を確立するために Router アプライアンスを使う方法も紹介されています。

参考 : サードパーティアプライアンスを使用する VPC 間のトポロジ

監視・運用

モニタリング指標

Network Connectivity Center のモニタリング指標は Cloud Monitoring で自動的に取得されます。

各スポークにおける上り・下りのバイト数が主です。また各スポーク（VPC や Cloud VPN、Cloud Interconnect）の情報は、各サービス側のメトリクスを参照します。

参考 : モニタリング指標

監査ログ

Network Connectivity Center からは Cloud Logging に監査ログが送信されます。設定変更（ハブやスポークの作成・更新・削除）などが記録され、Cloud Logging のメトリクスエクスプローラで閲覧することができます。

参考 : 監査ロギング情報

Cloud Logging については以下もご参照ください。

blog.g-gen.co.jp

補足事項・留意点

可用性

スポーク間を通るパケットは、実際に Network Connectivity Center のハブを通るわけではありません。Network Connectivity Center はあくまで経路交換を実現する仕組みであり、実際のパケットは Google Cloud の内部ネットワークで折り返してスポーク同士で直接やりとりされます。そのため、スポークリソース（Cloud VPN / Cloud Intercconnect / Router アプライアンス）の可用性が重要になります。

それぞれの可用性の考え方は、以下をご参照ください。