コンテンツにスキップ

📚 GCP PCA 学習: 2026-04-30

セクション: 2.1 ネットワークトポロジーの設定 前回からの繋がり: マイグレーション計画で検討した「ネットワーク接続方式」を、実装レベルで設定する段階。VPC・Interconnect・VPN の選択が実務を左右する。

① 一言サマリー

「ネットワークトポロジーの設定とは、GCP リソースと社内 DC・複数リージョン間の通信を、セキュリティと性能を両立させて構築することです。」

② たとえ話

イメージ：部屋同士を繋ぐ配線工事

  • VPC = 一つの部屋を仕切る壁。その部屋内で自由に通信（ファイアウォール開放）
  • サブネット = 部屋をさらに小部屋に分割。グループごとに異なるセキュリティ規則を適用
  • ルーティング = 「別の部屋へ行くには、この廊下を通りなさい」という配線図
  • Cloud VPN = 鍵をかけた細い通路で遠方の拠点と接続（遅延あり、セキュア）
  • Cloud Interconnect = 太い直結パイプで専用接続（高速、遅延小、コスト高）
  • Cloud NAT = 部屋の中では内線で通話、外に出る時だけ公開番号に変換して発信

この「配線設計」を誤ると、通信が遅い、外部から侵入されるといった問題が発生します。

③ 図解

ネットワークトポロジー全体図

