🧱 Deep Dive — VPC / Routing / NCC / PSC 運用

「気付かないうちに壊れる」VPC 系のトラップを集約。IPAM, Peering, NCC transitivity, PSC のオペレーショナルな罠を中心に。

🚨 重大事故ケース 10 件

#1 「Shared VPC subnet を削除しようとして本番停止」 — Service projects の VM が消滅

状況: Host project 管理者が「使われていないように見える」subnet を削除しようとした。実際は Service project の 200 個の VM がその subnet を使用中。コマンドはエラーで止まったが、復旧調査中 3 時間停滞。

原因: Shared VPC では subnet 削除前に service project の利用状況を確認する仕組みが弱い。gcloud compute networks subnets list-usable でも全 service project は見えない。

影響: 直接の outage はなかったが、削除コマンドを kick した時の影響評価で 3 時間ロス、ユーザコミュニケーション混乱。

復旧: 削除を中止。Asset Inventory で全 VM/GKE node の subnet 利用を網羅調査。

再発防止:

Subnet 削除前は Asset Inventory で全 service project を横断調査
Subnet を 論理削除フラグ (tag) でマーク → 30 日 quiescence → 物理削除
削除作業は IaC で PR レビュー必須化

#2 「VPC Peering の transitive 不可で 3rd party SaaS 不到達」 — PSA + Peering の罠

状況: VPC-A ↔ VPC-B (Peering), VPC-A ↔ Cloud SQL (PSA 経由で内部 Peering)。VPC-B から Cloud SQL に接続できない。

原因: PSA は VPC Peering を裏側で自動構築するが、VPC-A ↔ Cloud SQL の Peering は VPC-B からは transitive 不可。

影響: マイクロサービス間で DB 共有ができず、設計やり直し。

復旧: VPC-B から Cloud SQL への直接 PSA、または PSC for Cloud SQL に切替え (PSC は VPC-B → endpoint で透過接続)。

再発防止:

VPC Peering / PSA 依存設計は将来の transitive 要件で苦しむ → PSC を第一選択に
NCC で集約する場合は Producer spoke を使い PSC を propagation

#3 「Subnet expand で隣の subnet と重複」 — CIDR 計画の事故

状況: 10.10.0.0/20 を /19 に拡張しようとしたが、隣の subnet が 10.10.16.0/20。10.10.16.0-31 が重複し expand コマンドが失敗。

原因: Subnet expand は隣接 CIDR と衝突しない範囲でのみ可能。事前計画なしで /20 を割り当てた結果。

影響: 緊急で Pod range 不足、新規ノード起動できず。

復旧: 新規 subnet (別 CIDR) を作り、新ノード起動。古い subnet は段階的に退去。

再発防止:

IPAM 計画で subnet 間に "growth gap" を意図的に確保
初期割当は 必要量の 2倍を目安に
IP 割当を Spreadsheet/Confluence で記録、IaC で source-of-truth に

#4 「NCC mesh hub に追加した spoke で全 spoke が unstable」 — IP/CIDR フィルタ忘れ

状況: 既存 5 VPC spoke が mesh で接続済み。新 spoke を追加したら、新 spoke の subnet が他 spoke の CIDR と部分重複していて、NCC 内の route 計算が壊れた。

原因: NCC は spoke 同士の CIDR 衝突を防いでくれない。include/exclude フィルタを設定しないと best-effort で混乱。

影響: 全 spoke で random な通信断、復旧に 4 時間。

復旧: 新 spoke を hub から detach。subnet を別 CIDR に切替えて再 attach、include-export-ranges を厳密に。

再発防止:

NCC への spoke 追加前に CIDR 衝突を 必ず確認 (Network Analyzer)
include-export-ranges / exclude-export-ranges を IaC で定義
Pre-prod の NCC hub で先に検証

#5 「Private NAT による重複 IP 解決後、SrcIP ログが NAT IP に」 — Audit ログの混乱

状況: 重複 CIDR の VPC を NCC + Private NAT で接続。アプリケーション側ログでは送信元 IP が全て 100.64.x.x (Private NAT range) になり、誰がアクセスしたか分からない。

原因: Private NAT は SNAT のため、Source IP が NAT IP に書き換わる。アプリログだけでは元 IP 不明。

影響: Compliance audit で「アクセス元特定不可」と指摘。

復旧: Cloud Logging で NAT translation logs を有効化、original/translated IP を join 分析。

再発防止:

