サービスを選ぶ

VPC の設計

VPC はグローバル、サブネットはリージョンのリソースです。プロジェクトをまたいでネットワークを共有するなら Shared VPC、サービス 1 つを公開するなら Private Service Connect を選び、ロードバランサは HTTP(S) か、外部か内部か、グローバルかで決めます。

Google Cloud の VPC は 1 つで全リージョンにまたがり、サブネットだけをリージョンごとに切ります。設計で迷うのは、プロジェクトをまたいだネットワークのつなぎ方と、ロードバランサの種類の 2 つです。IP アドレス、サブネット、ルーティング、ファイアウォールの仕組みそのものはIP アドレスとサブネットとルーティング、NAT、ファイアウォールで扱ったので、ここでは Google Cloud での選び方だけを書きます。

VPC はグローバル、サブネットはリージョン

東京と大阪の VM は、VPN もピアリングもなしに内部 IP で通信できる。外部 IP のない VM の出口は、行き先がインターネットなら Cloud NAT、Google の API なら限定公開の Google アクセス

本番の VPC はカスタムモードで作ります。自動モードは全リージョンに 10.128.0.0/9 の中からサブネットを自動で作るため、ほかの VPC やオンプレミスと範囲が重なりやすく、重なるとピアリングも VPN 経由の経路も組めません。GKE を VPC ネイティブで使うなら、Pod と Service の IP にサブネットのセカンダリ範囲を消費するので、大きめに確保します。

本番の VM には外部 IP を付けません。外へ出る経路は上の図の 2 つで、Cloud NAT はリージョンのリソースとして Cloud Router に紐付けて作ります。送信だけを変換するので、インターネットから VM への接続は開きません。

ファイアウォールは組織の層と VPC の層で重ねる

VPC のファイアウォールルールの適用先は、IP 範囲のほかにネットワークタグかサービスアカウントで指定できます。タグは VM の編集権限があれば誰でも付け替えられるので、権限を分けたいならサービスアカウントで指定します。

組織全体に同じルールを強制するなら、階層型ファイアウォールポリシーを組織かフォルダに関連付けます。「社外から 22 番ポートへの接続を拒否する」をセキュリティチームが組織に置けば、各プロジェクトの管理者は VPC のルールで上書きできません。ファイアウォールの機能は Cloud NGFW という名前で Essentials、Standard、Enterprise の 3 階層があり、試験ガイドにある侵入防止は Enterprise の機能です (Cloud NGFW の概要)。

プロジェクトをまたぐなら、まず Shared VPC

共有する範囲が違う。Shared VPC はネットワークそのもの、ピアリングは経路、Private Service Connect はサービス 1 つ

同じ組織で「ネットワークは中央のチームが管理し、アプリのチームは自分のプロジェクトの VM だけを触る」なら Shared VPC です。どのサービスプロジェクトにどのサブネットを使わせるかを IAM で決められるので、職務の分離もそのまま書けます。

VPC ネットワークピアリングで試験に出る制約は 3 つです。推移しないこと、IP 範囲が重なる VPC 同士はつなげないこと、ファイアウォールルールを交換しないので両側で書くこと。下のシミュレーターで確かめてください。多数の VPC をまとめてつなぐなら、次のページの Network Connectivity Center を使います。

Private Service Connect は、利用側の VPC に置いたエンドポイントの内部 IP 宛てに送ると、提供側のサービスに届く仕組みです。IP 範囲が重なっていても使えるので、「多数の顧客 VPC に SaaS を提供する」「買収先と IP が重なっている」はこちらで解きます。Cloud Storage などの Google の API へのエンドポイントも作れます。

試すVPC ピアリングの到達性

ピアリング

A と B をつなぐ

B と C をつなぐ

A と C をつなぐ

受信を許可するルール (ピア先の範囲から)

VPC A に置く

VPC B に置く

VPC C に置く

C のサブネットを A と同じ 10.1.0.0/24 にする

A の VM → B の VM: 届くピアリングで経路があり、B の許可ルールが受信を通す
A の VM → C の VM: 届かないB を介しても届かない。ピアリングは推移しない
B の VM → A の VM: 届くピアリングで経路があり、A の許可ルールが受信を通す
B の VM → C の VM: 届くピアリングで経路があり、C の許可ルールが受信を通す
C の VM → A の VM: 届かないB を介しても届かない。ピアリングは推移しない
C の VM → B の VM: 届くピアリングで経路があり、B の許可ルールが受信を通す

