Google PCNE: ルーティング、Network Connectivity Center、セグメンテーション — 学習ガイド

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

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

概要

このセクションでは、Google Cloudにおけるルーティング、Network Connectivity Center (NCC)、セグメンテーションのパターンについて説明します。ルートの作成と選択方法、分離を維持しながらVPCや組織を相互接続する方法、スケーラブルなトランジットおよびサービス挿入の設計を構築する方法、障害を検証し、封じ込める方法に焦点を当てます。

ルーティングの基礎と制御

• ルートの種類

  • システム生成のサブネットルート: プライマリおよびセカンダリのサブネット範囲ごとに1つ。完全一致するプレフィックスに対して常に最優先されます。
  • インターネットゲートウェイへのデフォルトルート: 新しいVPCで自動的に作成されます。削除または上書きが可能です。
  • 静的ルート: デフォルトインターネットゲートウェイ、特定のインスタンス、ネクストホップとしての内部TCP/UDPロードバランサ (ILB)、またはCloud VPNトンネルなどのネクストホップを持つカスタムプレフィックス。ポリシーベースのルートは、一致条件（タグ、サービスアカウント、プロトコル/ポート）を追加し、高度なサービス挿入のためにインスタンスまたはILBネクストホップにトラフィックを誘導します。
  • 動的ルート: Cloud VPNまたはCloud InterconnectからBGPを介してCloud Routerによって学習されます。そのスコープはVPCの動的ルーティングモード（リージョンまたはグローバル）によって制御されます。

• ルートの選択

  • 最長プレフィックス一致が最優先されます。
  • 複数のルートが同じプレフィックス長を持つ場合、最も低い数値のルート優先度が優先されます（カスタムルートのデフォルトは1000）。静的/動的パス間で同じプレフィックスが重複しないようにし、どちらか一方が明確に優先されるように設計してください。
  • 優先度で決まらない場合は、プラットフォーム内部のタイブレークルールによって解決されますが、これに依存すべきではありません。

• ネクストホップの選択とサービス挿入

  • 下り（egress）トラフィックを集中管理したり、L3/L7サービスを挿入したりするには、0.0.0.0/0の静的ルートまたはポリシーベースのルートを、バックエンドがネットワーク仮想アプライアンス（NVA）であるILBネクストホップに向けます。
  • 外部IPを持たないインスタンスがGoogle APIにアクセスするためにアプライアンスをバイパスする必要がある場合は、サブネットでPrivate Google Accessを有効にし、公開されているGoogle APIのVIP範囲に対するカスタム静적ルートをデフォルトインターネットゲートウェイに追加します。これにより、他の下りトラフィックはNGFWパスをたどる一方で、Googleサービスへのプライベートアクセスが維持されます。

• 動的ルーティングモードと複数リージョンでの動作

  • リージョン: Cloud Routerによって学習されたルートは、同じリージョン内のサブネットにのみインストールされます。
  • グローバル: どこで学習されたルートでもVPC内のすべてのリージョンにインストールされ、シンプルな複数リージョン接続とハブアンドスポーク設計の運用オーバーヘッド削減を可能にします。us-east1とeurope-west1の近くにいるユーザーやワークロードの場合、リージョンサブネットとグローバル動的ルーティングを備えた単一のVPCを使用することで、RFC1918経由で最適な効率でプライベートに通信できます。

• ルートアドバタイズの制御

  • Cloud Routerは、すべてのサブネットまたはカスタムのプレフィックスセット（デフォルトルートを含む）をオンプレミスにアドバタイズできます。オンプレミスへのインバウンドパスの選択は、標準的なBGPツール（MED、ASパスプリペンド、オンプレミスでのローカルプリファレンス）を使用して制御します。オンプレミスへのアクティブ/スタンバイ構成では、プライマリパスに低いMEDを、スタンバイパスに高いMEDを設定します。
  • 異なるASNを持つ異なるオンプレミスピアから同じプレフィックスを同一のCloud Routerにアドバタイズすることは避けてください。デュアルホームECMPやクリーンなフェイルオーバーのためには、冗長化されたオンプレミスルーターで同じピアASNを使用してください。

VPCの相互接続とセグメンテーション

