Google Cloud
PCNE
完全攻略ガイド

🏗️ 1.1 全体ネットワークアーキテクチャの設計

ネットワークアーキテクチャの設計では、ネットワークティア（Premium / Standard）の選択から始まり、高可用性・フェイルオーバー・DR対応、DNSトポロジ、ロードバランサの選定まで、要件に基づいた全体最適な設計が求められる。

出題される考慮事項

• ネットワークティアの選択（Premium vs Standard）： Premium Tierはグローバルなエニーキャストを利用してGoogleのプライベートバックボーン経由でトラフィックをルーティングし、最低レイテンシを実現。Standard TierはISP網を使用しコストを優先する選択。
• 高可用性・フェイルオーバー・DR設計： マルチリージョン構成、グローバルロードバランサによる自動フェイルオーバー、Cloud Interconnect + HA VPNの二重化によりRTO/RPO目標を達成する設計。
• DNSトポロジの設計（オンプレミス連携含む）： Cloud DNSプライベートゾーン、転送ゾーン、インバウンドサーバーポリシーを組み合わせてオンプレとクラウドのDNS解決を統合する。
• 適切なロードバランサの選定： L7/L4、グローバル/リージョン、外部/内部の観点から、トラフィック特性と要件に基づいて最適なロードバランサを選択する。
• GKEネットワーキングの計画： セカンダリIPレンジ、スケールポテンシャル、コントロールプレーンアクセスを考慮したGKEクラスタのネットワーク設計。
• IAMロールの識別： LBプロビジョニングやShared VPCサブネット権限など、ネットワーク操作に必要な適切なIAMロールを特定する。
• マネージドサービスへの接続計画： Private Services Access、Private Service Connect（PSC）、Serverless VPC Accessを使ったセキュアな接続方法。
• クォータと制限の計画： Cloud Routerの数、動的ルート数、サブネット数など各サービスのクォータを事前に把握し、必要に応じて引き上げを計画。

✅ ベストプラクティス

• 本番ワークロードには常にPremium Tierを選択し、Googleのバックボーンで最低レイテンシを確保する
• アーキテクチャ設計初期段階からSPOFを洗い出し、マルチゾーン・マルチリージョン冗長を組み込む
• グローバル外部ALB + Cloud Armor + Cloud CDNのスタックを標準的なWebアーキテクチャのテンプレートとして採用する
• クォータはプロジェクト作成直後に確認し、本番移行前に必要な引き上げを申請しておく
• マネージドサービス（Cloud SQL、Memorystore等）へのアクセスは外部IPではなくPrivate Service ConnectまたはPrivate Services Accessを使用する

🌐 1.2 VPCネットワークの設計

VPCの設計では、VPCの種類と数の選択（スタンドアロン vs Shared VPC）、IPアドレス管理（IPAM）戦略、グローバル/リージョナルネットワーク構成、MTUサイジング、サードパーティ機器の挿入方法などが問われる。

出題される考慮事項

• VPCの種類と数の選択：スタンドアロンVPC vs Shared VPC。要件に基づいてVPCの数と分離レベルを決定する。
• ネットワーク相互接続の方法：VPC Network Peering、NCC（メッシュ/スタートポロジ）、PSCから要件に合わせて選択する。
• IPアドレス管理（IPAM）戦略：サブネット、IPv6、BYOIP、PUPI（Privately Used Public IP）、Private NAT、非RFC 1918アドレス、IPAM自動化を計画する。
• グローバルまたはリージョナルネットワーク環境の計画：ダイナミックルーティングモード（グローバル/リージョン）の選択と影響を理解する。
• MTUサイジング：VPCのデフォルトMTU（1460）とジャンボフレーム（最大8896バイト）の使い分けと設定方法。
• サードパーティ機器の挿入：NVA（Network Virtual Appliance）のカスタムルート（静的/ポリシーベース）とロードバランシングを使った高可用性設計。

✅ ベストプラクティス

• 本番環境では常にカスタムモードVPCを採用し、IPアドレス計画を事前に文書化する
• エンタープライズではShared VPCを標準として採用し、ネットワーク管理を中央集権化する
• オンプレミス・他VPC・他クラウドとのIPオーバーラップを避けるため、組織全体のIPアドレス台帳を管理する
• 高スループット要件（BigQuery、GKE等）にはジャンボフレーム（MTU 8896）を有効化してパフォーマンスを最大化する
• NVAを挿入する場合は内部LBをネクストホップとして使用し、NVAの単一障害点を排除する

🔗 1.3 レジリエントでパフォーマントなハイブリッド/マルチクラウドネットワーク設計

