Google PCNE: VPC アーキテクチャ、サブネット、アドレス計画 — 学習ガイド

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Network Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Virtual Private Cloud (VPC) は、すべての Google Cloud リージョンにまたがる、グローバルで論理的に分離されたネットワークです。サブネットは VPC 内のリージョン単位の構成要素であり、Compute Engine、GKE、その他のリソースを支える IP 範囲をホストします。健全な VPC アーキテクチャは、アドレスの効率性、成長性、運用上の制御のバランスを取りながら、プロジェクト内およびプロジェクト間のワークロード、そして Google API への低レイテンシで費用対効果の高い接続を保証します。

VPC のスコープ、サブネットアーキテクチャ、モード

• グローバル VPC、リージョナルサブネット

  • 単一の VPC がすべてのリージョンにまたがります。サブネットはリージョンごとに作成され、プライマリ IPv4 CIDR とオプションのセカンダリ範囲を定義します。インスタンスはリージョナルサブネットから IP を受け取りますが、デフォルトでは同じ VPC 内のリージョン間でプライベートに通信できます。
  • 動的ルーティングモード
    • リージョナル: Cloud Router は、そのリージョン内のサブネットとのみルートを交換します。
    • グローバル: あるリージョンの Cloud Router は、学習したルートをすべてのリージョンにアドバタイズします。複数リージョンにまたがるワークロードや HA Egress が必要な場合は、グローバルを優先します。

• 自動モードとカスタムモード

  • 自動モードでは、事前割り当てされた CIDR を持つサブネットがリージョンごとに 1 つ作成されます。迅速な開始には便利ですが、大規模な環境では柔軟性に欠けます。カスタムモードに変換できますが、この変換は一方通行です。
  • カスタムモードでは、サブネットの作成と CIDR の選択を完全に制御できます。これは、本番環境のアドレス計画、共有 VPC、ピアリング、および成長のための推奨パターンです。
  • 移行に関する注意: 自動モードからカスタムモードに変換した後、自動サブネットを想定していたアーティファクトやテンプレートは、カスタムサブネットを参照するように明示的に更新されるまで失敗することがよくあります。

• サブネットの不変性と拡張

  • サブネットのリージョンは不変です。サブネットをリージョン間で移動することはできません。
  • プライマリ IPv4 範囲は、その場で拡張（プレフィックスの拡大）できますが、縮小はできず、VPC および接続されているすべてのネットワーク全体で重複しないようにする必要があります。
  • セカンダリ範囲は追加または削除できますが（使用状況によります）、これも重複しないようにする必要があります。

アドレス計画: プライマリ/セカンダリ範囲、エイリアス IP、IPv6、プライベート空間

• プライマリおよびセカンダリ IPv4 範囲

  • プライマリ範囲: VM インターフェースのアドレス（デフォルトでは nic0）を割り当てます。システム生成のサブネットルートを作成し、ほとんどの内部通信に使用されます。
  • セカンダリ範囲: 追加の CIDR をサブネットに関連付けます。VPC ネイティブの GKE クラスタに必要です。セカンダリ範囲のシステム生成ルートにより、Pod と Service の East-West 通信が可能になります。

• エイリアス IP

  • エイリアス IP を使用すると、VM の NIC がサブネットのプライマリまたはセカンダリ範囲から複数の IP を所有できるようになり、厳密な IP ベースのポリシー、VPC ネイティブ GKE の Pod IP、効率的な IP 利用が可能になります。
  • GKE の場合、断片化と将来のサイズ変更を最小限に抑えるために、大規模で連続したセカンダリ CIDR を計画します。例: 100 ノード、200 Pods/ノード、1500 Services の場合、Pod のセカンダリに少なくとも /17、Services に /21 を割り当てて、余裕を持たせます。

• プライベート RFC 1918 の設計と IP 管理

  • 現在および計画中のすべての VPC、オンプレミス、パートナーにわたって、重複しないブロックを選択します。各環境に大きな親ブロックを予約し、そこからリージョンごと、機能ごとに予測可能なサブブロックを切り出します。
  • 成長、セカンダリ範囲、移行バッファ（一時的なデュアルスタック/ダブル NAT）、インフラストラクチャエンドポイント（ILB VIP、PSC エンドポイント）のためのキャパシティを予約します。
  • パートナーとの接続が見込まれる場合は、最も一般的なエンタープライズブロックを避けるか、NAT でセグメント化して競合を解消します。