• VPCネットワークピアリング

  • データプレーンアプライアンスなしで、VPC間で低レイテンシのプライベートRFC1918接続を可能にします。デフォルトでサブネットルートを交換し、オプションでカスタムルート（静的および動的）をインポート/エクスポートして、Cloud VPN/Interconnectの背後にあるリソースへの到達可能性を拡張できます。推移的なルーティングはありません: あるピアから学習したルートが別のピアに再エクスポートされることはありません。
  • 障害モードと制限: CIDRの重複は不可。ファイアウォールルールはVPCごとに独立。帯域幅は広いですがロードバランサの代替にはなりません。メッシュピアリングをまたぐ非対称ルーティングはサポートされていません。3つのVPCを三角形に接続するには、ピアリングペアのフルメッシュを構成します。Sales↔FinanceとMarketing↔Financeをピアリングしても、Sales↔Marketingのペアもピアリングしない限り、SalesとMarketing間の接続は有効になりません。
  • アドレス計画: auto-mode VPC（10.128.0.0/9を予約）とピアリングする場合、ピアとなるVPCは10.0.0.0/9のような重複しないCIDRを持つカスタムモードで作成します。

• 共有VPCと複数プロジェクト接続

  • ホストプロジェクトがVPCを所有し、サービスプロジェクトが選択されたサブネットにアタッチします。これにより、ネットワーキングとハイブリッド接続（Cloud Routers、Cloud NAT、Interconnect）を一元管理しつつ、プロジェクトごとにアプリケーションの所有権を委任できます。Dedicated Interconnect用のVLANアタッチメントとCloud Routerをホストプロジェクトに配置することで、すべてのサービスプロジェクトに対してコスト効率の高い、一元化されたオンプレミス接続を提供します。
  • 最小権限: ネットワーク管理者はルーティングとサブネットを管理し、セキュリティ管理者はファイアウォールルールとポリシーを管理します。ネットワーク管理者の権限でファイアウォールを更新できない場合は、共有VPCのスコープでセキュリティ管理者の権限をリクエストしてください。
  • セグメンテーション: サービスプロジェクトが必要とする特定のサブネットのみを共有します。これは、本番環境とステージング環境間のルート公開を厳密に制御するというGoogleのベストプラクティスに沿ったものです。

• ネットワーク分離の制御

  • VPC境界: 明示的なピアリング、VPN、またはPrivate Service ConnectなしではVPC間のルーティングは行われません。完全に分離する必要がある部門やテナントには、別々のVPCを使用します。運用オーバーヘッドを最小限に抑えるため、接続が必要なVPCのみをピアリングします。
  • ファイアウォールポリシー: 組織/フォルダレベルで階層型ファイアウォールポリシーを使用して一貫したガードレールを適用し、ローカルな例外についてはVPCごとのルールを使用します。デフォルトの上り（ingress）拒否/下り（egress）許可は、より厳しく設定できます。
  • 境界（Perimeter）: VPC Service Controlsを使用してGoogle APIへのアクセスを制限し、プロジェクトやネットワークをまたがるデータ漏洩リスクを軽減します。
  • IPv6の公開: パブリックIPv6アクセスには、サービスの前段に配置するグローバル外部HTTP(S)ロードバランサにIPv6を割り当てます。バックエンドはプライベートのままです。

Network Connectivity Center とトランジットアーキテクチャ

• NCC ハブアンドスポーク

  • ハブは、スポーク間のルーティングのためのコントロールプレーンを提供します。スポークには、VLAN アタッチメント (Interconnect)、HA VPN トンネル、ルーターアプライアンススポーク、サイト間データ転送でサポートされる VPC スポークが含まれます。NCC ルートテーブルは、どのプレフィックスをインポート/エクスポートし、どのスポークがそれらを受信するかを制御し、正確なセグメンテーションを可能にします。
  • サイト間データ転送により、オンプレミスサイトはハブをトランジットとして使用し、Google のバックボーン経由で相互に通信できます。これにより、サードパーティのトランジットの必要性を減らし、運用を簡素化します。

• ルーターアプライアンススポークとサードパーティ NVA

  • ルーターアプライアンススポークは、Compute Engine でホストされる仮想ルーター/ファイアウォールを、トランジットまたはインラインサービスとしてオンボードします。複数のアプライアンスにわたるスケールとヘルスチェックによるフェイルオーバーを実現するために、ネクストホップとして ILB を使用します。
  • HA 設計: 少なくとも 2 つのアプライアンスを異なるゾーンにデプロイします。可能であれば MIG を使用して ILB の背後に配置します。インスタンスで IP 転送を有効にします。ILB ネクストホップで対称ステアリングを使用します。タグまたはサービスアカウントに基づくポリシーベースのルートを使用して負荷を分散します。
  • スループットと障害のトレードオフ: NVA はインスタンスタイプと NIC 帯域幅によって制限されます。水平スケールを計画してください。アプライアンスの障害またはヘルスチェックの失敗は、ILB からの削除と高速フェイルオーバーをトリガーしますが、ルート収束タイマーとヘルスしきい値はフラッピングを避けるために調整されていることを確認してください。

