Private Service Connect

解決する課題

マネージドサービスや他組織のサービスへ、インターネットや外部 IP を経由せずに到達したい、というのが核心です。

• Google API（Cloud Storage、BigQuery など）へ、外部 IP を持たないインスタンスから閉域で到達したい
• 別 VPC・別組織が公開するサービスへ、IP レンジの重複を気にせず接続したい
• 自社サービスを SaaS のように他テナントへ公開しつつ、相互の VPC を直接ピアリングせずに済ませたい
• トラフィックを Google のバックボーン内に留め、攻撃面と外部依存を減らしたい

VPC ピアリングのように両者のネットワークを丸ごと結合するのではなく、特定のサービス単位で接続点だけを露出させるのが特徴です。

主要概念と用語

• コンシューマ: サービスを利用する側。自分の VPC 内に接続用の入口（エンドポイント）を作る
• プロデューサ: サービスを提供する側。ロードバランサの背後にサービスを置き、公開のための受け口を用意する
• エンドポイント（コンシューマ側）: コンシューマ VPC 内に確保したプライベート IP。ここ宛ての通信がプロデューサのサービスへ転送される。内部的には転送ルールとして実装される
• サービスアタッチメント（プロデューサ側）: プロデューサが内部ロードバランサに紐づけて公開する受け口。どのコンシューマからの接続を許可するかを制御する
• PSC バックエンド: エンドポイントの代わりにロードバランサのバックエンドとして PSC を組み込む形態。コンシューマ側で独自のロードバランサ機能を被せたい場合に使う
• アクセス先の種類: 大きく「Google API への PSC」「公開済みサービスへの PSC（プロデューサ・コンシューマ間）」の 2 系統がある
• 承認モデル: サービスアタッチメント側で、接続を自動承認するプロジェクトの許可リストか、手動承認かを選べる

仕様・制限・クォータ

• リージョン単位のリソース。エンドポイントとサービスアタッチメントは原則として同一リージョンで接続する
• コンシューマとプロデューサで IP レンジが重複していても接続できる（NAT 的に変換されるため）。これがピアリングに対する大きな利点
• プロデューサ側のサービスは内部ロードバランサの背後に置く必要がある。サービスアタッチメントはその内部ロードバランサに紐づく
• 接続はサービス単位で、両 VPC のルートや内部 IP 空間全体が相互に見えるわけではない
• エンドポイント数・サービスアタッチメント数・接続数などにクォータがある。規模が大きい構成では上限を事前に確認し、必要なら引き上げ申請する
• Google API 向け PSC では、専用の IP を確保し、対象 API バンドル（全 API か、VPC Service Controls 対応のバンドルか）を選んで構成する

内部の仕組み

PSC は、コンシューマ VPC 内のプライベート IP 宛ての通信を、Google のネットワーク内部でプロデューサ側のサービスへ橋渡しします。要点は「接続点だけを公開し、ネットワーク全体は結合しない」ことです。

• コンシューマはエンドポイント用にプライベート IP を 1 つ確保し、その IP 宛ての通信が PSC 経由でプロデューサのサービスアタッチメントへ向かう
• プロデューサ側ではサービスアタッチメントが内部ロードバランサを指し、その背後の実体（インスタンス群、サーバーレスなど）へ分散される
• 通信経路は Google のバックボーン内で完結し、インターネットを経由しない
• IP レンジが重複していても、PSC が送信元 IP を変換するため衝突しない。プロデューサ側から見える送信元は PSC が用意したレンジになる
• 接続の可否はサービスアタッチメントの許可リスト／承認設定で制御され、許可されたコンシューマプロジェクトのみが接続できる

設計パターン / ベストプラクティス

• 外部 IP を持たせたくないインスタンスから Google API へ到達する経路として、Google API 向け PSC を採用する
• 自社サービスを複数テナントへ提供する場合、各コンシューマにサービスアタッチメントを公開し、相手 VPC とピアリングしない疎結合な SaaS 提供にする
• 重複 IP を持つ複数組織・買収後の統合環境など、レンジ調整が困難なケースで PSC を選び、再設計コストを避ける
• コンシューマ独自のロードバランシングやヘルスチェックを被せたい場合は、エンドポイントではなく PSC バックエンド形態を検討する
• 承認は安易な全自動にせず、信頼できるプロジェクトのみを許可リスト化し、不要な接続を作らせない

運用・監視

• Cloud Monitoring で PSC 接続の通信量・接続状態を監視し、想定外の接続増加や切断を検知する
• VPC フローログでエンドポイント経由のトラフィックを可視化し、誰がどのサービスへ流しているかを把握する
• プロデューサ側は接続要求の承認状況を定期的に棚卸しし、不要になったコンシューマ接続を削除する
• 接続不能の切り分けでは、エンドポイントの IP・リージョン整合、サービスアタッチメントの許可リスト、内部ロードバランサの健全性を順に確認する

コスト

課金の中心は PSC を介した処理データ量と、付随するロードバランサなどのリソースです。

具体的な単価は変動するため、料金は公式の料金ページで最新値を確認してください。

セキュリティ

• トラフィックがインターネットを経由しないため、外部公開エンドポイントを持たずにサービス連携でき、攻撃面を縮小できる
• サービスアタッチメントの許可リスト／手動承認で、接続できるコンシューマを厳密に制限する
• Google API 向け PSC を VPC Service Controls と組み合わせ、サービス境界の外へのデータ持ち出しを防ぐ構成にできる
• IAM でエンドポイント・サービスアタッチメントの作成・変更権限を最小化する
• 外部 IP を持たないインスタンスからでも Google API に到達できるため、インスタンスに外部 IP を付ける必要がなくなる

Well-Architected の観点

• セキュリティ: 閉域接続でインターネット露出を排し、許可リストと VPC Service Controls で接続範囲とデータ持ち出しを統制する。これが PSC の最大の価値
• 信頼性: プロデューサ側を内部ロードバランサ＋複数バックエンドで冗長化し、単一障害点を避ける
• 運用性: 接続の承認・棚卸しを定期化し、不要な接続が残り続けないようにする

試験で問われるポイント

関連サービス・比較

VPC 全体を相互到達させたい場合は VPC ネットワークピアリング、オンプレミスとの専用線接続は Cloud Interconnect、Google マネージドサービスへの内部接続全般はプライベート サービス アクセスも比較対象になります。PSC は「サービス 1 点だけを閉域公開・利用する」ニーズに最適です。

ハンズオン / CLI例

# コンシューマ: PSC エンドポイント用のプライベート IP を予約
gcloud compute addresses create psc-endpoint-ip \
  --region=asia-northeast1 \
  --subnet=consumer-subnet \
  --addresses=10.10.0.50

# コンシューマ: 公開済みサービス（サービスアタッチメント）へのエンドポイントを作成
gcloud compute forwarding-rules create psc-endpoint \
  --region=asia-northeast1 \
  --network=consumer-vpc \
  --address=psc-endpoint-ip \
  --target-service-attachment=projects/producer-proj/regions/asia-northeast1/serviceAttachments/my-service

# プロデューサ: 内部ロードバランサを公開するサービスアタッチメントを作成（手動承認）
gcloud compute service-attachments create my-service \
  --region=asia-northeast1 \
  --producer-forwarding-rule=internal-lb-fr \
  --connection-preference=ACCEPT_MANUAL \
  --nat-subnets=psc-nat-subnet \
  --consumer-accept-list=consumer-proj=10

# 接続状態を確認
gcloud compute forwarding-rules describe psc-endpoint \
  --region=asia-northeast1 --format="value(pscConnectionStatus)"