🌐 Deep Dive — Cloud Interconnect / HA VPN / BGP 運用

「物理 + BGP + クラウド」が交わるため、PCNE で最もトラブルが多い領域。月数百万円の専用線が一夜で死ぬ事故、BGP の hidden gotcha、コスト最適化を集約。

🚨 重大事故ケース 10 件

#1 「99.99% SLA Interconnect なのにフル断」 — 1 metro 構成の盲点

状況: Dedicated Interconnect で 4 attachments + 2 Cloud Routers を asia-northeast1 の 1 metro (Tokyo PoP) のみで構成。Tokyo PoP の電源工事で同時 4 attachments 全断。

原因: SLA 99.99% の要件は 2 metros (異なる地理 PoP)。1 metro × 4 attachments では公式 SLA 上 99.9% 扱い。

影響: オンプレ DB ↔ GCP 全断 6 時間、決済処理停止。Google からは SLA credit 発行されるが、ビジネス損失 1 億円超。

復旧: Cloud VPN を緊急構築 (HA VPN) して暫定運用、後日 Osaka metro に 2 attachments 追加。

再発防止:

99.99% は 2 metros / 4 VLAN attachments / 2 Cloud Routers / global routing mode が公式要件
Disaster Recovery として HA VPN を待機構成で常時 stand-by
Google の planned maintenance notification を組織で購読

#2 「BGP セッション flap で経路振動」 — MD5 認証 mismatch + BFD なし

状況: Cloud Router と Onprem Router の BGP セッションが 30 分おきに up/down 繰り返し。flap で route が消えるたびに通信断。

原因: Onprem 側の MTU 1500、GCP 側の MTU 1460 で TCP MD5 認証パケットが fragmentation され、断続的に検証失敗。

影響: アプリケーションの TCP セッション RST 嵐、API success rate 70%。

復旧: MTU を両端 1500 に揃え、IKE/IPsec の MSS clamp を有効化。BFD 有効化で flap 即検出。

再発防止:

BGP セッションには BFD を必須化 (300ms × 3 で 1 秒以内検出)
MTU/MSS は両端統一、HA VPN なら 1460、Interconnect なら 1500 / 8896 で揃える
Cloud Monitoring の router.googleapis.com/bgp/session_up で 5 分以内アラート

#3 「Cloud Router の MED 加算で意図しないリージョンへ traffic」 — Legacy vs Standard mode

状況: 2 リージョン (Tokyo + Osaka) で Interconnect 構成。Onprem からは Tokyo 経由を優先したかったが、Osaka 経由のトラフィックが過半。

原因: Cloud Router の best-path-selection-mode が LEGACY のまま。Legacy では --advertised-route-priority が MED に加算されず、Osaka 側の MED が低くなった (BGP 自動計算)。

影響: Inter-region traffic が大量発生、egress コストが月 $30,000 → $80,000。

復旧: --best-path-selection-mode=STANDARD に変更、route priority が MED に加算され、意図通り Tokyo 経由優先。

再発防止:

Cloud Router は 必ず STANDARD mode で新規作成 (IaC で強制)
Legacy → Standard 移行時は dry-run で route 変化を確認
BGP route 可視化を Network Topology / Looker Studio で行う

#4 「HA VPN の片肺運用で 99.9% SLA 違反」 — Tunnel 構成ミス

状況: HA VPN を構築したが、Onprem 側の VPN GW が 1 interface のみ。GCP 側は 2 interface あるが、4 tunnel mesh ではなく 2 tunnel 直結に。

原因: HA VPN の 99.99% SLA 要件は「2 active tunnels with redundant peer interfaces」。Onprem 側 1 interface だと 1 tunnel down で半減。

影響: Onprem 側 VPN device 単一障害で全断。

復旧: Onprem 側 VPN GW を 2 台にし、4 tunnel mesh (各 GCP interface ↔ 各 Onprem interface) で再構築。