Private NAT 採用時は NAT logs を必須有効化 + BigQuery export
アプリ側は X-Forwarded-For ヘッダで識別 (LB 経由なら)
IP 重複は本来避けたい、組織横断 IPAM で予防

#6 「Policy-based Routing (PBR) で intended でない方向へ traffic」 — Priority 設計ミス

状況: 「特定 source からの egress だけ NVA 経由」を PBR で実装。検証では動いたが本番で global 影響、NVA が CPU 100% でクラッシュ。

原因: PBR の priority 設定が緩く、想定外の traffic にも match。NVA は当該 traffic 量を見越していなかった。

影響: NVA outage で全 egress 不可、サービス全断 30 分。

復旧: PBR を一時無効化、default route に戻す。NVA を再起動 + scale out。

再発防止:

PBR の match 条件は 狭く厳密に、source CIDR + protocol + port まで指定
NVA を multi-NIC + ILB next-hop で HA 化
PBR 投入前に Connectivity Tests で全パターン検証

#7 「Cloud DNS Private Zone が VPC Peering 越しに見えない」 — DNS Peering の理解不足

状況: VPC-A に Cloud DNS Private Zone internal.example.com を作成。VPC-B から Peering 経由で名前解決を試みても NXDOMAIN。

原因: VPC Peering は Cloud DNS Private Zone を共有しない。DNS Peering を別途張る必要がある。

影響: マイクロサービス間の名前解決失敗で全断。

復旧: VPC-B 側で DNS Peering Zone を作成、target を VPC-A の Private Zone に。

再発防止:

VPC Peering + 名前解決要件があれば DNS Peering Zone を必ずペア構築
Cross-project binding でも代替可能
IaC で「Peering と DNS Peering をセットで作る」モジュール化

#8 「Auto-mode VPC のまま大規模化、Custom-mode に移行不可」 — リファクタリング不能

状況: PoC で auto-mode VPC を採用、そのまま本番化。後で Custom-mode に変えたいが「VPC mode 変更不可」で詰む。

原因: Auto-mode → Custom-mode 変換コマンドが GCP 公式にあるが、auto-mode で割り当てた subnet (10.128.0.0/9) は維持される。それ以外は触れない。

影響: CIDR が変えられず、ハイブリッド接続で Onprem CIDR と衝突。

復旧: 新 VPC を Custom-mode で作成、データ移行 (Live migration 不可なので blue/green)。

再発防止:

本番 VPC は 必ず Custom-mode
Org Policy compute.skipDefaultNetworkCreation=true で default VPC を作らせない
VPC 作成は IaC でテンプレ化、auto-mode を選択肢から外す

#9 「PSC endpoint が大量に作られ Quota 枯渇」 — マネージドサービス爆増

状況: 各 environment (prod/stg/dev) で個別に PSC endpoint を作成、500 個に達して quota 上限。新規プロジェクト作れず。

原因: PSC endpoint は 1 endpoint = 1 IP + 1 forwarding rule。蓄積するとリソース上限に。

影響: 新規開発が止まる、緊急 quota 申請。

復旧: 不要 endpoint を整理 (300 → 50)、quota 緩和申請。

再発防止:

PSC は environment 共通基盤として集約 (Shared VPC + 1 endpoint で全 service project 共有)
NCC Producer spoke で複数 VPC に endpoint propagation
Tag による owner 管理 + 月次 GC

#10 「VPC Network Peering の暗黙ルートが Internet 不通の原因」 — default-internet-gateway の盲点

状況: VPC-A (egress を NVA 経由) と VPC-B を Peering。VPC-B の VM から外部 API への通信が VPC-A 経由になり遅延。

原因: Peering は subnet route を相互広告するが、default route は Peer に伝搬しない (custom routes として明示すれば伝搬可)。だが Peering 越しでも next-hop は VPC-A 内のリソースを指せる。設計次第。

影響: 意図しない経路で latency 増。

復旧: VPC-B にも独自 egress (Cloud NAT) を構成、Peering 越しの egress を遮断。

再発防止:

VPC Peering の --export-custom-routes / --import-custom-routes を慎重に設定
egress 経路は VPC 毎に独立確保が原則

💰 VPC / NCC / PSC のコスト構造

