VPC ネットワーキングの基礎

第 2 章で「誰が何をできるか」を設計しました。この章では「どこからどこへ通信できるか」を設計します。Google Cloud のネットワークはオンプレミスの常識と少し違う形をしており、その違い — VPC がグローバルであること — こそが設計の武器になります。まず構造を頭に入れ、後半のハンズオンで実際にネットワークを組み立てて壊します。

VPC ネットワークとサブネット — グローバル × リージョナルの二層構造

VPC（Virtual Private Cloud）ネットワークは、プロジェクト内に作る仮想ネットワークです。最重要の事実はスコープの二層構造です。

• VPC ネットワークはグローバルリソース。関連するルートとファイアウォールルールもグローバルで、特定のリージョンやゾーンには属しません
• サブネットはリージョンリソース。IP アドレス範囲はサブネット、つまりリージョン単位で定義します

代表的な他クラウドでは VPC 相当のネットワークをリージョンごとに作る設計が一般的なので、ここは発想の切り替えが必要です。Google Cloud では 1 つの VPC が世界中のリージョンをまたぎ、東京の VM とアイオワの VM が同じネットワークの内部 IP で直接通信できます。リージョン間 VPN もピアリングも不要です。

auto モードと custom モード

VPC ネットワークにはサブネットの作られ方が異なる 2 つのモードがあります。新規プロジェクトに最初から存在する default ネットワークは、IPv4 ファイアウォールルールが事前設定された auto モード VPC です。

auto モードの範囲はどのプロジェクトでも同一なので、将来 VPC 同士をつないだり（第 12 章）オンプレミスと接続したりすると IP 範囲の重複が起きやすくなります。変換は --switch-to-custom-subnet-mode による一方通行で、custom から auto には戻せません。本番ネットワークは最初から custom モードで設計するのが定石です。

IP アドレス設計 — プライマリ範囲・セカンダリ範囲・予約アドレス

サブネットは必須のプライマリ IPv4 範囲と、任意のセカンダリ IPv4 範囲を持ちます。設計時に押さえるルールは次のとおりです。

• プライマリ範囲の先頭 2 つ（ネットワークアドレスとゲートウェイ）と末尾 2 つ（将来予約とブロードキャスト）、計 4 アドレスは予約されていて VM に使えません。たとえば 10.0.1.0/24 なら VM に割り当てられるのは 252 個です
• 範囲の最小サイズは IPv4 アドレス 8 個分（/29）。使える範囲は RFC 1918（10.0.0.0/8 など）のほか RFC 6598（100.64.0.0/10）等のプライベートでない範囲も含みます。リンクローカル 169.254.0.0/16 やマルチキャストは使えません
• プライマリ範囲は後から拡張はできるが縮小はできません（expand-ip-range）。最初は小さめに切るのが安全です
• セカンダリ範囲はエイリアス IP 範囲専用です。1 つの VM（の NIC）に追加の IP 範囲を持たせる仕組みで、代表例は 第 6 章の GKE が Pod に割り当てるアドレスです。セカンダリ範囲には予約アドレスがなく全アドレスを使えます

なお VPC ネットワークには MTU 設定があり、既定は 1460 バイト（1300〜8896 の範囲で指定可能）です。ここを変えるのはハイブリッド接続や高性能通信の設計時なので、いまは既定のままで構いません。

ファイアウォールルール — 暗黙の拒否から設計する

VPC ファイアウォールルールは VPC ネットワークに属するグローバルリソースで、VM 単位ではなくネットワーク単位で通信を制御します。特性は次の 4 点です。

• ステートフル — 許可された接続の戻りトラフィックは自動的に許可される
• 方向は片方向 — 1 つのルールは ingress（着信）か egress（発信）のどちらかにだけ適用される
• アクションは allow か deny の二択
• 優先度は 0〜65535（既定 1000）。番号が小さいほど優先され、一致した最も高優先のルールだけが適用される

この暗黙のアクション（ingress は拒否、egress は許可）が設計の出発点です。自分で作った VPC には最初ルールが 1 つもないため、SSH も ping も一切届きません。「まず全部閉じている。必要な穴だけ開ける」が Google Cloud の既定姿勢です。

ターゲット — 誰にルールを適用するか

ルールの適用先（ターゲット）は 3 通りです: ネットワーク内の全インスタンス（既定）、ターゲットタグ（--target-tags）、ターゲットサービスアカウント（--target-service-accounts）。ingress の送信元も IP 範囲のほかタグ・サービスアカウントで指定できます。ただしタグとサービスアカウントを同一ルール内で混在させることはできません。

使い分けの軸は「誰がその属性を変えられるか」です。ネットワークタグはインスタンスを編集できる人なら誰でも付け外しできる任意の文字列ですが、サービスアカウントは 第 2 章で学んだ IAM で保護されたアイデンティティです。セキュリティ境界として使うならサービスアカウントターゲットが堅牢です。