再発防止:

HA VPN は GCP 2 interface × Onprem 2 interface = 4 tunnels を確実に
External VPN Gateway リソースで Onprem 側 redundancy = TWO_IPS_REDUNDANCY を宣言
SLA テスト: 各 tunnel を意図的に shutdown して挙動確認

#5 「Interconnect VLAN attachment の帯域不足で全 traffic drop」 — Burst 設計

状況: 10G Dedicated Interconnect の VLAN attachment 容量を 1G で発注 (コスト最適化)。日次 batch (BigQuery → Onprem) で 1G を瞬間的に超え、tail drop 大量発生。

原因: Cloud Interconnect の VLAN attachment は shaped (hard cap)。physical link 容量に余裕があっても VLAN attachment 容量で head drop される。

影響: Batch ジョブが連続失敗、データ整合性問題。

復旧: VLAN attachment を 5G に増強 (resize)。または batch を rate-limit。

再発防止:

VLAN attachment の interconnect_attachment/network/sent_bytes_count を 5 分単位で監視
Burst を考慮し、平均利用率 60% を上限の目安に
batch は rate_limit with token bucket で平準化

#6 「Onprem 側 BGP の AS-Path prepending が逆効果」 — 経路選択の罠

状況: Onprem A サイト経由を優先したく、B サイトの BGP advertisement に AS-Path prepending を 3 段追加。にもかかわらず B 経由が選ばれる。

原因: Cloud Router は local pref を peer から受け取らない (eBGP)。AS-Path で長くしても、prefix length / MED の順で評価されるため、prepending は best path 選択に直接効かないケースがある。

影響: 意図しない経路で traffic が流れ、SLA違反は出ないが latency 増加。

復旧: Onprem 側で community をマークし、Cloud Router の custom learned routes で priority を上げる。または GCP 側で advertised-route-priority 調整。

再発防止:

BGP best path は longest prefix → Cloud Router priority (Standard mode) → MED → AS-Path の順
経路制御は priority と route map (custom learned) を優先、AS-Path prepending は補助

#7 「MACsec を有効化したら traffic 全断」 — Key rotation の事故

状況: Cloud Interconnect で MACsec を有効化。Onprem 側 device に pre-shared key を投入したが、GCP 側で key が 1 文字違いで設定された。

原因: MACsec key 不一致で物理層 L2 セッションが down。L2 が落ちると BGP も Interconnect も即死。

影響: Interconnect 全断 1 時間、決済 outage。

復旧: Key を再投入。Onprem 側 device の MACsec を一時 disable して traffic を通し、修正後再 enable。

再発防止:

MACsec key は Secret Manager 等で一元管理、コピペミスを撲滅
MACsec の有効化は maintenance window で実施
Cloud Logging で connection_state="down" を 1 分以内アラート

#8 「Cross-Cloud Interconnect の BGP unstable」 — AWS 側 BFD 不対応

状況: Cross-Cloud Interconnect で AWS Direct Connect と接続。GCP 側で BFD を有効化したが、AWS Direct Connect Transit VIF は BFD 対応がベンダーによって異なり、BGP session が unstable に。

原因: AWS Direct Connect の Transit VIF は BFD 設定が必要。一部の DC partner は default で disabled。BFD packet が片方向だけ来て adjacency fail。

影響: AWS ↔ GCP 通信が断続的に切れ、cross-cloud DB replication が遅延。

復旧: AWS 側で BFD を明示有効化。または GCP 側 BFD を一旦 disable して traditional BGP keepalive 運用。

再発防止:

Cross-Cloud Interconnect 構築前に対向クラウドの BFD/BGP 仕様を確認
BGP/BFD 設定の "両端一致" を IaC で管理 (Terraform + AWS Provider)

#9 「Classic VPN を残したまま HA VPN に移行、route 衝突」 — Migration の事故