オンプレミスや他のクラウドプロバイダとのハイブリッド接続設計。Dedicated Interconnect、Partner Interconnect、Cloud VPN、Cross-Cloud Interconnectの使い分けと、高可用性・DR戦略、DNS統合、暗号化オプションが重要なトピックである。

ハイブリッド接続の詳細設計

• 🔒 Interconnect暗号化オプション： MACsec（レイヤー2での暗号化。Dedicated Interconnectの物理リンク上のデータを暗号化）。HA VPN over Interconnect（IPsecによるレイヤー3暗号化。高いセキュリティ要件に対応）。
• 🌐 ハイブリッドDNSトポロジ： Cloud→オンプレ（Cloud DNS転送ゾーンを設定してオンプレのDNSサーバーに転送）。オンプレ→Cloud（インバウンドサーバーポリシーを設定してCloud DNSフォワーダーIPへ委譲）。
• ⚡ HA設計（99.99% SLA）： Dedicated Interconnectの99.99%は異なるメトロの2回線各2VLAN attachment（合計4本）。HA VPNの99.99%は2つのトンネル（異なるゲートウェイ）の同時確立が必須。
• 🎯 MTUの考慮事項： Cloud InterconnectはMTU最大1440バイト（デフォルトVPC MTU 1460から要調整）。HA VPNはIPsecオーバーヘッドでMTUが削減されるためTCP MSS clampingが必要。

✅ ベストプラクティス

• 本番環境のInterconnectにはHA構成（99.99% SLA）を採用し、異なるメトロに冗長回線を確保する
• HA VPNをInterconnectのバックアップとして構成し、BGP LOCAL_PREFでプライマリ/バックアップを制御する
• セキュリティ要件が高い場合はHA VPN over InterconnectでIPsec暗号化を追加する
• BFD（Bidirectional Forwarding Detection）を有効化し、障害検知を数秒以内に短縮する
• Vertex AIなどのGoogle APIへのプライベートアクセスにはPrivate Google AccessとPSCを使用する

☸️ 1.4 GKE（Google Kubernetes Engine）向けネットワーク設計

GKEネットワーク設計では、パブリック/プライベートクラスタの選択、コントロールプレーンエンドポイント、IPアドレス計画（RFC 1918/非RFC 1918）、IPv6対応、負荷分散構成が重要テーマとなる。

出題される考慮事項

• パブリック vs プライベートクラスタノード：セキュリティ要件に応じてノードに外部IPを持たせるか否かを決定。プライベートクラスタではCloud NATが必要。
• パブリック vs プライベートコントロールプレーン：プライベートエンドポイントで外部からのコントロールプレーンアクセスを遮断し、セキュリティを向上させる。
• サブネット計画（プライマリ/セカンダリレンジ）：ノード用プライマリレンジ、Pod用・Service用セカンダリレンジの3つを計画。Pod数が多いため十分な空間を確保する。
• GKEのIPアドレス計画：RFC 1918、非RFC 1918、PSC、共有IPレンジ、PUPIなど多様なIPアドレス戦略の使い分け。
• IPv6対応：デュアルスタッククラスタの設計とIPv6サポートの計画。
• GKE向け負荷分散設計：GKE Gateway コントローラ、GKE Ingressコントローラ、NEGを使ったコンテナネイティブ負荷分散。

✅ ベストプラクティス

• 本番クラスタは必ずプライベートノードを使用し、ノードへの外部からの直接アクセスを遮断する
• コントロールプレーンもプライベートエンドポイントにして、authorized networksで管理IPのみアクセスを許可する
• ノードあたりの最大Pod数を実際の需要に合わせて削減（64等）し、IP空間を節約する
• VPC-nativeクラスタ（エイリアスIP）を使用してPodのIPをVPCでネイティブにルーティング可能にする
• GKE Dataplane V2（eBPFベース）を有効化してネットワークポリシーを高速に実行し、kube-proxyのオーバーヘッドを排除する

⚙️ 2.1 VPCの構成

VPCネットワーク、サブネット、ファイアウォールルール/ポリシーの作成から、VPC Peering、Shared VPC構成、Google APIへのアクセス設定、VPC Service Controls境界の設定まで実装スキルが問われる。

主要な実装タスク