default ネットワークの事前設定ルール

default ネットワークには次の ingress 許可ルールが事前設定されています（削除・変更は可能）。

SSH と RDP が全世界（0.0.0.0/0）に開いている点に注目してください。学習には便利ですが、本番でこのまま使うべきではありません。なお、ファイアウォールルールとは無関係に VM とメタデータサーバー 169.254.169.254 の通信は常に許可されます（内部 DNS や起動時の鍵配布がここを通ります）。

ルート・内部 DNS・外への出口 — Cloud NAT と Private Google Access

ルート — パケットの行き先はどう決まるか

VPC のルートもグローバルリソースです。ルートには大きくシステム生成ルートとカスタムルートがあります。

• サブネットルート（システム生成) — サブネットの IP 範囲宛の経路。サブネットのライフサイクルに合わせて Google Cloud が自動作成・削除し、宛先がサブネットルートと一致する、またはその内側に収まる（より具体的な）カスタム静的ルートは作れません
• デフォルトルート（システム生成） — 宛先 0.0.0.0/0、ネクストホップ default-internet-gateway。より特定的なルートに一致しないパケットの最後の受け皿で、インターネットへの出口と Google API へのアクセスがここに依存します。削除・置換は可能ですが影響が大きい操作です
• カスタム静的ルート — 手動作成。ネクストホップには VM インスタンス、内部パススルー Network Load Balancer、Classic VPN トンネル、default-internet-gateway などを指定できます
• カスタム動的ルート — Cloud Router が BGP で学習して自動管理する経路（第 12 章）。VPC の動的ルーティングモード（regional / global）で適用範囲が変わります

ルート選択は最長プレフィックスマッチが原則です。宛先 IP に最も長く（具体的に）一致するルートが勝ち、同じ長さならルートの種類と優先度で決まります。

なお、ロードバランサのヘルスチェックや IAP のトラフィックには、上記のルートとは別の専用の戻り経路（special return paths）が Google 側のネットワークに用意されています。これらは VPC のルートテーブルには現れず、削除も上書きもできません。IAP の範囲 35.235.240.0/20 は後のハンズオンでファイアウォールの送信元として登場します。

内部 DNS — VM は名前で呼び合える

同じ VPC 内の VM は、内部 DNS 名で解決できます。現在の既定であり推奨でもあるゾーン DNS の形式は VM_NAME.ZONE.c.PROJECT_ID.internal です（障害の影響をゾーン単位に閉じ込められるため、グローバル DNS 形式 VM_NAME.c.PROJECT_ID.internal より強く推奨されています）。名前解決を担うのはメタデータサーバー 169.254.169.254 で、各 VM の DNS リゾルバとして構成されます。解決できるのは同一 VPC ネットワーク内からのみです。

外部 IP を持たない VM の出口 — Cloud NAT と Private Google Access

セキュリティ設計の基本は「VM に外部 IP を付けない」ことです。しかし外部 IP がないと、OS パッケージの更新も Google API の呼び出しもできません。この問題への答えが宛先別に 2 つ用意されています。

Cloud NAT は、外部 IPv4 アドレスを持たないリソースにインターネットへのアウトバウンドを提供するマネージドサービスです。プロキシ VM を立てる方式ではなく、VPC を支える Andromeda ソフトウェアに NAT を組み込む分散実装なので、単一障害点や帯域ボトルネックになりません。制御プレーンとして Cloud Router を使い（NAT 自体はリージョンリソース）、Compute Engine VM のほか GKE、Cloud Run、Cloud Run functions からも利用できます。ポートは既定で静的割り当て（VM あたり 64 ポート）、動的ポート割り当てを有効にすると 32 ポートから需要に応じて倍々に増えます。NAT 用外部 IP 1 つで TCP・UDP 各 64,512 の送信元ポートを提供でき、ポートが尽きるとパケットはドロップされます（2026-08 時点）。

Private Google Access（PGA）は、外部 IP を持たない VM が Cloud Storage や BigQuery などの Google API・サービスの外部 IP アドレスへ、Google の網内経路で到達できるようにするサブネット単位の設定です。外部 IP を持つ VM には効果がありません（設定と無関係にアクセス可能）。既定ではデフォルトルート経由で API の公開 IP に届きますが、より厳密に制御したい場合は private.googleapis.com（199.36.153.8/30）や VPC Service Controls 対応の restricted.googleapis.com（199.36.153.4/30）という専用ドメイン + 専用 IP 範囲に DNS を向ける構成が取れます（第 13 章）。

ハンズオン

第 1 章で作った学習用プロジェクトと Cloud Shell を使います（ローカルの gcloud CLI でも同じです）。3 本は連続しており、3-1 で作るネットワークを 3-3 まで使い回します。現在のプロジェクトは gcloud config get-value project で確認してください。

gcloud compute networks create handson-vpc --subnet-mode=custom