• IPv6 の計画

  • 外部 IPv6: グローバルロードバランサでグローバル外部 IPv6 アドレスを使用して、クライアントアクセスとエニーキャストの到達可能性を確保します。
  • 内部 IPv6: 利用可能な場合、デュアルスタックサブネットを有効にして VM に内部 IPv6 を割り当て、それに応じてファイアウォールルールを調整します。DNS AAAA レコードを計画し、IPv4 ポリシーとの整合性を確保します。
  • クラウド内の制御やサードパーティとの統合のために IPv4 を維持し、ロードバランサやデュアルスタックサブネットを通じて段階的に IPv6 を導入します。

ルーティング: 暗黙のルート、カスタムルート、優先度、タグ、ネクストホップ

• 暗黙の（システム生成）ルート

  • サブネットルート: プライマリサブネットとセカンダリレンジごとに1つ。宛先はCIDRと等しく、ネクストホップはサブネット自体。
  • デフォルトルート: デフォルトで、0.0.0.0/0からデフォルトインターネットゲートウェイへのルートが作成される。インターネットへの下り（egress）には、外部IPまたはNATが必要。

• カスタムルートと選択ロジック

  • 最長プレフィックスマッチが優先される。複数のルートが同じプレフィックス長を持つ場合、最も低い優先度番号が優先される（デフォルトの優先度は1000）。
  • タグとサービスアカウント
    • タグのないルートはすべてのVMに適用される。タグでスコープされたルートは、一致するネットワークタグを持つインスタンスにのみ適用される。
    • IDベースのファイアウォールルールはサービスアカウントにマッチさせることができる。可能な場合は、タグよりもきめ細かい制御のためにこれらを使用する。

• ネクストホップ

  • カスタムルートでサポートされるネクストホップには以下が含まれる:
    • デフォルトインターネットゲートウェイ（0.0.0.0/0またはより具体的な下りプレフィックス）
    • インスタンス（他のトラフィックをルーティングするためにIP転送が必要。仮想アプライアンスに使用される）
    • Cloud VPNトンネル（静的ルート）
    • ネクストホップとしてのリージョン内部ロードバランサ（スケーラブルなアプライアンスパターン用）
  • VPCピアリング接続をネクストホップに設定することはできない。ピアリングは独自のルート交換を処理する。

• トラフィックステアリングの例（仮想アプライアンス）

  • サブネットルートよりも具体的なルートを作成し、ネクストホップをIP転送が有効なインスタンスに設定し、ソースVMのタグでスコープを限定する。

  • 例:

undefined

• 外部IPなしでのGoogle APIへの下り（Egress）
  • オプション1: サブネットでPrivate Google Access (PGA)を有効にし、必要に応じてサードパーティのデフォルト下りパスをバイパスするために、Google API VIP向けのカスタムルートをデフォルトインターネットゲートウェイに追加する。
  • オプション2: PGAとCloud NATを併用して、プライベートVMからGoogleサービスへの下りを提供する。
  • オプション3: Private Service Connect to Google APIsを使用して、インターネットを経由せずにサービスを利用する。トラフィックはGoogleのネットワーク内に留まり、VPC内のプライベートRFC1918エンドポイントを使用する。
  • アクセスを制限する場合は、クライアントを制限付きGoogle API VIPに向け、下り制御を強制する。

共有VPC、ピアリング、委任管理、サービスアカウント

• Shared VPC

  • ホストプロジェクトが1つ以上の中央管理されたVPCとサブネットを所有する。サービスプロジェクトは、選択された共有サブネットにワークロードをアタッチする。
  • 委任管理
    • Shared VPC管理者がアタッチメントとサブネット共有を設定する。
    • ネットワーク管理者がホストプロジェクト内のルート、サブネット、ファイアウォールを管理する。
    • サービスプロジェクト内のプロジェクトレベルIAMがワークロードのデプロイを制御する。必要なサブネットのみを共有することで、影響範囲（blast radius）とルートの可視性を制限できる。
  • サービスアカウント
    • チーム間で決定論的かつID駆動の制御を行うには、サービスアカウントベースのファイアウォールポリシーを優先する。
    • 階層や環境ごとに専用のサービスアカウントを使用し、データアクセスには最小権限のロールを付与する（例: Cloud Storageを読み取るサービスアカウントにStorage Object Viewerを付与する）。