項目	単価	備考
VPC, Subnet, Route	無料	リソース存在は課金されない
VPC Peering	無料 (リソース)	traffic は通常 egress 料金
VPC Network Peering egress (intra-region)	無料 (同 zone) / $0.01/GB (異 zone)	同 region 内の Peering 越しもゾーン跨ぎで課金
VPC Network Peering egress (cross-region)	$0.02 - $0.08/GB	region 間 traffic は cross-region egress 扱い
NCC Hub	無料
NCC VPC spoke	無料
NCC Hybrid spoke (VPN/VLAN attachment)	$0.0008/hour	spoke 1個で月 ~$0.6
NCC Router Appliance spoke	$0.0008/hour
NCC Site-to-site data transfer	$0.04 - $0.10/GB	NCC 経由の cross-region traffic 別途
PSC Endpoint (consumer)	$0.01/hour (forwarding rule)	月 ~$7 / endpoint
PSC Producer published service	$0.01/hour
PSC data processing	$0.01/GB	PSC を通る traffic
Cloud NAT	$0.045/hour/gw + $0.045/GB	VM 数で割ると安いが、idle でも timer 課金
Cloud DNS public zone	$0.20/月/zone + $0.40/M query	クエリ量が支配的になることも

📈 コスト肥大化パターン 6 種

NCC Hybrid spoke 増殖

各拠点で別々に spoke 化、20 個 = 月 $12。少額に見えるが、運用負荷が高い。

PSC endpoint の野良増加

同じマネージドサービスへの endpoint が複数プロジェクトで重複作成。集約化で 70% 削減可能。

Cloud NAT の per-gw timer 課金

使われていない region に Cloud NAT が残存。1 GW = 月 $33 × 10 region = $330 を払い続ける。

VPC 越し cross-region egress

Peering 越しに cross-region で大量転送。$0.08/GB は隠れ高コスト。

Cloud DNS query 過剰

キャッシュなしクライアントで毎秒 1000 query × 30 日 = 月 26 億 query = $1,040。

NCC site-to-site data transfer 見落とし

NCC 経由の cross-region は別料金。AWS で言う Transit Gateway data charge と同じ罠。

🚀 最適化テクニック 10 選

Shared VPC で集約: マルチプロジェクトで個別 VPC は避け、host project に集中。
NCC でハイブリッドを統合: 拠点毎の VPN/VLAN を hub-spoke に集約、運用負荷 -70%。
PSC for Google APIs: googleapis.com を private IP で叩き、egress を節約 + セキュリティ。
Cloud DNS resolver cache: クライアント側 resolver で TTL を活用、query コスト削減。
Cloud NAT の region 集約: 不要 region の NAT を削除、必要なリージョンだけ。
Subnet expand を計画: 隣接 CIDR と growth gap を確保。
Custom-mode VPC のみ: Auto-mode 禁止 Org Policy。
Network Analyzer の継続観察: unused resources, suboptimal を月次レビュー。
VPC firewall rules → Cloud NGFW policy 移行: 管理性向上 + IAM 制御。
Asset Inventory + Cloud Asset Org Policy: 横断 IPAM の source-of-truth 化。

🔔 監視アラート設計

シグナル	メトリック	閾値
VPC route count	resource quota	> 80% quota
Subnet IP 使用率	VPC Flow Logs から導出	> 85%
Cloud NAT port usage	`nat.googleapis.com/nat/port_usage`	> 75%
Cloud NAT dropped packets	`nat.googleapis.com/nat/dropped_sent_packets_count`	> 100/s for 5m
NCC spoke state	Cloud Logging filter	state=DOWN
PSC endpoint reject	Connectivity Tests on schedule	失敗時
Cloud DNS query rate	`dns.googleapis.com/query/response_count`	前日比 +200%
VPC Peering state	Asset Inventory	state != ACTIVE
Network Analyzer findings	API findings	新規 finding
Inter-region egress cost	Billing export	前日比 +50%

📖 Runbook: 「VM 間で通信不可」

1. Connectivity Tests で src→dst の経路と blocker を即診断 (3 min)
2. 出力されたリソース (firewall, route, peering) を特定
3. Type 別対処:
   - Firewall blocked → Cloud NGFW policy / VPC firewall rule 確認
   - Route missing → VPC route, subnet route, BGP learned route を確認
   - Peering inactive → state, IAM, transitive 制約
   - PSC endpoint reject → IAM, allowed projects 確認
4. Cloud Logging で firewall_rule_logs / packet_mirroring / vpc_flow_logs 突合
5. Network Analyzer の findings をクロスチェック
6. 復旧後: IaC reflect, 同種事故の予防アラート追加