ピアリングは推移しません。A と B、B と C をつないでも A と C は届かないので、直接ピアリングするか Network Connectivity Center のハブにまとめます。

ロードバランサは 3 つの問いで決まる

負荷分散の仕組みはロードバランシングの基礎で扱いました。Google Cloud の 10 種類を超える構成は、HTTP(S) か、外部か内部か、グローバルかリージョンかの順に答えて絞ります。

最初の分かれ目は HTTP(S) かどうか。パススルー型だけが UDP を扱え、クライアントの送信元 IP をそのままバックエンドに渡す

内部のアプリケーションロードバランサにグローバル版はなく、リージョン障害に備えるならクロスリージョン内部を選びます。外部パススルー型のグローバル版は 2026 年 10 月時点でプレビューです (ロードバランサの選び方)。グローバル外部アプリケーションロードバランサは、既定の Premium 階層でしか作れません。安い Standard 階層ではリージョンのロードバランサだけが使えます。

外部アプリケーションロードバランサには 3 つを組み合わせます。Cloud CDN はバックエンドで有効にするキャッシュで、配信を速くし下り料金を減らします。Cloud Armor は WAF と DDoS 対策で、OWASP の Core Rule Set に基づくルール、IP や国での許可と拒否、レート制限を書けます (対応するロードバランサはCloud Armor の概要)。Cloud DNS は公開ゾーンのほかに VPC の中だけで引ける限定公開ゾーンを持ち、オンプレミスの DNS との転送も組めます。

試してみる

カスタムモードの VPC に外部 IP のない VM を作り、Cloud NAT 経由でインターネットに出られることを確かめます。SSH は IAP 経由で入ります。Cloud Shell で実行してください。

REGION=asia-northeast1
ZONE=asia-northeast1-a

gcloud compute networks create lab-vpc --subnet-mode=custom
gcloud compute networks subnets create lab-subnet \
  --network=lab-vpc --region=$REGION --range=10.10.0.0/24 \
  --enable-private-ip-google-access

# IAP の TCP 転送が使う送信元範囲からの SSH だけを許可する
gcloud compute firewall-rules create lab-allow-iap-ssh \
  --network=lab-vpc --direction=INGRESS --allow=tcp:22 \
  --source-ranges=35.235.240.0/20

gcloud compute instances create lab-vm \
  --zone=$ZONE --machine-type=e2-micro \
  --subnet=lab-subnet --no-address

この時点で外へ出てみると、外部 IP も NAT もないのでタイムアウトします。

gcloud compute ssh lab-vm --zone=$ZONE --tunnel-through-iap \
  --command="curl -sS -m 5 https://example.com -o /dev/null -w '%{http_code}\n'"

Cloud Router と Cloud NAT を作ってから、同じコマンドをもう一度実行します。200 が返れば NAT 経由で出られています。

gcloud compute routers create lab-router --network=lab-vpc --region=$REGION
gcloud compute routers nats create lab-nat --router=lab-router --region=$REGION \
  --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges

作った順の逆に消します。

gcloud compute instances delete lab-vm --zone=$ZONE --quiet
gcloud compute routers nats delete lab-nat --router=lab-router --region=$REGION --quiet
gcloud compute routers delete lab-router --region=$REGION --quiet
gcloud compute firewall-rules delete lab-allow-iap-ssh --quiet
gcloud compute networks subnets delete lab-subnet --region=$REGION --quiet
gcloud compute networks delete lab-vpc --quiet

試験で問われる判断

このカリキュラムで作った例です。

「10 個のプロジェクトのネットワークを中央のチームだけが変更する」なら Shared VPC です。10 個の VPC をピアリングでつなぐ案は、推移しないので全組み合わせの接続が要ります。

「買収した会社の VPC と IP 範囲が重なっている。相手の API 1 つだけを使いたい」なら Private Service Connect です。ピアリングは IP が重なるとつなげず、IP の振り直しは要件に対して大きすぎます。

「北米と欧州のユーザーに 1 つの IP で Web アプリを出し、DDoS から守る」なら、グローバル外部アプリケーションロードバランサに Cloud Armor を付けます。リージョンのロードバランサ 2 つを DNS で振り分ける案は、1 つの IP という要件を満たしません。

「ゲームサーバーが UDP を使い、クライアントの IP を記録する」なら外部パススルーネットワークロードバランサです。アプリケーションロードバランサは UDP を扱えず、プロキシ型は既定では送信元 IP を残しません。