• VPC Network Peeringの構成： 双方向の承認が必要。IPオーバーラップがないことを確認してからピアリングを作成する。
• Shared VPCの作成とサブネット共有： ホストプロジェクトの有効化 → サービスプロジェクトの関連付け → networkUserロールの付与の手順で実施。
• Google APIへのアクセス設定： Private Google Accessをサブネット単位で有効化し、VPC内のVMが外部IPなしでGoogle APIにアクセスできるようにする。
• VPCサブネット範囲の拡張： 既存サブネットのプレフィックス長を短くすることで範囲を拡張可能（縮小は不可）。
• VPC Service Controls境界： Google Cloudサービス（BigQuery、Cloud Storage等）へのアクセスをネットワーク境界で制限してデータ漏洩を防止。

✅ ベストプラクティス

• ファイアウォールルールはIPレンジではなくサービスアカウントまたはネットワークタグで対象を指定し、管理性を高める
• すべてのサブネットでPrivate Google Accessを有効化し、VMが外部IPなしでGoogle APIにアクセスできるようにする
• Shared VPCのサブネット権限はプロジェクトレベルではなくサブネットレベルで付与し、最小権限を実現する
• VPC Service Controlsはまずドライランモードで設定し、違反ログを分析してから強制モードに移行する

🛣️ 2.2 VPCルーティングの構成

静的ルート・動的ルート（Cloud Router）の設定、グローバル/リージョナルダイナミックルーティング、ネットワークタグと優先度によるルーティング、内部LBをネクストホップとした構成、ポリシーベースルーティングが問われる。

• 📌 静的ルート： 手動でルーティングテーブルを設定。NVAのネクストホップに使用。ネットワークタグで特定VMのみに適用可能。変更には手動更新が必要でオペレーションコストが高い。
• 🔄 動的ルート（Cloud Router）： BGPを使って自動的にルートを学習・広報。Interconnect・VPN接続に必須。リージョンまたはグローバルのダイナミックルーティングモードを設定。
• 🎯 ポリシーベースルーティング： 送信元IP、宛先IP、プロトコルなどに基づいてパケットごとにルートを選択。通常のルーティングテーブルより細かい制御が可能。IDS/IPSへのトラフィック誘導に活用。
• ⚖️ 内部LBをネクストホップ： NVAクラスタを内部パススルーLBの後ろに配置し、スタティックルートのネクストホップとして指定。NVA障害時の自動フェイルオーバーを実現。

✅ ベストプラクティス

• ダイナミックルーティングはグローバルモードを使用し、全リージョンのサブネットをCloud Router経由で広報する
• カスタムルート広告を使ってVPCサブネット以外のルート（例：PSCエンドポイントのIP）を選択的に広報する
• NVAはHA構成にし、内部LBをネクストホップとして静的ルートを設定することでNVA障害時の自動切り替えを実現する

🔀 2.3 Network Connectivity Center（NCC）の構成

NCCはハブ＆スポークモデルでVPCと外部ネットワークを統合する次世代のネットワーク集約サービス。スポークタイプの違い、トポロジ管理、Private NATとPSC伝播が重要テーマ。

• VPCスポーク： VPCネットワークをNCCハブに接続。複数VPC間の推移的ルーティングを実現し、複雑なピアリングメッシュを排除する。
• ハイブリッドスポーク： Cloud VPNトンネルまたはVLAN attachmentをスポークとしてNCCハブに接続。オンプレミスをVPCと同じハブで管理。
• プロデューサースポーク： PSCを通じてプロデューサーサービスをNCCハブに統合するスポーク。マネージドサービスへのアクセスを一元管理。
• 📡 Private NAT + PSC伝播： IPが重複する環境でPrivate NATを使用してNATトランスレーションを実施。PSCエンドポイントをNCC経由で伝播し、ハブに接続した全スポークからアクセス可能にする。

✅ ベストプラクティス

• 大規模マルチVPC環境ではVPCピアリングのメッシュよりNCCハブ＆スポークを採用して管理を簡素化する
• サイト間データ転送機能を活用してオンプレ拠点間の通信をGoogleのバックボーン経由でルーティングする
• IP/CIDRフィルタリングを設定して、スポーク間で広報するルートを必要最小限に制限する

🐳 2.4 GKEクラスタの構成と管理

VPC-nativeクラスタ、Shared VPC連携、プライベートクラスタ、GKE Dataplane V2、SNAT/IPマスカレードポリシー、GKEネットワークポリシー、DNS構成など実装レベルの詳細が問われる。

主要な実装タスク