• トランジットトポロジのトレードオフ

  • NCC を使用したハブアンドスポーク: 中央集権的なポリシー、高いスケーラビリティ、明確な影響範囲の制御。ルートテーブルの設計とインポート/エクスポートの意図が必要です。
  • フルメッシュピアリング: 少数の VPC にはシンプルで、中央のトランジットはありませんが、スケーラビリティが低く、推移的な接続やサービス挿入を提供できません。
  • 中央集約型エグレス: 1 つの NGFW または NAT によるシンプルなセキュリティ適用。レイテンシを追加し、チョークポイントになる可能性があります。リージョンごとのエグレスポイントとオートスケーリングで緩和します。
  • Cloud Routers を使用したメッシュ VPN: 柔軟で迅速にデプロイ可能。ピア数とともに運用オーバーヘッドが増加します。統合のために NCC を検討してください。

• Cloud VPN の考慮事項

  • オンプレミスデバイスに BGP がない場合は、静的ルートと慎重にスコープされたトラフィックセレクタを使用してポリシーベースの Cloud VPN を使用します。長期的なオーバーヘッドを最小限に抑えるために、最終的には BGP を使用した HA VPN への移行を計画します。
  • オンプレミスへのアクティブ/スタンバイ トンネルの場合、オンプレミス側で MED または AS パスを操作します。
  • 単一の Cloud Router に接続するデュアル オンプレミス ルーターの場合、両方のパスのインストールと ECMP を可能にするために、同一のピア ASN を使用することが推奨されます。異なるピア ASN を使用すると、通常は 1 つのパスしか選択されません。

オペレーション: 検証、分析、障害の封じ込め

• 接続性の検証とルート分析

  • Network Intelligence Center の Connectivity Tests を使用して、VM、ロードバランサ、VPC ピアリング、Cloud VPN、Interconnect にまたがるデータパスをトレースし、ファイアウォール ルールとルートを検証します。
  • VM/サブネットごとの有効なルートを分析して、ネクストホップと動的プレフィックスを確認します。動的ルーティングモードのスコープが意図と一致していることを検証します。
  • パフォーマンスやユーザーエクスペリエンスの問題については、ネットワークロードバランサはリージョン単位であり、グローバルなレイテンシを改善しないため、エニーキャストイングレスとエッジでの終端を通じて世界中のユーザーのレイテンシを削減するグローバル HTTP(S) ロードバランシングを優先します。

• 障害の封じ込めと影響範囲の縮小

  • VPC、NCC ルートテーブル、プロジェクトごとの共有 VPC サブネットでセグメント化し、障害や設定ミスの意図しない伝播を防ぎます。
  • ピアリングによる推移的な依存関係を避けます。推移的な接続が必要な場合は、NCC と制御されたインポート/エクスポートを使用して、到達可能性を制限します。
  • ベースラインの拒否/許可には組織レベルの一元化されたファイアウォールポリシーを使用し、アプリケーションの例外にはローカルポリシーを使用します。変更は Connectivity Tests でテストします。
  • インラインセキュリティが必要な場合は、正常なフェイルオーバーのために、ヘルスチェックとポリシーベースルーティングを備えたネクストホップ ILB をデプロイします。重要な Google API には、外部 IP に依存せずに Private Google Access または Cloud NAT を介して到達できるようにします。
  • BGP セッションとルートの変更を監視します。ルートのオシレーションや非対称フローを避けるために、メトリック（MED、ローカルプリファレンス）とアドレスプランを標準化します。

• 短い設定例

  • インライン ILB を経由してトラフィックを誘導するための静的ルートを作成する:
    • gcloud compute routes create egress-via-ngfw –network my-vpc –destination-range 0.0.0.0/0 –next-hop-ilb ngfw-ilb –priority 900
  • MED を使用して、オンプレミスへの 2 つの BGP パスのうち 1 つを優先する（オンプレミスルーター側）:
    • route-map FROM_GCP permit 10
    • set metric 20
    • router bgp 65000
    • neighbor 169.254.x.y route-map FROM_GCP in

実践的な問題シナリオ