graph LR
    subgraph OnPrem["オンプレミス / DC"]
        DC["データセンター
192.168.0.0/16"]
    end

    subgraph GCP1["GCP リージョン1
us-central1"]
        VPC1["VPC: prod-vpc
10.0.0.0/16"]
        Subnet1["Subnet
10.0.1.0/24"]
        VM1["Compute Engine
内部IP: 10.0.1.10"]
    end

    subgraph GCP2["GCP リージョン2
europe-west1"]
        VPC2["VPC: prod-vpc
10.1.0.0/16"]
        Subnet2["Subnet
10.1.1.0/24"]
        VM2["Compute Engine
内部IP: 10.1.1.10"]
    end

    Internet["インターネット"]

    DC -->|Cloud Interconnect
100 Mbps+| VPC1
    DC -->|Cloud VPN
バックアップ| VPC1
    VPC1 -->|VPC Peering| VPC2
    VPC1 -->|Cloud NAT| Internet
    VM1 -->|Cloud CDN| Internet

VPC トポロジー選択マトリクス

graph LR
    A["ネットワーク管理
責任体制は？"]

    B["一つのチーム
集中管理"]
    C["複数チーム
分散管理"]
    D["異なる
組織"]

    B -->|非常に単純| E["単一 VPC
複数 Subnet"]
    C -->|同一 GCP Project
内の分割] --> F["共有 VPC
Host Project"]
    D -->|別 Project| G["VPC Peering"]

    A --> B
    A --> C
    A --> D

接続方式の速度・遅延・コスト比較

graph LR
    A["接続要件"] --> B{"DL 検証
アクティブ
共存"}

    B -->|不要
低遅延| C["Cloud Interconnect
VLAN × 複数
遅延: <1ms
コスト: 月4万円"]
    B -->|必要
高セキュア| D["Cloud VPN
IPSec 暗号化
遅延: 10-50ms
コスト: 月5,000円"]
    B -->|教育用
低コスト| E["HTTP/HTTPS
API 経由
遅延: 100ms
コスト: トラフィック課金"]

④ 仕組みの深掘り

4.1 VPC とサブネットの構造

VPC（Virtual Private Cloud） は： - IP アドレス空間を定義するコンテナ - 例：10.0.0.0/16 を宣言すると、VPC 内のすべてのリソースがこの範囲内の IP を持つ - 複数 VPC は独立し、通信するには Peering か VPN が必要

  • ファイアウォールルール（FW）は VPC 単位で適用される
  • VPC A のリソースと VPC B のリソースが Peering で繋がっていても、FW で遮断すれば通信できない
  • つまり「ネットワーク接続」と「通信許可」は独立した概念

サブネット（Subnet） は： - VPC 内の IP レンジをさらに分割したもの - VPC 10.0.0.0/16 を 4 つのサブネット（10.0.1.0/24, 10.0.2.0/24, ...）に分割 - リージョンごとに 1 つ以上のサブネットが必須 - 同じ VPC 内のサブネット間は「ルーティングテーブル不要」で自動的に接続

  • GKE・Cloud Run など、マネージドサービスはサブネットを「自動予約」する可能性がある
  • IP アドレスが枯渇したら、GKE クラスタの Pod が起動できない
  • PCA 試験では「IP アドレス計画」は出題ホットスポット

4.2 ルーティングの実体

ルーティング（経路制御） は、VPC 内で定義される： - ローカルルート（自動）: 同一 VPC 内のサブネット間は直結 - 10.0.1.0/24 のリソース → 10.0.2.0/24 のリソース = ローカルルートで転送

  • カスタムルート（手動）: VPC 外へのトラフィック経路を明示
  • 例：0.0.0.0/0 → Cloud NAT → インターネット
  • 例：192.168.0.0/16 → VPN Gateway → オンプレ DC

ルーティングの優先度： 1. ローカルルート（常に最優先） 2. より詳細なプレフィックス（例：192.168.1.0/24 が 192.168.0.0/16 より優先） 3. 同じプレフィックスの複数ルート → 負荷分散

4.3 Cloud Interconnect の実装

Dedicated Interconnect： - GCP と DC を VLAN で直結 - VLAN 複数本でレイアウル冗長化（例：LON1 と LON2 から 2 本） - SLA 99.99% を実現

  • セットアップ は 1-3 ヶ月かかる（Google のハードウェア配置・ケーブル工事）

  • BGP（動的ルーティングプロトコル） で経路自動交換

  • DC 側でルートアドバタイズ → GCP 側が自動受信

Partner Interconnect： - GCP と DC を「通信キャリアの提携パートナー」経由で接続 - セットアップが早い（数週間） - 遅延は Dedicated より大きい（1-5ms） - コストは Dedicated より安い（月 1-2 万円）

4.4 Cloud VPN の実装

IPSec トンネル でオンプレ ↔ GCP 間を暗号化： - 遅延 10-50ms（インターネット経由） - スループット最大 3 Gbps（VPN Gateway 1 つあたり） - コスト：月 5,000 円（ゲートウェイ 1 つ）+ トラフィック課金

HA VPN（高可用性）： - GCP 側に 2 つのゲートウェイを自動配置（冗長化） - 99.99% アップタイム SLA（Dedicated Interconnect と同等） - しかし遅延は依然 10-50ms

4.5 Cloud NAT の仕組み

Outbound NAT（外向き）： - サブネット内のリソース（内部 IP 10.0.1.10）が外部（インターネット）にアクセス - Cloud NAT が内部 IP → Cloud NAT の公開 IP に変換 - レスポンスは自動的に元のリソースに戻される

Cloud NAT の設定要素： - スコープ：どのサブネットに対して NAT を適用するか - ログ : NAT トラフィックをログ記録するか（デバッグ用） - Port Allocation : リソースあたり何個のポートを予約するか（コネクション数の上限を決める）

⑤ 他サービスとの使い分け

VPC vs VPC Peering vs Shared VPC

要件 VPC VPC Peering Shared VPC
多数のプロジェクト管理 不向き（各 Project ごと） 向いている（1:1 接続） 最適（ハブ&スポーク）
共有 VPC リソース（IAM） 不可能 不可能 可能（Host Project で統一管理）
ネットワーク管理権限 Project Owner Peering Admin が必須 Host Admin 一元化
複数リージョン対応 自由 自由 自由（同一 VPC）
構成の複雑さ シンプル 中程度 やや複雑
コスト 無料（VPC 作成） 無料（Peering） 無料（Shared VPC）
PCA 試験での出現率 高 中 最高

PCA 試験での選択ロジック： - 一社・一チーム内 → 単一 VPC + 複数 Subnet - 複数チーム・部門別 → Shared VPC（Admin が一元化） - 別組織・M&A 後 → VPC Peering（各 Project 独立）

Cloud Interconnect vs Cloud VPN vs Public API

要件 Dedicated Interconnect HA Cloud VPN Public API / HTTPS
遅延（ms） < 1 ms 10-50 ms 50-200 ms
スループット 10-100 Gbps 3 Gbps 可変（ISP）
セットアップ期間 1-3 ヶ月 数時間 即座
月額コスト 4-10 万円 5,000 円 ほぼ 0（トラフィック課金）
オンプレ DB レプリケーション 最適 可（DMS 用） 不向き
CloudSQL ← Replication 推奨 可（検証段階） 非推奨
Spanner グローバルレプ 推奨 可 非推奨

PCA 試験での判断軸： - RTO が秒単位 + 同期レプリケーション必須 → Dedicated Interconnect（遅延 <1ms） - RTO が分単位 + 非同期 OK → HA VPN（安い・速い） - 開発・テスト・低頻度アクセス → Public API（設定不要）

Cloud NAT vs Static IP vs Private Google Access

要件 Cloud NAT Static IP（GCP 公開 IP） Private Google Access
内向きトラフィック 不可 可（Firewall + Load Balancer） N/A
外向きトラフィック 自動（IP 変換） 自由 不要（Google API に直結）
外部リソースへの接続 可 可 Google API のみ
Cloud Storage アクセス NAT を通す 直結 Private Google Access で高速
コスト 月 3,000 円（ゲートウェイ） 無料（未使用時）→ 月 4,000 円（使用中） 無料
セキュリティ 最高（IP 隠蔽） 露出リスク 中程度

PCA 試験での選択基準： - 社内 DB・API への通信 → Cloud NAT（外部 IP を隠す） - Cloud Storage / GCS への高速アクセス → Private Google Access（NAT 不要） - Web サーバー（外部向け） → Static IP（固定必須）

⑥ 実務への応用

ケース 1: Web スタートアップの初期構成

要件： - フロントエンド（Cloud Run）と API（Cloud Run） - RDS 互換 DB（Cloud SQL） - 定期バッチ処理（Compute Engine）

設計： 

VPC: startup-vpc (10.0.0.0/16)
├─ Subnet-FE (10.0.1.0/24): Cloud Run（自動デプロイ）
├─ Subnet-API (10.0.2.0/24): Cloud Run + Cloud SQL
├─ Subnet-Batch (10.0.3.0/24): Compute Engine（深夜実行）
└─ Cloud NAT（Compute Engine のバッチが GCS・GitHub にアクセス）

判断軸： - Cloud Run は VPC 接続を自動でハンドル → サブネット設計のみ - Compute Engine のバッチは IP 固定不要 → Cloud NAT で十分 - Cloud SQL は「プライベート IP」構成（Interconnect 不要）

ケース 2: 大規模エンタープライズの HA 構成

要件： - オンプレ DB（Oracle）→ Cloud SQL への同期レプリケーション - 複数リージョン への自動フェイルオーバー - DLP（Data Loss Prevention）コンプライアンス対応

設計： 

オンプレ DC (192.168.0.0/16)
│
├─ Dedicated Interconnect（VLAN × 2: LON1 + LON2）
│  └─ GCP Primary (europe-west1): Cloud SQL（リーダー/ライター）
│     └─ Cloud SQL レプリケーション → Secondary (us-central1)
│
└─ HA VPN (バックアップ)
   └─ 障害時の代替経路

判断軸： - 同期レプリケーション必須 → Dedicated Interconnect（遅延 <1ms） - セットアップ 1-3 ヶ月を許容 → Interconnect コストは許容（月 5-10 万円） - DLP コンプライアンス → VPC Service Controls + Private IP で完全隔離

ケース 3: 受託開発の マルチテナント構成

要件： - 顧客 A・B・C ごとに異なる VPC - 管理コスト最小化（一つの運用チーム） - 顧客間のネットワーク分離（セキュリティ必須）

設計： 

Host Project（運用チーム：GCP Admin）
├─ Shared VPC
│  ├─ Subnet-A (10.0.0.0/24) → Service Project-A（顧客 A）
│  ├─ Subnet-B (10.0.1.0/24) → Service Project-B（顧客 B）
│  └─ Subnet-C (10.0.2.0/24) → Service Project-C（顧客 C）
│
└─ Cloud Firewall（Host Admin が一元管理）
   ├─ Rule-A: Subnet-A からの通信のみ許可
   ├─ Rule-B: Subnet-B からの通信のみ許可
   └─ Rule-C: Subnet-C からの通信のみ許可

判断軸： - Shared VPC で一元管理 → Admin の運用負荷 80% 削減 - 顧客ごと Service Project → IAM 権限も分離（顧客 A の admin は Subnet-A だけ管理可能） - Firewall を Host で統一 → 誤設定を削減

⑦ よくある誤解・落とし穴

誤解 1: 「VPC Peering なら自動的に通信できる」

❌ 間違い: - VPC A と B を Peering でつなぐだけで「ネットワーク接続は OK」と思ってしまう - しかし Firewall で遮断されていたら、通信は失敗する

✅ 正解: - VPC Peering = ネットワーク層の接続 - Firewall Rule = セキュリティ層の許可 - この 2 つが「両方そろって初めて通信が成功」

VPC-A (FW開放) --Peering--> VPC-B (FW開放) = OK
VPC-A (FW開放) --Peering--> VPC-B (FW遮断) = NG
VPC-A (FW遮断) --Peering--> VPC-B (FW開放) = NG

試験対策: 設問で「A と B を Peering 接続したが通信できない。原因は？」 → まず Firewall Rule を確認するクセをつけよ。

誤解 2: 「Cloud NAT があれば、セキュリティも完璧」

❌ 間違い: - Cloud NAT で IP が隠蔽されるから、外部からのアクセスは防げると思う - しかし Firewall の Ingress Rule が開いていたら、外部からの入力も受け付ける

✅ 正解: - Cloud NAT = Outbound（外向き）トラフィックのみに作用 - Inbound（内向き）トラフィックは Firewall Rule で制御する - 例：0.0.0.0/0 → 0.0.0.0/0 DENY で Inbound 遮断 + Cloud NAT で Outbound

試験対策: 「内部サーバーから外部 API へアクセスしたいが、内部からのアクセスは許可したくない」という要件 → Firewall の Egress Rule + Cloud NAT で実現

誤解 3: 「Cloud Interconnect なら常に高速」

❌ 間違い: - Dedicated Interconnect は遅延 <1ms だから「圧倒的に速い」と思う - しかし DB のレプリケーション遅延は、ネットワーク遅延だけでは決まらない - DB のディスク I/O・ロック競合・ネットワークバッファ など複合要因

✅ 正解: - Interconnect の遅延 <1ms は「往復 RTT」 - DB レプリケーションの同期は「リモート側が書き込み完了」を待つ - ネットワーク <1ms + リモート DB の書き込み 10-100ms + ネットワーク <1ms = 最終的に 20-150ms - Interconnect でも「複数の DB インスタンスを同期的に更新」は難しい

試験対策: 「Oracle → Cloud SQL への同期レプリケーション」 → Interconnect は必須（遅延削減）ですが、「完全な同期」は期待できません。

誤解 4: 「複数 Project なら VPC Peering を使う」

❌ 間違い: - 複数 Project は自動的に VPC Peering を使うべきだと思う - しかし管理複雑度が大幅に上がる（各 Peering の設定・Firewall ルール複数化）

✅ 正解: - 複数チーム・部門で「統一ネットワーク管理」が必要 → Shared VPC（推奨） - 別組織・独立した Project → VPC Peering（各 Project が独立） - Peering はスケーラビリティに限界がある（複数 Project では VPC を複数個作ると Peering の関係が n * (n-1) / 2 本に爆増）

試験対策: PCA 試験では「複数チーム・複数 Project で管理コスト最小化」という要件が出たら → Shared VPC が正解（Peering ではない）

誤解 5: 「HA VPN なら Cloud Interconnect と同じセキュリティ」

❌ 間違い: - HA VPN は 99.99% SLA だから「Interconnect と同等」と思う - しかし HA VPN は「インターネット経由」のため、中間ノードを通過する

✅ 正解: - Dedicated Interconnect = DC ↔ Google PoP ↔ GCP （ダイレクト・Google ネットワーク内） - HA VPN = DC ↔ インターネット ↔ GCP （エンクリプションは IPSec だが、インターネット経由） - セキュリティ水準は異なる（Interconnect の方が高い）

試験対策: 「HIPAA / PCI DSS コンプライアンス対応で、オンプレ DB → Cloud SQL」 → HA VPN ではなく Dedicated Interconnect が正解

⑧ 理解度チェック

問題 1

要件: スタートアップが Cloud Run + Cloud SQL で Web サービスを運用中。Cloud Run は VPC の内部 IP を持つ必要があります。このとき、どのネットワークリソースを設定する必要がありますか？

選択肢: 1. VPC + Subnet + Cloud NAT 2. VPC + Subnet + Cloud Run VPC Connector 3. VPC + Cloud Interconnect 4. VPC Peering + Cloud VPN

答え: 2. VPC + Subnet + Cloud Run VPC Connector

理由: - Cloud Run はデフォルトで Google 管理のネットワークで実行（公開 IP なし） - Cloud SQL に VPC 内部 IP でアクセスするには、Cloud Run VPC Connector で手動接続 - Cloud NAT は「Outbound トラフィック」の外向き NAT だけ（Cloud Run → Google API） - Interconnect / VPN は不要（社内 DC とのリンク不要）

問題 2

要件: オンプレ DC と GCP を接続し、オンプレの DB を Cloud SQL にリアルタイム同期（遅延 <100ms）したい。このとき、どの接続方式を推奨しますか？

選択肢: 1. Cloud VPN のみ（月コスト 5,000 円） 2. Dedicated Interconnect のみ（月コスト 5 万円） 3. Cloud VPN + Dedicated Interconnect 冗長構成（月コスト 55,000 円） 4. Public API 経由（レプリケーションツール使用）

答え: 3. Cloud VPN + Dedicated Interconnect 冗長構成

理由: - 遅延 <100ms 要件 → Dedicated Interconnect 必須（<1ms 達成） - ネットワーク冗長性 (SLA 99.99%) → Interconnect だけでは不足（Interconnect 障害時のバックアップ必要） - HA VPN を「バックアップ」として追加すれば、Interconnect 障害時も自動フェイルオーバー - 月コストは高いが（55,000 円）、ビジネス継続性 (99.99% SLA) を実現

問題 3

要件: 複数事業部（営業・技術・財務）が GCP 上で各々独立したシステムを運用。ネットワークは分離したいが、管理は一元化したい。

このとき、どのトポロジー設計を推奨しますか？

選択肢: 1. 各事業部ごとに VPC を作成し、VPC Peering で接続 2. Host Project の Shared VPC で統一。各事業部は Service Project 3. VPC Peering + 複数 Project（各事業部が独立管理） 4. Cloud Interconnect で全て接続（オンプレとも統合）

答え: 2. Host Project の Shared VPC で統一。各事業部は Service Project

理由: - ネットワーク一元管理 = Host Project の Admin が全体を統制 - リソース分離 = 各事業部の Service Project は独立した IAM / リソース所有 - Firewall・ルーティング一元化 → Host Project で一度の設定で全事業部に適用 - 管理コスト最小化 （VPC Peering では n 本の関係を管理する必要）

問題 4

要件: 内部 Compute Engine インスタンスから GitHub / Docker Hub へのアクセスが必要。Compute Engine は「内部 IP のみ」（公開 IP なし）で運用し、セキュリティを最大化したい。

このとき、どのネットワーク構成を採用しますか？

選択肢: 1. Cloud NAT を使用。GitHub・Docker Hub への外向きアクセスを許可 2. Compute Engine に公開 IP を付与して直結 3. Cloud NAT + Firewall Egress Rule（GitHub/Docker Hub IP アドレスのみ許可） 4. VPN で社内プロキシ経由でアクセス

答え: 3. Cloud NAT + Firewall Egress Rule（GitHub/Docker Hub IP アドレスのみ許可）

理由: - Cloud NAT で内部 IP を隠蔽（セキュリティ向上） - Firewall の Egress Rule で GitHub/Docker Hub の IP のみ許可（ホワイトリスト方式） - 2 層防御 = Cloud NAT（IP 隠蔽）+ Firewall（アクセス制御） - オプション 1（NAT だけ）は不十分（全外部サイトが許可される） - オプション 2（公開 IP）はセキュリティ低下

⑨ 深掘り補足（PCA 試験範囲外）

Cloud Armor の戦略的活用

Cloud Armor = DDoS・WAF（Web Application Firewall）を Compute Engine / Load Balancer の前段に設置

  • Google エッジで攻撃トラフィックを遮断（遅延なし）
  • geo-ブロッキング（特定国からのアクセス遮断）
  • レート制限（1 IP あたり秒 100 リクエストまで）

PCA 試験での出題：「グローバルな Web アプリケーション。DDoS 対策と GDPR 対応（EU からのアクセス制限）」 → Cloud Armor + Cloud CDN で実装

Cloud CDN とネットワークトポロジーの相互作用

Cloud CDN = Google エッジノード（全世界 200+ PoP）でコンテンツをキャッシュ

  • オリジン（自 Web サーバー）への負荷削減
  • レイテンシー削減（ユーザーの近くのエッジから配信）
  • コスト削減（トラフィック圧縮・エッジキャッシュ）

ネットワークトポロジーとの関連： - オリジンが VPC 内部 IP の場合 → Cloud CDN 経由でアクセス不可（CDN は HTTP/HTTPS で通信） - オリジンに「公開 IP」または「Cloud Load Balancer」が必須 - つまり「VPC 内の Compute Engine → Cloud CDN → エッジ → ユーザー」という設計になる

2026年 4月の GCP リリースハイライト

⚠️ 注：ここで言及する機能は、公式ドキュメント時点での情報です

最近のネットワークセクションの GA： - Private Service Connect の拡張 : Google API（BigQuery・Cloud Storage）へのプライベートアクセスがさらに簡素化 - Cloud NAT のログ詳細化 : セッション・パケット単位でのログ取得が可能に（デバッグ性向上）

理解度確認のための実習課題

実装課題： 1. gcloud compute networks create prod-vpc --subnet-mode=custom 2. gcloud compute networks subnets create prod-subnet --network=prod-vpc --range=10.0.0.0/24 --region=us-central1 3. gcloud compute instances create web-server --subnet=prod-subnet --zone=us-central1-a 4. Cloud NAT Gateway を設定し、インスタンスから外部 API へアクセス可能にする

期待される結果： - インスタンスに公開 IP なし、しかし curl https://api.github.com が成功

次回: 2.2 個別ストレージシステムの設定