• VPC-nativeクラスタ（エイリアスIP）の作成： --enable-ip-alias フラグでPodとServiceにVPCネイティブのIPを割り当てる。
• Shared VPCとのクラスタ連携： ホストプロジェクトのサブネットとセカンダリレンジをサービスプロジェクトのGKEクラスタで使用。
• プライベートクラスタと認定ネットワーク： コントロールプレーンへのアクセスをauthorized networksで制限し、セキュリティを強化。
• GKE Dataplane V2の有効化： eBPFベースのデータプレーンでネットワークポリシーを高速処理し、可観測性を向上。
• SNATとIPマスカレードポリシー： Pod→外部通信の送信元IP変換を制御。ClusterIPサービスとの通信でのIPマスカレードを管理。
• GKEネットワークポリシー： Pod間通信をラベルセレクタで制御するマイクロセグメンテーション。Ingress/Egressルールを定義。
• DNS構成： ローカルDNSキャッシュ（NodeLocal DNSCache）、Cloud DNS、kube-dnsの選択と設定。

✅ ベストプラクティス

• GKE Dataplane V2を有効化してNetworkPolicyを適用し、Pod間の通信を必要なもののみ許可するゼロトラスト設計を実現する
• NodeLocal DNSCacheを有効化してDNS解決レイテンシを削減し、kube-dnsへの負荷を軽減する
• プライベートクラスタにDNSベースのエンドポイントを使用してコントロールプレーンへのアクセスをより柔軟に管理する

⚖️ 3.1 ロードバランシングの構成

GCPのロードバランサは世界最大規模のソフトウェア定義LBサービス。バックエンドサービス設定、NEG、GKEでのLB、Application LBでのトラフィック管理が重要トピック。

重要な実装ポイント

• バックエンドサービスの設定： NEG（コンテナネイティブ）またはMIG（VMベース）、バランシング方式（使用率/接続数/RPS）、セッションアフィニティ、ヘルスチェック設定。
• GKEでのLB： GKE Gatewayコントローラ（L7）、GKE Ingressコントローラ（L7）、NEGを使ったコンテナネイティブLBでPodへ直接転送。
• Application LBのトラフィック管理： URL書き換え、トラフィックミラーリング、トラフィック分割（カナリアデプロイ）、ヘッダーベースルーティング。

✅ ベストプラクティス

• GKEワークロードにはNEGを使ったコンテナネイティブLBを採用し、kube-proxyのNATオーバーヘッドを排除して送信元IPを保持する
• 本番Webアプリには必ずGlobal External ALBにCloud Armorを組み合わせてDDoS/WAF保護を有効化する
• ヘルスチェックの間隔・タイムアウト・閾値を適切に設定し、障害の迅速な検知と回復を実現する
• GKE Gateway APIを使用してL7の高度なトラフィック管理（加重ルーティング、ヘッダー変換等）を実装する

🚀 3.2 Cloud CDNの構成

Cloud CDNはGoogle Cloud Load Balancingと統合されたエッジキャッシュサービス。MIG、Cloud Storage、Cloud Runなど多様なオリジンに対応し、外部バックエンド（インターネットNEG）にも使用可能。

• 📦 対応オリジン： MIG、Cloud Storage、Cloud Run、App Engine、カスタムオリジン（インターネットNEG、サードパーティオブジェクトストレージ含む）。
• 🗑️ キャッシュ無効化： gcloud compute url-maps invalidate-cdn-cacheコマンドでURLパターン指定（ワイルドカード対応）のキャッシュパージが可能。即座に全エッジに反映される。
• ⚙️ キャッシュモード： CACHE_ALL_STATIC（静的コンテンツ自動キャッシュ）、USE_ORIGIN_HEADERS（オリジンヘッダーに従う）、FORCE_CACHE_ALL（強制キャッシュ）の3種類。
• 🔑 Signed URL/Cookie： プレミアムコンテンツのアクセス制御。Signed URLで個別コンテンツを保護し、Signed Cookieで複数リソースへの一括アクセスを制御する。

✅ ベストプラクティス

• 静的コンテンツ（画像・CSS・JS・動画）は積極的にCloud CDNでキャッシュし、オリジンの負荷とレイテンシを削減する
• オリジンにCache-Controlヘッダーを正確に設定し、動的コンテンツや認証後コンテンツは必ずno-storeで保護する
• キャッシュヒット率をCloud Monitoringで監視し、80%未満の場合はキャッシュキー設計を見直す

🔍 3.3 Cloud DNSの構成

Cloud DNSはGoogleが提供するスケーラブルで低遅延のマネージドDNSサービス。ゾーン管理、ルーティングポリシー、DNSSEC、ハイブリッドDNS統合、スプリットホライズンDNSが重要テーマ。

主要な実装タスク