Acme Retail 社は、us-east1 と europe-west1 の近くに 2 つのユーザー集団を持つ、マルチプロジェクトの Google Cloud 組織を運営しています。彼らは、リージョン間のワークロードのプライベートで低コストな通信、一元化されたオンプレミス接続、インターネット出口でのインライン URL フィルタリングを必要としており、同時に財務部門をエンジニアリング部門から隔離しておく必要があります。

1. ホストプロジェクトに単一の共有 VPC を構築し、us-east1 と europe-west1 にリージョンサブネットを配置し、動的ルーティングモードをグローバルに設定します。

• 論理的根拠: 1 つの VPC により、ピアリングのオーバーヘッドなしでリージョン間の直接的な RFC1918 通信が可能になります。グローバル動的ルーティングは、学習したハイブリッドルートをすべてのリージョンにインストールするため、運用が簡素化され、効率的な VPC 内フローが保証されます。

2. 必要なサブネットのみを各サービスプロジェクトに共有します。財務部門とエンジニアリング部門は別々のサービスプロジェクトに配置します。

• 論理的根拠: サブネットレベルの共有は、組織的なセグメンテーションを提供し、意図しないルートの公開を最小限に抑えます。財務部門は、エンジニアリング部門のサブネットを共有せず、ファイアウォールポリシーのスコープを分けるだけで隔離された状態を維持できます。

3. ホストプロジェクトで Dedicated Interconnect を終端させ、Cloud Router をアタッチします。カスタムアドバタイズを使用して、必要なプレフィックスのみをアドバタイズします。

• 論理的根拠: ハイブリッド接続を一元化することで、オンプレミスに到達するルートを制御しつつ、コストと複雑さを削減します。カスタムアドバタイズは、過剰なルート公開を防ぎ、影響範囲を封じ込めます。

4. リージョン内部 TCP/UDP ロードバランサの背後にインライン L7 URL フィルタリングアプライアンスを挿入します。各リージョンで ILB ネクストホップへの 0.0.0.0/0 静的ルートを使用して、下り（egress）トラフィックを誘導します。

• 論理的根拠: ILB ネクストホップとヘルスチェックにより、アプライアンス間で対称的なフローを持つ HA サービス挿入が提供されます。デフォルトよりも高い優先度を持つ静的ルートにより、すべての下りトラフィックが確実にフィルタリングされます。

5. 外部 IP を持たないインスタンスが Google API に直接到達できるようにします。すべてのサブネットで Private Google Access を有効にし、Google API の VIP 範囲への静的ルートをデフォルトのインターネットゲートウェイに追加して、アプライアンスをバイパスします。

• 論理的根拠: Private Google Access は、BigQuery や Pub/Sub へのプライベートアクセスを維持します。カスタムルートは、フィルタを介した不要なヘアピンを防止し、コストとレイテンシを削減します。

6. 財務部門を隔離し続けます。階層型ファイアウォールポリシーでプロジェクト間のトラフィックを拒否し、財務部門とエンジニアリング部門の間でピアリングを設定しません。エンジニアリング部門と分析部門の連携が必要な場合は、重複しない CIDR を持つ専用のピアリングされた VPC ペアを作成します。

• 論理的根拠: VPC の境界、ピアリングの不在、組織レベルのファイアウォールポリシーによって隔離が強制されます。特定の部門間の接続には、推移性なしで運用オーバーヘッドの少ない、的を絞ったピアリングを提供します。

7. 検証とモニタリング：Connectivity Tests を使用して、リージョン間の到達可能性とアプライアンスの挿入を検証します。Cloud Router の BGP の健全性とルートテーブルを監視します。複数のトンネルが存在する場合は、アクティブ/スタンバイのフェイルオーバーのためにオンプレミスルーターに MED を実装します。

• 論理的根拠: 事前検証により、設定ミスを早期に検出できます。BGP 制御は、メンテナンスや障害時にオンプレミスのパスを決定論的に保ち、NCC/Cloud Router のテレメトリはトラブルシューティングを加速させます。

この設計は、Acme Retail 社の要件を最小限のコストと高い効率で満たします。単一の VPC でのプライベートなマルチリージョンルーティング、一元化されたハイブリッド接続、制御されたサービス挿入、そして強力な組織的セグメンテーションを実現します。

← Google およびマネージド サービスへのプライベート接続 · すべてのドメイン · GKE、コンテナ、アプリケーション ネットワーキング →

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

Googleを閲覧 →