Zenn
🤙

VPC 接続前に知っておこう！Private Service Connect

に公開
Security
network
Google Cloud
VPC
Private Service Connect
tech

はじめに

こんにちは。クラウドエースの田中です。

わたしたちが Google Cloud を利用する際、さまざまなサービスや VPC を利用します。

そんなとき、こんな困りごとはないでしょうか。

  • VPC 同士を接続したいから VPC ピアリングの利用を検討しているけど、IP アドレスの重複管理・ルーティングの管理が大変
    • 例: 最初は VPC 同士の接続なんていらないはずだったのに、後から追加で考える必要が出てきてしまった
  • VPC 全体をつなぐことになる VPC ピアリングより、細かい粒度でアクセス制御を行いたい
  • 各サービス間での通信を行う時、その通信をインターネットに出さず Google Cloud 内に留めておきたい

今日はこれらの要件を解決できる、Google Cloud の Private Service Connect（以下、PSC）についてご紹介します。

TL;DR

PSC を使うことで、上記困りごとにはこのようにアプローチできます。

  • 困りごと: IP アドレスの重複管理・ルーティングの管理が大変
    • PSC だと: VPC 間の通信の際には NAT が用いられるため、IP アドレスの調整が不要になり、また共有リソースの依存関係も存在しません
  • 困りごと: VPC ピアリングより細かい粒度でアクセス制御を行いたい
    • PSC だと: PSC の「サービス指向」の設計により、意図したサービスエンドポイントのみにアクセスさせる・させないことが可能
  • 困りごと: 各サービス間での通信を行う時、その通信をインターネットに出さず Google Cloud 内に留めておきたい
    • PSC だと: 通信が Google Cloud 内部で完結

このように、PSC は VPC 間接続における多くの課題を解決する、便利で強力な選択肢となります。
これから Google Cloud でネットワーク構成を考える際に、ぜひ検討していただければと思っています。

では、さっそく見ていきましょう。

Private Service Connect（PSC）とはなにか

Private Service Connect は、VPC をまたいで Google Cloud 内のサービスに接続する際に、その通信をプライベートに保つための仕組みの 1 つです。
プライベートに、というのは、Google Cloud のサービスに接続する側は自身の内部 IP アドレスを利用して、通信をインターネットに出すことなく、ということです。

これだけでは分かりにくいかもしれません。
公式ドキュメントの図を見るのがわかりやすそうです。


出典: https://cloud.google.com/static/vpc/images/psc-overview.svg

このように、コンシューマ（サービスに接続する側）とプロデューサ（サービスを提供する側）の 2 つの間をピンポイントでつないでくれるのが PSC です。

コンシューマ側の VPC にエンドポイントなど（種類については後述します）を用意し、そこへのアクセスを転送ルールに基づいてプロデューサ側 VPC の対応する API との通信を行います。
このとき、コンシューマとプロデューサの両 VPC の間は Google Cloud のネットワーク、具体的にはGoogle Cloud のソフトウェア定義ネットワーク（Software Defined Network: SDN）である Andromeda を利用[1]して通信が行われます。


出典: https://cloud.google.com/vpc/docs/private-service-connect-architecture

Andromeda は分散コントロールプレーンと分散データプレーンでできており、この Andromeda の性能のおかげで PSC 利用時のネットワークへの影響（遅延・帯域幅）といったことを考える必要はほぼなくなっています。

PSC の料金

PSC の利用には料金がかかります。

具体的には、1 PSC エンドポイントごとに、1 時間あたり 0.01 USD がかかります（2025/06/05 現在）。
これは月単位では 7.2 USD 程度となり、日本円に換算するとだいたい 1000 ~ 1100 円の間になるかと思います。

なお、PSC エンドポイントを経由して行われるデータ転送量に対しては、2025/06/05 時点で課金されません。

上記情報はこれを読まれている時点でアップデートされている可能性があるため、実際に使用を検討する際は必ず下記の公式ドキュメントを参照してください。

PSC の割当（Quota）・上限・制限

PSC の割当（Quota）・上限（Limit）・制限についても触れておきます。

プロジェクトごとの割当、VPC（ネットワーク）ごとの割当のそれぞれがあります。
例えばそれぞれごとに転送ルールの割当があり、上限を引き上げ可能なものや引き上げ不可能なものがあります。
これらは他の VPC 周りの機能の割当と並んで、下記の公式ドキュメントに記載があります。

PSC に関わる上限（Limit）は 2025/06/05 現在、公式ドキュメントに記載がありません。
ただし転送ルールやサービスアタッチメントなど、関連するリソースの割り当て（Quota）や上限には従います。

また、PSC を利用できるサービス（Google Cloud もしくはサードパーティ問わず）は、下記にて公開されています。

PSC の主要な接続形態 3 種を解説

では、ネットワークエンジニアや VPC 設計担当が PSC を利用する際に検討すべき、PSC の主要なコンポーネント 3 つを見ていきましょう。

具体的には以下のものです。

コンシューマ側（2 点） プロデューサ側（1 点）
PSC エンドポイント
PSC バックエンド 		PSC インタフェース