• Cloud DNSゾーンとレコードの管理： パブリックゾーン、プライベートゾーンの作成とA/AAAA/CNAME/MX/TXTレコード管理。
• DNSルーティングポリシー： 位置情報ポリシー（ジオロケーション）でユーザーの地理的位置に基づいてレスポンスを制御。フェイルオーバーポリシーで障害時の自動切り替え。
• DNSSEC（DNS Security Extensions）： DNSキャッシュポイズニング攻撃を防御するデジタル署名。パブリックゾーンでDNSSECを有効化してセキュリティを強化。
• 自己ホスト型DNS統合（転送・サーバーポリシー）： オンプレミスDNSとCloud DNSを統合するための転送ゾーンとインバウンドサーバーポリシーの設定。
• スプリットホライズンDNS： 同じドメイン名に対してパブリックゾーンとプライベートゾーンで異なるレコードを返す設定。内部IPと外部IPを使い分ける。
• DNSクロスプロジェクトバインディングとDNSピアリング： 別プロジェクトのプライベートゾーンを使用し、複数VPCにまたがるDNS解決を統合する。
• GKEとexternal-dnsオペレータ： KubernetesリソースのライフサイクルにCloud DNSレコードを自動同期するexternal-dnsの構成。

✅ ベストプラクティス

• すべての公開ゾーンでDNSSECを有効化してDNSハイジャックとキャッシュポイズニングから保護する
• ハイブリッド環境ではShared VPCのホストプロジェクトに転送ゾーンを一元化し、複数VPCからDNSピアリングで利用する
• 移行前はTTLを短縮（300秒等）してからIPを変更し、移行完了後にTTLを元の値（86400秒等）に戻す
• GKEクラスタにはNodeLocal DNSCacheを有効化してDNS解決を高速化し、kube-dnsへの負荷を軽減する

🔌 4.1 Cloud Interconnectの構成

Cloud InterconnectはGoogleのネットワークとオンプレミス/他クラウドを物理的に接続する高帯域幅サービス。SLA達成のためのトポロジ設計と暗号化オプションが重要ポイント。

• 🏢 Dedicated Interconnect： GoogleのColo施設に10G/100G回線を直接接続。VLAN attachmentを作成してVPCに接続。最高帯域・最低レイテンシ。自社でポートのプロビジョニングが必要。
• 🤝 Partner Interconnect： 認定パートナー経由でGoogleネットワークに接続。50Mbps〜50Gbps。L2とL3接続タイプあり。L3はBGPをパートナー側で終端する。
• ☁️ Cross-Cloud Interconnect： AWS、Azure等との専用線接続（10G/100G）。インターネットを経由しないマルチクラウド接続。GCPとAWS間のデータ転送コストを削減。
• 🔒 HA VPN over Interconnect： InterconnectのVLAN attachmentの上でHA VPNを構成してIPsec暗号化を追加。物理的な専用線の安全性にIP層の暗号化を重ねる多層防御。

✅ ベストプラクティス

• 本番環境では99.99% SLAトポロジ（異なるメトロ4回線構成）を採用し、メトロレベルの障害にも対応する
• コンプライアンスや規制によりデータ暗号化が必要な場合はHA VPN over Interconnectを構成する
• VLAN attachmentはINACTIVE状態で事前に作成しておき、BGPセッションの設定を事前に完了させてから有効化する

🛡️ 4.2 サイト間IPsec VPNの構成

Cloud VPNはIPsecを使ってオンプレミスやAWS/Azureとの暗号化されたVPN接続を提供。HA VPNは99.99% SLAを提供し、Classic VPNは99.9%のレガシー構成。

• HA VPN（推奨）： 2つのインターフェース（各外部IP）を持つHAゲートウェイ。BGP必須。2本のトンネルを同時に確立することで99.99% SLAを達成。新規構築ではこちらを使用。
• Classic VPN（非推奨）： 1つの外部IPを持つ単一ゲートウェイ。99.9% SLA。ルートベースとポリシーベースのVPNをサポート。新規構築では使用しないことを推奨。

✅ ベストプラクティス

• 常にHA VPN（IKEv2）を使用し、Classic VPNへの新規投資は避ける
• 事前共有鍵（PSK）は自動生成の長いランダム文字列（32文字以上）を使用し、Secret Managerで安全に保管する
• HA VPNのインターフェース0と1に対してそれぞれトンネルを作成し、BGPセッションを両方確立して真の冗長性を確保する

📡 4.3 Cloud Routerの構成

Cloud RouterはBGPスピーカーとして動作し、VPC間およびハイブリッド接続のルーティングを制御。BGP属性の理解とBFD設定が試験の頻出ポイント。