状況: Classic VPN から HA VPN への移行中、両方の VPN tunnel が同じ prefix を Cloud Router に広告。Cloud Router が ECMP で振り分けたが、Classic VPN tunnel が low capacity で詰まる。

原因: 移行手順で Classic VPN tunnel の advertisement を停止せずに HA VPN を有効化。Cloud Router は両方を等価で扱った。

影響: 半分のリクエストが 1 Gbps Classic tunnel に流れ、packet drop。

復旧: Classic VPN tunnel を即削除、または route priority を下げて HA VPN 優先化。

再発防止:

VPN 移行は route priority で段階的シフト、ECMP に放置しない
Classic VPN は GA だが新規構築非推奨、既存も計画的に HA VPN へ移行

#10 「Cloud Router の BGP route limit 100 を超過」 — Onprem 全 prefix を flat に広告

状況: Onprem の global routing table をそのまま Cloud Router に広告したら、limit (100 dynamic routes per region per Cloud Router) を超え、超過分が drop される。

原因: Cloud Router の dynamic routes は region あたり 100 がデフォルト quota。Onprem の細かい /24 を 200 個広告するとオーバー。

影響: 一部 Onprem subnet が GCP から不到達、原因究明に半日。

復旧: Onprem 側で route aggregation (e.g., 200 個の /24 → 1 個の /16)、または quota 緩和申請。

再発防止:

BGP advertisement は summarizationを Onprem 側で実施
Cloud Router の router.googleapis.com/bgp/route_count を 80% で alert
Quota の事前緩和申請 (Cloud Router 単位で最大 250 まで拡張可)

💰 Interconnect / VPN のコスト構造

Dedicated Interconnect

項目	単価	備考
10G port	$1,700/月/port	2 port 構成 (99.9%) なら $3,400/月
100G port	$10,000/月/port	大規模向け
VLAN attachment	$0.04 - $0.10/hour	capacity (50M-50G) に応じ階段状
Egress (GCP → Onprem)	$0.02/GB	Interconnect 経由は public egress より 75% 安
Ingress	無料	Onprem → GCP は無料
MACsec	無料	機能料金なし

Partner Interconnect

Partner (Equinix, NTT 等) の回線料金 + GCP 側 VLAN attachment 料金。capacity と connectivity tier (L2/L3) で大きく異なる。中規模ユーザは月 $500〜$3,000 程度から。

HA VPN

項目	単価	備考
HA VPN tunnel	$0.05/tunnel/hour ≈ $36/tunnel/月	4 tunnel mesh で月 $144
Egress (VPN 経由)	通常の egress 料金 ($0.08〜$0.23/GB)	VPN は egress 割引なし、Interconnect より高い
IPSec の暗号化処理	無料 (Google 側)	Onprem 側 device の能力に依存

Cross-Cloud Interconnect

10G で $1,700/月程度 + AWS/Azure 側 Direct Connect/ExpressRoute 料金。cross-cloud egress は通常の internet egress より 50% 程度安い。

「Interconnect 高い」と感じる時の見直し順:

VLAN attachment の capacity が過大ではないか (実 traffic の peak が 50% 未満なら downsize)
Egress 料金が支配的なら、データ転送方向の見直し (cache の方向で削れないか)
99.99% SLA が本当に必要か (99.9% への downgrade で port 半減)
Partner Interconnect への切替えで月額削減

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

VLAN attachment over-provisioning

「念のため 10G」が常態化。実 peak は 1G。差額 $0.10/h × 9G × 8760h = $7,884/年のムダ。

対策: interconnect_attachment/bandwidth を 30 日 p95 で観測、20% buffer で resize。

Inter-region egress over Interconnect

1 つの Cloud Router で global routing → 全リージョンの egress が 1 metro 経由。リージョン間の不要 transit。

対策: リージョン毎に Cloud Router/Interconnect を local 接続化 (regional routing mode)。

HA VPN tunnel 増殖