1: エンドポイント

PSC エンドポイントは、コンシューマ側 VPC に用意する内部 IP アドレスです。
クライアントの内部 IP アドレスからこのエンドポイントの内部 IP アドレスにアクセスすると、転送ルールに基づいて以下の 3 種類の転送先に通信を送ることができます。

  1. 公開されたサービス（Published Service）
  2. グローバル Google API
  3. リージョナル Google API

1.1 公開されたサービス（Published Service）への PSC 経由アクセス

コンシューマにとって接続したいプロデューサ側が PSC に対応している場合、このやり方を使って接続します。
他の VPC に PSC を使って接続する場合、このパターンでの接続となるのが一般的です。


出典: https://cloud.google.com/vpc/docs/about-accessing-vpc-hosted-services-endpoints

上図のように、コンシューマ側に PSC エンドポイントを、プロデューサ側にサービスアタッチメントを配置します。

コンシューマ側でのエンドポイントの作り方は、下記公式ドキュメントのページに記載があります。

なお、PSC コンシューマ側がサービスプロデューサ側に接続する方法によっては、プロデューサ側が対応していないもしくは設定変更が必要なケースがあります。
具体的な組み合わせパターンについては、下記の公式ドキュメントをご覧ください。

公開されたサービスに対して PSC エンドポイントを利用する際は、コンシューマ側とプロデューサ側のそれぞれの VPC 内のサブネットが同じリージョンになければいけません[2]。
また、同一 VPC 内にコンシューマとプロデューサを配置できません[3]。

1.2 グローバル Google API への PSC 経由アクセス

Google Cloud の各リソースは Web API への操作を通じてアクセスされます。
こうした Web API のデフォルトの DNS 名はパブリックにアクセスできる IP アドレスに紐づいています。

一方で PSC エンドポイントとそれに紐づくグローバル内部 IP アドレスを VPC 内に設置し、そうした IP アドレスに対して DNS 名を割り当てることで、VPC 内で通信が完結することを保証しつつ、トラフィックのより細やかな管理が可能になります。


出典: https://cloud.google.com/vpc/docs/about-accessing-google-apis-endpoints

このように、当該の VPC 内で Google API にアクセスする際に通常用いる DNS 名を変更することで、Google Cloud 内に通信が完結することを保証するのがこの機能の主目的です。

そうした DNS 設定も含めてどのように構築するのかについては、下記の公式ドキュメントに記載があります。

1.3 リージョナル Google API への PSC 経由アクセス

こちらは 1.2 グローバル Google API への PSC 経由アクセスのリージョン版という位置付けです。

具体的には、あるリージョン内に通信途中のデータも保たれなければいけない場合などに利用を考慮します。

構築方法は概ね上記グローバル版と似たものであり、下記から確認できます。

PSC エンドポイントの追加情報

ここではすでに提供されているサービスに対してアクセスするための、コンシューマ側からのアプローチについて記載しました。
当然その逆となる、サービスを提供する側の視点もあります。

その際、サービスプロデューサは

  1. PSC 提供用のサブネットを作成
  2. 作成したサブネットにひもづくサービスアタッチメントを作成

の 2 つを行うことで、コンシューマ側に PSC 経由での接続を提供できます。

より詳しくは下記の公式ドキュメントをご覧ください。

また、PSC コンシューマ側の情報は、今回多くリンクしているような https://cloud.google.com/vpc/docs/ 配下ではなく、各サービス（例えば Cloud SQL、AlloyDB）側にも含まれていることがあります。

例えば以下のページです。

接続したいサービスプロデューサ側にも情報があるかもしれないので、併せて公式ドキュメントを確認することをおすすめします。

2: バックエンド

PSC エンドポイントは、VPC ネットワーク内に配置される単一の内部 IP アドレス（転送ルールによって提供される）を介して、Google API や公開サービスへのアクセスを提供します。
この IP アドレスが、クライアントからのトラフィックのプライベートな入り口として機能します。

一方で PSC バックエンドでは、ロードバランサと PSC NEG（network endpoint group）を組み合わせて利用します。


出典: https://cloud.google.com/vpc/docs/private-service-connect-backends

上記の図は外部グローバルアプリケーションロードバランサのバックエンドに PSC NEG が配置されて、それを通して公開サービスに接続している様子を表しています。

これの使い所は上の図でも示されているように、わたしたちユーザ側が Google Cloud のプロダクトを使って構築したサービスを、外部に公開する時になります。
例えばサービスを構築した Google Cloud プロジェクト以外の Google Cloud プロジェクト、もしくはインターネットを通しての公開です。

これまでの VPC ピアリングや Cloud VPN だと必要になっていた IP アドレス範囲の管理といったものがこの方法だと必要なくなる、というのが嬉しいポイントです。

なお、この機能を使えるロードバランサには制限があります。
サポートされているロードバランサの種類については下記の公式ドキュメントをご覧ください。

PSC バックエンドの追加情報

実際に PSC バックエンドを作成する際は下記の公式ドキュメントが参考になります。