• 🔢 BGP属性： ASN： 各Cloud RouterのAS番号（プライベートASN: 64512-65534推奨）。MED（メトリック）： 低い値が優先。フェイルオーバー制御に使用。LOCAL_PREF： 高い値が優先。プライマリ/バックアップ経路制御。認証： BGPセッションのMD5認証。
• ⚡ BFD（双方向フォワーディング検出）： 標準BGPの障害検知（60秒+）を数秒に短縮するUDPベースのプロトコル。Cloud RouterとオンプレルーターでBFDを有効化してフェイルオーバーを高速化する。
• 📢 カスタムルート広告： VPCサブネット以外のルートを選択的に広報（例：PSCエンドポイントのIP）。特定のオンプレレンジを広報から除外してセキュリティを向上。
• 🎯 ベストパス選択： レガシーと標準のベストパス選択アルゴリズム。標準モードでは同じASNから複数パスを受信した場合にECMP（等コストマルチパス）を適用可能。

✅ ベストプラクティス

• BFDを有効化（最小送信間隔300ms、マルチプライヤ3等）してBGP障害検知を高速化する
• カスタムルート広告を使ってVPCサブネット以外の到達可能なレンジ（PSCエンドポイント等）を必要に応じて広報する
• BGP MD5認証を設定してBGPセッションへの不正接続やルート注入を防止する
• Cloud Routerのクォータ（プロジェクト/リージョン/VPCあたり最大5つ）を把握して設計段階で計画する

🕸️ 4.4 ハイブリッド接続でのNCC構成

NCCをハイブリッド接続に活用して、オンプレミス拠点間のサイト間データ転送、ルーターアプライアンス（NVA）の接続、推移的ルーティング問題の解決が重要テーマ。

主要な実装タスク

• ハイブリッドスポークの作成： VPNトンネルまたはVLAN attachmentをNCCハブのスポークとして登録してオンプレミスを統合。
• サイト間データ転送： オンプレ拠点AからGCPハブを経由してオンプレ拠点BへGoogleのバックボーンで低遅延転送。
• ルーターアプライアンス（RA）： サードパーティのNVA（SD-WAN等）をNCCスポークとして登録してBGPピアリングを確立。
• 推移的ルーティング問題の解決： VPCピアリングでは推移的ルーティングが不可だが、NCCハブ経由で複数スポーク間の通信を可能にする。

📊 5.1 ロギングとモニタリング（Cloud Observability）

ネットワークコンポーネントのログとメトリクスを適切に設定・活用することで、障害の早期発見と根本原因分析を実現する。各サービスの主要なメトリクスを把握することが重要。

✅ ベストプラクティス

• VPC Flow Logsは全サブネットではなく、セキュリティ要件が高い/トラブルシューティングが必要なサブネットに限定し、サンプリングレートを調整してコストを最適化する
• Cloud RouterのBGPセッション状態とルート数をCloud Monitoringでアラートを設定し、ルートクォータ超過を早期検知する
• 重要なネットワークメトリクス（Interconnect帯域利用率80%以上、NATポート使用率90%以上等）にアラートポリシーを設定する
• Cloud DNSクエリログを有効化して不審なDNSクエリ（C2通信、DNSトンネリング等）を検知するSIEMルールを設定する

🔧 5.2 接続問題のトラブルシューティング

VPN、Interconnect、BGPなどのハイブリッド接続の問題を系統的に診断・解決するスキルが問われる。またApplication LBのトラフィックドレインやVPC Flow Logs/パケットミラーリングを使ったデバッグ手法も重要。

主要なトラブルシューティングシナリオ

• Application LBのトラフィックドレイン： バックエンドをメンテナンスモードにするためにサービングキャパシティを0%に設定し、既存接続を安全に終了させる。
• VPNのトラブルシューティング： IKEネゴシエーションの失敗（PSK不一致、暗号スイート不一致）、トンネルのフラッピング（BFD設定ミス）、ルーティング問題の診断。
• Cloud Interconnect問題： 物理リンク状態、VLAN attachmentの状態、BGPセッション確立の確認。Colocation施設との連携が必要な物理障害の判別。
• Cloud Router BGPピアリング問題： BGPセッション状態（IDLE/ACTIVE/ESTABLISHED）の確認、ASN設定ミス、アドバタイズされたルートの確認、認証設定の確認。
• VPC Flow Logs/ファイアウォールログ/パケットミラーリングの活用： REJECTされた通信の特定、ファイアウォールルールのデバッグ、ペイロードレベルの詳細分析。

✅ トラブルシューティングの鉄則