サブ拠点ごとに HA VPN を作って tunnel が 30 本超え。月 $1,080 を超え、Interconnect 検討タイミング。

対策: NCC hub-spoke で集約、または Dedicated Interconnect 移行検討。

Classic VPN 残置

HA VPN 移行が中途半端で Classic VPN tunnel が残存。SLA も低い上に料金は同等。

対策: 移行計画を引き、quarter ごとに 1 拠点ずつ。

Cross-Cloud Interconnect の片肺運用

AWS との接続で片方向の traffic だけが大量、逆方向は皆無。それでも port 料金は対称。

対策: 片方向 large traffic なら Direct Peering の方が安いことも。

BGP route count 増加で Cloud Router 分割不可

Cloud Router を分割しようとして、route table 全体を見直さないとできない状況に。

対策: Onprem 側で route aggregation を維持、Cloud Router は最初から分割設計。

🚀 最適化テクニック 10 選

Standard mode best-path-selection を Cloud Router に必須化、route priority による意図的制御。
BFD 有効化 (300ms × 3 mult) で BGP failover を 1 秒以内に。
NCC hub-spoke で複数拠点接続を集約、運用負荷とコスト両方削減。
HA VPN over Interconnect で compliance 要件を満たしつつ Interconnect 帯域を使い切る。
Custom learned routes で受け入れ route を絞り、Cloud Router の dynamic route quota を温存。
Multiple Cloud Routers でリージョン毎に分割、blast radius を最小化。
Partner Interconnect の L3 接続で BGP を partner に委任、運用簡素化。
Traffic engineering: prepending + MED で active/standby を意図的に。
Capacity planning: traffic の p95 × 1.5 で VLAN attachment サイジング。
Maintenance notification を Org-wide で購読、planned outage に事前対応。

🔔 監視アラート設計

必須アラート 12 件

シグナル	メトリック	閾値
BGP session down	`router.googleapis.com/bgp/session_up`	= 0 for 1m → P1
BGP route count	`router.googleapis.com/bgp/route_count`	> 80% quota
VLAN attachment status	`interconnect_attachment/operational_status`	!= OS_ACTIVE
VLAN attachment bandwidth	`interconnect_attachment/network/sent_bytes_count`	> 80% capacity for 5m
Interconnect link status	`interconnect/link/operational_status`	!= LINK_OPERATIONAL_STATUS_LACTIVE
VPN tunnel established	`vpn.googleapis.com/tunnel_established`	= 0 for 2m
VPN dropped packets	`vpn.googleapis.com/network/dropped_sent_packets_count`	> 100/s for 5m
BFD events	Cloud Logging filter	state=DOWN 検出
MACsec session state	Cloud Logging filter (`jsonPayload.connection_state`)	= DOWN
MTU mismatch (推定)	VPC Flow Logs での ICMP fragmentation needed	急増
Inter-region egress cost	Billing export → BigQuery	前日比 +50%
Maintenance notification	Cloud Logging (PubSub)	受信時即通知

📖 Runbook: 「BGP session down」

1. Cloud Monitoring alert で対象 router/peer を特定 (1 min)
2. Cloud Router の BGP events を Cloud Logging で確認:
   - Authentication failed → MD5 key mismatch
   - Hold timer expired → keepalive 喪失 (peer device 確認)
   - Active connection failed → 物理 down or firewall
3. Onprem 側 device の BGP neighbor 状態を確認 (NOC 連携)
4. Connectivity Tests で Cloud Router IP ↔ peer link-local IP の到達性
5. VLAN attachment status / Interconnect link status を確認
6. 短期対処:
   - 代替経路 (HA VPN backup) に traffic shift
   - 影響時間が長引くなら、HA VPN を緊急構築
7. 復旧後の確認:
   - route_count が事前と一致しているか
   - Inter-region traffic が想定通りか
8. Post-mortem: BFD/BGP timer 設定の見直し、IaC reflect