Section 1 — VPC 設計と計画

出題比率 ~21%。Section 1+2 で約 41% を占める「中核ドメイン」。

VPC の基本特性 — 他クラウドとの違い

🅖 Google Cloud VPC

  • Network = Global
  • Subnet = Regional
  • 暗黙ルートで subnet 間疎通
  • Internet GW は暗黙
  • alias IP / secondary range

🅐 AWS VPC

  • VPC = Regional
  • Subnet = AZ 単位
  • Route Table で明示制御
  • Internet GW を attach
  • ENI/ENA

🅐 Azure VNet

  • VNet = Regional
  • Subnet = Regional
  • Route Table を明示
  • NSG (Security Group)
  • Public IP リソース
暗記必須: GCP の VPC は global, subnet は regional。

VPC モードの選択

プロジェクト作成時に自動生成。default-allow-internal/icmp/ssh/rdp が暗黙。本番では非推奨、PoC のみ。

全リージョンに /20 subnet が自動作成 (10.128.0.0/9 範囲)。設計自由度が低く本番非推奨。

subnet を手動定義。本番標準。CIDR を自由に管理でき、Shared VPC や Interconnect 設計に必須。

gcloud compute networks create prod-vpc \
  --subnet-mode=custom \
  --bgp-routing-mode=global

Shared VPC のアーキテクチャ

Host Project Shared VPC (prod-vpc) subnet-a / subnet-b (共有) Cloud Router / FW / DNS をここで集中管理 Service Project A GKE / GCE / Cloud Run Service Project B Cloud SQL / VMs Service Project C Workloads
IAM ロール付与先用途
compute.xpnAdminOrg/FolderShared VPC の有効化と Project attach
compute.networkAdminHost projectVPC/Subnet/Route の管理
compute.networkUserSubnet levelService project が subnet を使う
頻出ミス: project-level に networkUser を付与すると全 subnet 使えてしまう。subnet-level が原則。

VPC Peering vs NCC

VPC Network Peering

  • 2 VPC 間 1対1
  • Transitive 不可
  • 重複 CIDR 不可
  • Cloud DNS 非共有
  • PUPI は --*-public-ip フラグで明示

Network Connectivity Center

  • hub-spoke で多数 VPC を集約
  • Transitive 可能
  • Hybrid spoke (VPN/VLAN/RA) を統合
  • Producer spoke で PSC propagation
  • mesh / star、IP/CIDR フィルタ
判断基準: VPC が 3 つ以上、もしくは ハイブリッド統合が必要なら NCC。

IPAM 戦略

IP タイプ例用途
RFC191810.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16標準
Non-RFC1918100.64.0.0/10RFC1918 枯渇時
BYOIP持ち込みパブリック IPExternal 用、IP 固定
PUPI1.2.3.0/24 を private 利用パブリック IP を内部利用
Private NATRFC6598VPC 間の重複 IP 解決
覚え方: 重複 IP 問題は Private NAT で吸収できる (NCC 経由)。

GKE 設計の要点

VPC-native (alias IP) 必須

route-based は legacy。primary range = Node、secondary #1 = Pod、secondary #2 = Service。

Pod range は大きく

per-node 110 Pod を予約する前提で /16〜/14 推奨。不足したら Additional Pod range 追加。

DNS-based endpoint

Control plane への公開 IP 不要、IAM 認証で kubectl 可能 (最新推奨)。

Dataplane V2

eBPF 基盤、Network Policy 強化、FQDN policy 対応。無効化不可。

確認問題

Q. マルチプロジェクトで NW チームが集中管理、開発チームが個別プロジェクトでワークロードを動かす。最適は?

C。 Shared VPC は GCP の集中管理の鉄板。subnet level の networkUser がベストプラクティス。