• 下位レイヤーから確認（L1物理→L2リンク→L3ルーティング→L4ポート→L7アプリ）し、根本原因を系統的に絞り込む
• Connectivity Testを最初に実行してルート・ファイアウォール設定の問題を即座に特定する（実際のパケット送信不要）
• 本番環境でのパケットキャプチャにはPacket Mirroringを使用し、直接VMに負荷をかけずに通信内容を分析する

🔬 5.3 Network Intelligence Centerによる監視と診断

Network Intelligence Centerはネットワークの可視化と診断を統合したマネージドツール群。各モジュールの特性と使い分けを正確に理解することが試験では問われる。

• 🗺️ Network Topology： VPC、リージョン、オンプレミスとの接続、VM間の実際のトラフィックフローを視覚的なグラフで表示。帯域利用率とボトルネックを特定。
• 🔍 Connectivity Tests： 実際のパケット送信なしにコントロールプレーン設定を静的解析。ファイアウォールルールやルーティングの問題を瞬時に特定。送信元→宛先の到達性をシミュレーション。
• 📈 Performance Dashboard： プロジェクトスコープとGoogleワイドのパケットロスとレイテンシを表示。VMからGoogleフロントエンドまでの経路上の問題を特定。
• 🔒 Firewall Insights： 機械学習で未使用ルール、シャドウイングされたルール、過剰な権限のルールを自動検出。ファイアウォールポリシーの最適化提案を提供。
• 🔄 Network Analyzer： ネットワーク障害、最適でない設定、利用率警告を自動検知。設定の誤り（孤立したネットワークリソース等）をプロアクティブに通知。
• 📊 Flow Analyzer： VPC Flow LogsとBigQueryを活用してネットワークトラフィックパターンを分析。トップN通信、異常検知、コスト最適化機会の特定。

✅ ベストプラクティス

• 新しい環境や設定変更後はまずConnectivity Testsを実行して、実際の障害が発生する前に設定ミスを検出する
• Firewall Insightsを定期的に確認し（月1回等）、未使用ルールを削除してファイアウォールポリシーをクリーンに保つ
• Network Analyzerのアラートをサブスクライブして、設定の問題をプロアクティブに通知を受ける

🛡️ 6.1 Google Cloud Armorポリシーの構成

Cloud ArmorはGoogleのグローバルエッジで動作するDDoS防御とWAFサービス。外部Application LBに統合され、L3/L4 DDoSを自動吸収し、L7のWAFルールでアプリケーション攻撃を防御する。

主要な実装タスク

• エッジ/バックエンドセキュリティポリシーの構成： エッジポリシーはキャッシュ前に適用（CDNオリジンの保護）、バックエンドポリシーはLBバックエンドに適用。
• WAFルール（SQLi、XSS、RFI）： OWASP Top 10に対応するプリコンフィグルールを適用。プレビューモードで誤検知を確認してから強制モードへ移行。
• 高度なネットワークDDoS防御とAdaptive Protection： L4フラッド攻撃の自動軽減。Adaptive Protectionで機械学習を使ったL7 DDoS攻撃の自動検知と緩和ルール提案。
• レート制限： IP単位のリクエストレートを制限してブルートフォース攻撃やDDoSを軽減。スロットリングとbanの設定。
• ボット管理： reCAPTCHAとの統合によるボットトラフィックの検知と管理。ヒューマンチャレンジの実装。
• Google Threat Intelligence： Googleが収集した脅威情報（悪意のあるIPリスト、Torノード等）に基づいてアクセスをフィルタリング。

✅ ベストプラクティス

• 新しいWAFルールは必ずプレビューモードで先行デプロイし、誤検知がないことを確認してから強制モードに切り替える
• Adaptive Protectionを有効化してL7 DDoS攻撃をMLで自動検知し、提案された緩和ルールを迅速に適用できる体制を整える
• JSONペイロードの解析を有効化してAPIトラフィックのディープインスペクションで高度な攻撃を検出する
• Cloud Armorのログ（requests.json）をBigQueryにエクスポートして長期的な攻撃傾向を分析し、ルールを最適化する

🔥 6.2 Cloud NGFWポリシーとVPCファイアウォールルールの構成と管理

Cloud NGFWはVPCファイアウォールの次世代版。階層型ポリシーによる組織全体の統一管理、L7パケットインスペクション（Enterprise Tier）、GKEとCloud LBとの統合が特徴。

主要な実装タスク