またサービスを公開する手順については、下記の公式ドキュメントにまとまっています。

3: インタフェース

PSC インタフェースは、これまで紹介してきた PSC エンドポイントおよびバックエンドと異なり、プロデューサ側（サービス公開側）の VPC に作成するリソースです。
PSC インタフェースをプロデューサ側に配置し、コンシューマ側にはその受けとなる PSC ネットワークアタッチメントを配置します。

このとき作成する PSC インタフェースの実態としては、2 つ以上のネットワークインタフェースをもった Google Compute Engine（以下、GCE） インスタンスとなります。


出典: https://cloud.google.com/vpc/docs/about-private-service-connect-interfaces

上の図にも示されているように、GCE インスタンスに紐づいているネットワークインタフェースそれぞれが、プロデューサ側 VPC のサブネットもしくはコンシューマ側 VPC の PSC ネットワークアタッチメントに接続されます。

これだけだと PSC エンドポイントとサービスアタッチメントの接続との違いがわかりにくいと思います。
プロデューサ側に主語を持ってきただけで、内容は変わらないように見えます。

しかし公式ドキュメントによると、重要な違いが 2 点あります。

  • ネットワーク アタッチメントを使用すると、プロデューサー VPC ネットワークからコンシューマー VPC ネットワークへの接続（マネージド サービスの下り、外向き）を開始できます。エンドポイントは逆方向に機能し、コンシューマー VPC ネットワークがプロデューサー VPC ネットワークへの接続（マネージド サービスの上り、内向き）を開始できるようにします。
  • Private Service Connect インターフェースの接続は推移的です。つまり、プロデューサー VPC ネットワーク内のワークロードは、コンシューマー VPC ネットワークに接続されている他の VPC ネットワークのワークロードに接続できます。

言い換えると、プロデューサ側からコンシューマ側への通信も可能になること、またコンシューマ側 VPC に接続されている他の VPC、オンプレミスネットワークへの接続も提供しているということです。

それぞれ公式ドキュメントの図が参考になります。


出典: https://cloud.google.com/vpc/docs/about-private-service-connect-interfaces


出典: https://cloud.google.com/vpc/docs/about-private-service-connect-interfaces

PSC インタフェースの追加情報

PSC インタフェースおよびネットワークアタッチメントの作成方法についてはこちらをご覧ください。

インタフェース

アタッチメント

さらに興味がある人に

こうした PSC の諸機能は Google Cloud でハブ・アンド・スポークアーキテクチャによるネットワーク設計を実現するためのプロダクトである、Network Connectivity Center（以下、NCC） と組み合わされることで、さらに価値を発揮させることもできます。

例えば今回は説明できませんでしたが、NCC を使って PSC エンドポイントが存在する VPC をスポークとして構成することで、当該の PSC エンドポイントの存在を伝播してくれる機能があります。
言い換えると、ある VPC から別の VPC に存在する PSC エンドポイントにアクセスできる（= VPC ごとに PSC エンドポイントを作る必要がなくなる）ということです。

NCC 側、PSC 側それぞれに対応する公式ドキュメントがあります。
併せてご覧いただけると幸いです。

まとめ

PSC とは、Google Cloud の VPC 同士を接続したいときに使える 1 つの手段です。
以下の種類があります。

  1. PSC エンドポイント
    1.1 コンシューマ側 VPC で作成する、内部 IP アドレス。この内部 IP アドレスへの通信が、プロデューサ側の VPC に転送される
  2. PSC バックエンド
    1.1 ロードバランサのバックエンドとして作成するリソース。ロードバランサとバックエンドのサービスを PSC を使って接続する
  3. PSC インタフェース
    1.1 プロデューサ側 VPC に作成するリソース。実態は GCE の VM。プロデューサ側 VPC からコンシューマ側への通信を可能にする

下記のような困りごとがあるときは、PSC の採用をぜひご検討ください。

困りごと PSC だと
IP アドレスの重複管理・ルーティングの管理が大変 VPC 間の通信の際には NAT が用いられるため、IPアドレスの調整が不要になり、また共有リソースの依存関係も存在しません
VPC ピアリングより細かい粒度でアクセス制御を行いたい PSC の「サービス指向」の設計により、意図したサービスエンドポイントのみにアクセスさせる/させないことが可能
各サービス間での通信を行う時、その通信をインターネットに出さず Google Cloud 内に留めておきたい 通信が Google Cloud 内部で完結

こうした Google Cloud の機能を活かしたネットワーク構築については、弊社クラウドエースのような Google Cloud に知見のあるベンダーの活用もご検討ください。

最後までお読みいただきありがとうございました。

脚注

  1. https://cloud.google.com/vpc/docs/private-service-connect-architecture ↩︎

  2. https://cloud.google.com/vpc/docs/configure-private-service-connect-services#:~:text=The subnet must be in the same region as the service that you want to connect to. ↩︎

  3. https://cloud.google.com/vpc/docs/about-accessing-vpc-hosted-services-endpoints#limitations ↩︎

Discussion