gcloud compute networks subnets create subnet-tokyo \
    --network=handson-vpc \
    --region=asia-northeast1 \
    --range=10.0.1.0/24 \
    --secondary-range=pods=10.4.0.0/20 \
    --enable-private-ip-google-access

gcloud compute networks subnets expand-ip-range subnet-tokyo \
    --region=asia-northeast1 \
    --prefix-length=23

gcloud compute networks subnets describe subnet-tokyo \
    --region=asia-northeast1 \
    --format="text(ipCidrRange, secondaryIpRanges, privateIpGoogleAccess)"

gcloud compute networks subnets delete subnet-tokyo --region=asia-northeast1 --quiet
gcloud compute networks delete handson-vpc --quiet

gcloud compute firewall-rules create handson-allow-internal \
    --network=handson-vpc --direction=INGRESS --action=ALLOW \
    --rules=tcp,udp,icmp --source-ranges=10.0.0.0/23

gcloud compute firewall-rules create handson-allow-ssh-iap \
    --network=handson-vpc --direction=INGRESS --action=ALLOW \
    --rules=tcp:22 --source-ranges=35.235.240.0/20 \
    --target-tags=ssh-via-iap

gcloud compute firewall-rules create handson-quarantine-deny-ssh \
    --network=handson-vpc --direction=INGRESS --action=DENY \
    --rules=tcp:22 --priority=900 --source-ranges=0.0.0.0/0 \
    --target-tags=quarantine

gcloud compute firewall-rules list \
    --filter="network=handson-vpc" --sort-by=priority

NAME                         NETWORK      DIRECTION  PRIORITY  ALLOW         DENY
handson-quarantine-deny-ssh  handson-vpc  INGRESS    900                     tcp:22
handson-allow-internal       handson-vpc  INGRESS    1000      tcp,udp,icmp
handson-allow-ssh-iap        handson-vpc  INGRESS    1000      tcp:22

gcloud compute firewall-rules delete handson-allow-internal \
    handson-allow-ssh-iap handson-quarantine-deny-ssh --quiet

gcloud compute instances create nat-test \
    --zone=asia-northeast1-b \
    --machine-type=e2-micro \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=handson-vpc \
    --subnet=subnet-tokyo \
    --tags=ssh-via-iap \
    --no-address

gcloud compute ssh nat-test --zone=asia-northeast1-b --tunnel-through-iap \
    --command="curl -s -o /dev/null -w 'google-api: %{http_code}\n' -m 10 https://storage.googleapis.com; curl -s -o /dev/null -w 'internet: %{http_code}\n' -m 10 https://example.com"

gcloud compute routers create handson-router \
    --network=handson-vpc --region=asia-northeast1

gcloud compute routers nats create handson-nat \
    --router=handson-router --region=asia-northeast1 \
    --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges

gcloud compute ssh nat-test --zone=asia-northeast1-b --tunnel-through-iap \
    --command="curl -s -o /dev/null -w 'internet: %{http_code}\n' -m 10 https://example.com"

gcloud compute routers nats delete handson-nat \
    --router=handson-router --region=asia-northeast1 --quiet
gcloud compute routers delete handson-router --region=asia-northeast1 --quiet
gcloud compute instances delete nat-test --zone=asia-northeast1-b --quiet
gcloud compute firewall-rules delete handson-allow-internal \
    handson-allow-ssh-iap handson-quarantine-deny-ssh --quiet
gcloud compute networks subnets delete subnet-tokyo --region=asia-northeast1 --quiet
gcloud compute networks delete handson-vpc --quiet

gcloud compute networks list

つまずきポイント

理解度チェック

まとめと次章へ

• VPC ネットワーク・ルート・ファイアウォールルールはグローバル、サブネットはリージョナル。この二層構造が Google Cloud ネットワークの土台
• 本番は custom モード。IP 設計では予約 4 アドレス・拡張のみ可・セカンダリ範囲（エイリアス IP 用）を押さえる
• ファイアウォールは「暗黙の deny ingress / allow egress」から出発し、優先度（小さいほど強い）とターゲット（タグ / サービスアカウント）で穴を設計する
• ルートは最長プレフィックスマッチ。サブネットルートが内部を、デフォルトルート 0.0.0.0/0 が外部への出口を受け持つ
• 外部 IP なし VM の出口は宛先で使い分け: インターネット = Cloud NAT、Google API = Private Google Access

ネットワークという土台ができたので、第 4 章ではその上で動かす Compute Engine — マシンタイプの選定からマネージドインスタンスグループまで — を学びます。ここで作った「外部 IP なし + IAP SSH」の構成は、以降の章でも VM を作るたびの既定形として使います。

• VPC ネットワークの概要 / サブネット
• VPC ファイアウォール ルール / ファイアウォール ルールの評価順序
• ルート / 内部 DNS
• Cloud NAT の概要 / Private Google Access