• 階層型ファイアウォールポリシー： 組織レベル→フォルダレベル→プロジェクトレベルの順で評価。上位で設定したルールは下位に継承され組織全体の基本セキュリティを統一。
• 効果的なポリシールールの理解： 階層型ポリシーのどのレベルのルールが最終的に適用されるかを正確に把握する。gotoNextを使ったルールの継続評価。
• マイクロセグメンテーション： メタデータ（セキュアタグ）、サービスアカウント、ネットワークタグを使ってPod/VMレベルの細かいアクセス制御を実装。
• VPCファイアウォールからNGFWポリシーへの移行： 既存VPCファイアウォールルールをNGFWポリシーに変換する段階的な移行戦略。

✅ ベストプラクティス

• デフォルト拒否ポリシーを組織レベルのNGFWポリシーで設定し、全プロジェクトに強制適用する
• IPレンジではなくセキュアタグまたはサービスアカウントでファイアウォールの対象を指定してマイクロセグメンテーションを実現する
• ファイアウォールルールのログ記録を有効化し、Firewall Insightsで定期的に未使用ルールと過剰権限ルールを削除する
• SSH（22番ポート）とRDP（3389番ポート）は全世界への公開（0.0.0.0/0）を絶対に許可せず、IAP経由（35.235.240.0/20）のみ許可する

🌐 6.3 インターネットエグレストラフィックの保護（Cloud NAT / Secure Web Proxy）

VPCからインターネットへのアウトバウンドトラフィックを制御する2つの主要なサービス。Cloud NATはIPアドレス変換、Secure Web ProxyはHTTP/HTTPSトラフィックのURLフィルタリングを提供。

• 🔄 Cloud NAT： プロキシレスSDN実装でアウトバウンドIPを変換。IPアドレス割り当て： 自動（Google管理）または手動（静的予約IP）。ポート割り当て： 静的（固定ポート数/VM）または動的（DPA: 需要に応じて自動調整）。コンプライアンス用に固定外部IPが必要な場合は手動割り当てを使用。
• 🔒 Secure Web Proxy： 明示的プロキシまたはインターセプトモードでHTTP/HTTPSトラフィックをフィルタリング。URLリスト、FQDNマッチング、TLS検査（Managed Certificate Authority経由）で許可/拒否ポリシーを適用。内部ワークロードから特定のURLのみアクセスを許可するホワイトリスト制御。

✅ ベストプラクティス

• すべてのVMに外部IPを持たせず、Cloud NAT経由でインターネットにアクセスさせてアタックサーフェスを最小化する
• Cloud NATに動的ポート割り当て（DPA）を有効化して、接続数の変動に対してポートを効率的に割り当てる
• Cloud NATのport_usageメトリクスに90%以上のアラートを設定し、ポート枯渇を事前に検知する
• 外部パッケージリポジトリへのアクセスを持つワークロードにはSecure Web Proxyを導入してURLレベルのホワイトリスト制御を実装する

🔭 6.4 自己管理型NVAとパケットミラーリングの構成

サードパーティのNVA（NGFW、IDS/IPS等）をGCPに統合するパターンと、パケットキャプチャを使ったネットワーク分析の実装が問われる。

主要な実装タスク

• マルチNIC VM（NVA）によるVPC間トラフィックのルーティングと検査： 内部NICと外部NICを持つNGFWアプライアンスVMを展開し、すべてのトラフィックを検査するアーキテクチャ。
• HA マルチNIC VMルーティングの内部LBをネクストホップとした設定： 内部パススルーNLBをNVAクラスタのフロントエンドとし、静的ルートのネクストホップに指定。NVA障害時の自動フェイルオーバーを実現。
• ポリシーベースルートによるHA マルチNIC VMルーティング： 特定のトラフィック（プロトコル/送信先IP等）を選択的にNVAに誘導するより細かい制御。
• アウトオブバンドネットワークセキュリティ統合： Packet Mirroringを使ってNVAにトラフィックのコピーを送信し、本番トラフィックに影響を与えずに検査。
• パケットミラーリングの構成： ミラーリング対象（VMインスタンス/サブネット）を指定し、内部パススルーNLB経由でコレクターNVAに転送。フィルタでキャプチャするトラフィックを絞り込む。

✅ ベストプラクティス

• NVAは単一障害点を排除するため複数VMで構成し、内部LBをネクストホップとした静的ルートでHA構成にする
• 本番トラフィックの検査にはインライン（ブロック可能）とアウトオブバンド（Packet Mirroring、検知のみ）を要件に応じて使い分ける
• Packet Mirroringはコレクターの処理能力に合わせてフィルタ条件を設定し、不要なトラフィックのミラーリングコストを削減する
• Cloud IDSを活用してPacket Mirroring + Google管理のIDSバックエンドという最小運用コストのIDS構成を実現する