• VPC Network Peering

  • 制約
    • 非推移的: A↔BかつB↔Cであっても、A↔Cは成立しない。必要であればフルメッシュを構築する。
    • ピアリングされたネットワーク間でIPレンジの重複は不可。
    • 交換されるのはサブネットルート（セカンダリレンジを含む）に限定される。ピアリング経由のネクストホップステアリングはサポートされていない。
  • 別々のVPCを管理上分離しておく必要がある場合に、低レイテンシ、プライベート、組織内接続を最小限の運用オーバーヘッドで実現するためにピアリングを使用する。

• ハイブリッド接続

  • Dedicated InterconnectとCloud RouterをShared VPCのホストプロジェクトに集約し、大容量の接続を各部門のサービスプロジェクトと共有する。
  • HA VLANアタッチメント、多様なエッジロケーション、デュアルCloud Router、グローバル動的ルーティングを使用して、回復性と必要なすべてのリージョンへの伝播を確保する。

運用: 拡張、HA、プライベートアクセス、検証、トラブルシューティング

• サブネットの拡張と移行の制約

  • サブネットの容量が上限に近づいたら、インプレースで拡張します。接続されているすべてのネットワークで重複がないことを検証し、依存するGKEのセカンダリレンジが引き続き適切であることを確認します。
  • 組織間やパートナー間でレンジが重複する場合は、NATまたは段階的な再ナンバリングを採用します。重複するVPCのピアリングや、重複する動的ルートのインストールはできません。

• リージョン配置と高可用性

  • ユーザーとデータに最も近いリージョンにサブネットを配置します。大西洋をまたぐユーザーベースの場合、us-east1とeurope-west1にリージョンサブネットを持つ単一のVPCを使用することで、VPC内で最適なレイテンシとゼロの下り（内向き）料金で直接プライベート接続を提供します。
  • ワークロードをゾーン間で分散させます。ゾーン障害への耐性のために、リージョンマネージドインスタンスグループとリージョン内部/外部ロードバランサを使用します。
  • ハイブリッド構成の場合、リージョンまたはエッジロケーションごとにデュアルCloud Routerとアタッチメントをデプロイします。サポートされている場合はBFDを有効にし、フェイルオーバーのためにグローバル動的ルーティングを使用します。

• プライベートGoogleアクセスと制限付きエンドポイント

  • 外部IPを持たないインスタンスをホストするサブネットでPGAを有効にします。
  • Google APIへのアクセスを許可しつつ、一般的なインターネットへの下り（外向き）トラフィックを防ぐには：
    • デフォルトトラフィックをNGFWにルーティングします。
    • Google APIのVIPに対するより具体的な静的ルートをデフォルトインターネットゲートウェイに追加するか、Google APIへのPSCエンドポイントをデプロイします。

  • 例：

undefined

• トポロジーの検証とトラブルシューティング
  • Network Intelligence Centerを使用します：
    • Connectivity Testsで到達可能性を検証し、ルーティング、ファイアウォール、ゲートウェイの決定をシミュレートします。
    • Performance DashboardとTopologyでパスとヘルス状態を可視化します。
  • ログとテレメトリ：
    • VPC Flow Logsでインターフェースごとの許可/拒否とレイテンシを監視します。
    • Firewall Rules Loggingでルールの一致を確認します。
    • Cloud NATのログとヘルス状態で、外部IPなしでの下り（外向き）の問題を調査します。
    • ロードバランサとヘルスチェックのログでバックエンドの準備状況を確認します。

  • CLIによるチェック：

undefined

と

undefined

で有効なポリシーを確認します。 - テストVMからtracerouteとcurlを実行し、必要に応じてパケットミラーリングを使用して詳細な検査を行います。

実践的な問題シナリオ

Acme Retail Groupは、集中管理されたマルチリージョン、低レイテンシのGoogle Cloudネットワークを必要としています。このネットワークは、プライベートインスタンスからインターネットを経由せずにGoogle APIにアクセスでき、通信が不要な部門間は厳格に分離されている必要があります。一部のチームは、高密度のPodを持つGKEを実行しています。また、Acmeは一般的な下り（外向き）トラフィックをサードパーティのファイアウォール経由に誘導しつつ、Google APIトラフィックはそのファイアウォールを回避させたいと考えています。

1. ホストプロジェクトにカスタムモードで単一のShared VPCを構築し、グローバル動的ルーティングを有効にします。そして、us-east1とeurope-west1にリージョンサブネットを作成し、GKE用にセカンダリレンジを予約します。

• 根拠: 単一のVPCは、RFC1918アドレスを介して、コストゼロのプライベートなリージョン間接続を提供し、最適な効率を実現します。カスタムモードとグローバル動的ルーティングは、正確なIP計画とマルチリージョンでのルート伝播をサポートします。

2. 各部門のサービスプロジェクトには、必要な特定のサブネットのみを共有します。3つのサービスプロジェクト（Sales、Finance、Marketing）を作成し、それぞれに必要なサブネットのみを公開します。

• 根拠: サブネット単位の共有は、影響範囲とルートの公開を限定し、集中運用を可能にしながら分離を強制します。委任されたIAMにより、中央のネットワーク管理者がファイアウォールとルートを管理し、アプリケーションチームは独立してワークロードをデプロイできます。

3. 通信が必要な部門については、それらの専用VPCをピアリングするか、同じShared VPCサブネットに配置します。分離が必要な部門については、ピアリングを控え、重複するサブネットを共有しないようにします。

• 根拠: ピアリングは、最小限の運用オーバーヘッドで低レイテンシのプライベート接続を提供します。非推移性のため、必要な場所にのみ明示的なメッシュ接続が必要となり、これによりデフォルトで分離が維持されます。

4. すべての共有サブネットでPrivate Google Accessを有効にし、Google APIへのPrivate Service Connectエンドポイントをデプロイします。サードパーティのファイアウォールへのデフォルトルートは維持し、さらにGoogle APIのVIPに対するより具体的な静的ルートをデフォルトインターネットゲートウェイに追加します。

• 根拠: PGAとPSCは、プライベートVMからのインターネットを経由しないAPI利用を提供します。より具体的なルートにより、Google以外のインターネットへの下り（外向き）トラフィックは検査パスを通り続ける一方で、APIトラフィックはNGFWをバイパスすることが保証されます。

5. 成長の余地を持たせてプライマリとセカンダリのCIDRを割り当てます。GKE用には、トラフィックの多いリージョンごとにPod用のセカンダリ（例: /17）とService用のセカンダリ（/21）を確保します。PodとServiceにはエイリアスIPを使用し、それらのレンジにバインドされたVPCネイティブクラスタを作成します。

• 根拠: セカンダリレンジとエイリアスIPは、ノードIPの枯渇を防ぎ、高密度のスケジューリングを可能にします。将来の需要を見越したサイジングは、運用に影響を与えるサイズ変更やセカンダリレンジの再ナンバリングを回避します。

6. ハイブリッドおよびアプライアンストラフィックのためにHAを実装します。必要に応じて、デュアルCloud RouterとHA VPNまたはInterconnectをデプロイします。仮想アプライアンス経由でのトラフィック誘導が必要な場合は、ネクストホップをリージョン内部ロードバランサまたはIP転送が有効なインスタンスに設定し、タグで適用範囲を限定した、より具体的なカスタムルートを使用します。

• 根拠: エッジでのHAは、障害時の継続性を保証します。タグによるルートのスコープ設定は、意図しないトラフィックのヘアピンを回避し、選択されたインスタンスのみがアプライアンスパスを通過するようにします。

7. Network Intelligence CenterのConnectivity Tests、VPC Flow Logs、Firewall Rules Loggingを使用して検証と運用を行います。サービスアカウントを使用してIDベースのファイアウォールポリシーを適用し、リージョンと機能ごとに予約済みバッファを持つIPAMレコードを維持します。

• 根拠: 事前検証は、変更時のサービス停止を防ぎます。IDベースのポリシーは、タグのみのアプローチよりも堅牢です。IPAMの規律を保つことで、ピアリングをブロックしたり、学習したルートを抑制したりする可能性のあるIPアドレスの重複を防ぎます。

すべてのドメイン · ファイアウォール ポリシー、Cloud Armor、ネットワーク セキュリティ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →