はじめに
Google Cloud Partner Top Engineer で\textcolor{red}{赤髪} がトレードマークの Shanks です。
2年前に Professional Cloud Network Engineer 試験が日本語化された初日に取得し、先日更新を迎えました。
Google Cloud の資格取得を目指す人に有益な情報となれば幸いです。
注意事項
試験を知る
出題背景
まず、認定試験ガイドを確認すると、大きく5つのセクションに分類されていることがわかります。
Google Cloud ネットワークの設計、計画、プロトタイピング
VPC ネットワークの実装
ネットワーク サービスの構成
ハイブリッド相互接続の実装
ネットワーク オペレーションの管理、モニタリング、トラブルシューティング
これらをさらに大まかに見ていくと、2つの観点が重要視されていることがわかります。
Google Cloud ネイティブな接続の設計・管理・運用
ハイブリッドクラウド・マルチクラウド
前者は Google Cloud のネットワーク製品を正しく選択し、設計できるか、ベストプラクティスに沿ってアーキテクチャを検討できるかという基礎能力が問われる内容です。
後者は Google Cloud とオンプレミスまたは他パブリッククラウドとハブアンドスポーク構成で接続するための制御方法を問われる内容です。
大きく上記2つの背景と観点を理解しておけば、Professional 試験だからといって身構える必要はありません。
筆者のケース
初回受験時：事前学習0h/おおよそ30-45分程度で終了
今回更新時：事前学習0h/おおよそ30-45分程度で終了
出題範囲
出題範囲をもう少し細かく見ていきましょう。
アーキテクチャ設計は、製品選定や接続方式の理解を深めておくと良いでしょう。
ネットワーク運用は、デバッグやモニタリングだけでなくビジネスの拡大に伴うシステムのスケールアウトについて学んでおく必要があります。
アーキテクチャ設計
ネットワーク運用
・ VPC のベストプラクティス
・ Cloud Logging
試験の対策
基本的に Google Cloud の試験には以下の方法が有効だと筆者は考えています。
本記事を試験直前まで読み込んでおく ← 【重要！！！】
関連するプロダクトの公式ドキュメントを確認する
概要、注意事項、料金、制限事項をよく読む
Google Cloud 公式ベストプラクティスをよく読む
手元で試せるプロダクトはまず触れてみる
Google Cloud Skills Boost などの教材を受講する
各章の重要度
出題範囲から各章の重要度をまとめておりますが、重要度 = 出題数というわけではなく原則としてまんべんなく学習していただくことを推奨します。
各章の重要度
章名
ポイント
重要度
VPC のベストプラクティス
VPC ネットワークのベストプラクティスを十分に理解しているか
★★★
Google Cloud ネイティブな接続
Google Cloud 特有の接続手法を十分に理解しているか
★★★
ロードバランサの選定
最適なロードバランサの選定方法を十分に理解しているか
★★★
ハイブリッド/マルチクラウド
オンプレミスや他クラウドとのハブアンドスポーク構成を十分に理解しているか
★★★
コンテンツキャッシュ
CDN による大規模コンテンツ配信について、チューニングを含めた管理手法を理解しているか
★
ネットワークセキュリティ
FW ルールや境界型ネットワークセキュリティのベストプラクティスを十分に理解しているか
★★
限定公開のアクセス
ハイブリッドクラウド/マルチクラウドで閉域網を通じた限定公開のアクセスを十分に理解しているか
★★★
ネットワークフォレンジック
デバッグ、フォレンジック、監視運用のベストプラクティスを十分に理解しているか
★★
組織ポリシーによるガバナンスの強制適用
組織全体でガバナンスを強制する最適なポリシーを選定できるか
★★
ポイント解説：VPC のベストプラクティス【重要！】
自動モードとカスタムモード
図：リージョナル サブネットと グローバル VPC
VPC ネットワークは、Google Cloud 上に構成するグローバルなネットワークのことで、リージョンごとにサブネット （IP アドレス帯）を持ちます。
プロジェクトを新規に払い出したとき、default という名前の VPC が自動的に作成されているのをご存知でしょうか。
すぐに PoC を始められるメリットもありますが、不要な IP アドレスの払い出しや緩いファイアウォールが適用されてしまい、セキュリティの大きな懸念があります。
本番環境で利用するには必ず自身でサブネットを作成する「カスタムモード」 で作成することを強く推奨します。
利用できない IP アドレス
!
サブネットの IP アドレスには、一部利用できない IP アドレスがありますのでご注意ください。
例として、10.0.0.0/24 の場合、通常であればネットワークアドレスとブロードキャストアドレスを差し引いた254個の IP アドレスが利用できますが、Google Cloud では予約された2個のアドレスをさらに差し引いた252個の IP アドレスが利用できます。
表：利用できない代表的なアドレス一覧
アドレス
理由
例
先頭から1番目のアドレス
ネットワークアドレス、一般的に利用不可
e.g. 10.0.0.0(/24)
先頭から2番目のアドレス
デフォルト ゲートウェイ アドレス
e.g. 10.0.0.1(/24)
末尾から1番目のアドレス
ブロードキャストアドレス、一般的に利用不可
e.g. 10.0.0.255(/24)
末尾から2番目のアドレス
将来的な用途のために予約されたアドレス
e.g. 10.0.0.254(/24)
https://zenn.dev/cloud_ace/articles/9b4286fea857bc https://zenn.dev/cloud_ace/articles/dataflow-vpc-scale-out https://cloud.google.com/architecture/best-practices-vpc-design?hl=ja
共有 VPC による組織のガバナンス
図：共有 VPC 概要
共有 VPC は、1つの VPC ネットワークを複数のプロジェクトで共有する機能です。
主なユースケースとして、組織の情シス部門やマルチベンダー開発を統括するシステム部門が、アドレス範囲や FW ルールなどを一元管理 したい場合に利用されます。
ここで、親であるホストプロジェクトが所有権を持っている点に注目してください。roles/compute.networkUser）
共有 VPC で必要な IAM 権限の設定例
サービスプロジェクトで VM を構築する場合の例：
プロジェクト：ホストプロジェクト
リソース：サブネット単位
プリンシパル：サービスプロジェクトの SA
権限：ネットワークユーザ権限
https://cloud.google.com/iam/docs/job-functions/networking?hl=ja
Cloud NAT によるアドレス変換
図：Cloud NAT 概要
Cloud NAT は、VPC ネットワーク内の VM が外部 IP アドレスを持たずにインターネットと通信できるようにするいわゆる NAT のフルマネージドサービスです。Cloud NAT は SNAT であり、DNAT ではない、という点に注意してください。
SNAT（Source NAT）：送信元の IP アドレスを変換する
DNAT（Destination NAT）：宛先の IP アドレスを変換する
あくまでも、VPC からの通信を NAT してインターネット上のサービスにアクセスできるようにするもので、インターネットからの通信は遮断されます。
Serverless 製品と VPC ネットワーク
サーバレス製品である Cloud Run（Functions/Service）からのトラフィックを VPC 経由で送信する場合、2 つの方法があります。
表：Serverless VPC Access と Direct VPC Egress の比較
#
Serverless VPC Access
Direct VPC Egress
対象サービス Cloud Run（Service/全世代のFunctions）, App Engine (全世代)
Cloud Run（Service/第2世代のFunctions）
コネクタ 必要（VM）
不要
コスト コネクタの VM 費用 + ネットワークトラフィック費用
ネットワークトラフィック費用のみ
パフォーマンス レイテンシが高め、スループットが低め
レイテンシが低く、スループットが高い
設定の複雑さ コネクタの作成・管理が必要
コネクタ不要
インターネット接続 コネクタ経由で可能（Cloud NAT との連携も容易）
Cloud NAT との併用で可能
IPアドレス消費 コネクタに割り当てられる
Cloud Run インスタンスに直接割り当てられる。サブネットのIPアドレス消費が多い傾向
Direct VPC Egress は比較的最近 GA になったことから、試験の回答として選択肢に含まれていない可能性もありますが、知識として持っておくとよいでしょう。
!
Serverless VPC Access は 35.199.224.0/19 を内部専用の範囲として使用します。
Google ネットワーク内のルートによって、35.199.224.0/19 から Serverless VPC Access Connector の VM にパケットが配信されます。
https://zenn.dev/cloud_ace/articles/cloudrun-direct-vpc-egress-preview https://zenn.dev/cloud_ace/articles/0f3c9a8f768be9 https://zenn.dev/cloud_ace/articles/6e9ba9490126b1 https://zenn.dev/cloud_ace/articles/direct-vpc-nat-support-for-run
GKE と VPC
VPC ネイティブな GKE クラスタ
公式ドキュメントより引用
GKE の IP アドレスは、クラスタ内のノード、Pod、Service などのリソースに割り当てられます。
ノード：プライマリアドレス
Pod と Service：セカンダリアドレス
ベストプラクティスとして、VPC サブネットから払い出されるプライマリアドレスとセカンダリアドレスを利用する、VPC ネイティブ クラスタ を構成することが推奨されます。
https://cloud.google.com/blog/ja/products/containers-kubernetes/ip-address-management-in-gke
GKE クラスタの IP アドレス設計
GKE クラスタのコンポーネントが必要とする IP アドレスの計算方法については理解しておく必要があります。
例えば、VM が n 台必要で、Pod と Service が将来的に n 個まで拡張される計画がある、と問われたときに必要なアドレスの範囲（CIDR）がすぐ暗算できるように何度も計算しておきましょう。
https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips?hl=ja#defaults_limits https://cloud.google.com/network-intelligence-center/docs/network-analyzer/insights/kubernetes-engine/gke-ip-utilization?hl=ja
ポイント解説：Google Cloud ネイティブな接続【重要！】
PGA vs PSA vs PSC
リソースに外部 IP アドレスを付与せずにサービス接続する「プライベート接続」という機能があります。Private Google Access（PGA） 、Private Service Access（PSA） 、Private Service Connect（PSC） については必須の知識と言ってよいでしょう。
表：PGA / PSA / PSC の比較
名称
ユースケース
Private Google Access（PGA）
インターネットを経由せず内部経路で Google API へアクセスする
Private Service Access（PSA）
インターネットを経由せず VPC と Google マネージド サービスをピアリングする
Private Service Connect（PSC）
インターネットを経由せず内部経路で Google マネージド サービスへアクセスする
https://zenn.dev/cloud_ace/articles/e007a97af56514
VPC Peering による内部通信経路の確保
図：VPC Peering 概要
VPC Peering は、その名の通り 2 つの VPC を接続する ことで、各ネットワーク内のリソースが相互に内部通信できるようにする機能です。
図：VPC Peering の推移的接続の制限
注意点として、直接接続された VPC 同士でしか通信ができません。推移的接続の制限 と呼び、フルメッシュで通信するには、すべての VPC 間でピアリングを行う必要があります。
https://zenn.dev/cloud_ace/articles/511474aa8e4268 https://zenn.dev/cloud_ace/articles/7f6f37fc3f5283#vpc-における推移的接続の制限(おさらい)
ポイント解説：ロードバランサの選定【重要！】
トラフィック種別に応じたロードバランサの選定
図：公式ドキュメントより引用
ロードバランサの選定でもっとも重要視すべきポイントはどんなトラフィックを待ち受けるか という点です。
どんな種類のトラフィックが想定されるか？（LB 種別の絞り込み）
パススルートラフィックをサポートする必要があるか？（パススルー LB かの絞り込み）
インターネットからのトラフィックか？（外部 LB か 内部 LB かの絞り込み）
トラフィックはリージョンをまたぐか？（単一リージョンかクロスリージョンかの絞り込み）
表：ロードバランサ一覧とサポートするトラフィックの種類
ロードバランサの種類
トラフィックの種類
アプリケーション ロードバランサ
HTTP または HTTPS
パススルー ネットワーク ロードバランサ
TCP または UDP
プロキシ ネットワーク ロードバランサ
TCP とオプションの SSL オフロード
プロキシ型とパススルー型
図：プロキシ型とパススルー型のロードバランサ
ロードバランサには「プロキシ型」と「パススルー型」の2種類が存在します。
「プロキシ型」は、ロードバランサのフロントエンド部分（Google Front End または Cloud Front End）に Envoy と呼ばれるプロキシがデプロイされており、1度受け取ったトラフィックのヘッダー情報などをみてバックエンドに転送をする動きをします。
「パススルー型」は、ロードバランサのフロントエンド部分に Maglev と呼ばれる分散処理方式のロードバランサがデプロイされており、受け取ったトラフィックをバックエンドまでそのまま流すため、End to End で終端することができます。
https://cloud.google.com/load-balancing/docs/choosing-load-balancer?hl=ja https://zenn.dev/cloud_ace/articles/947ece662574da
ポイント解説：ハイブリッド/マルチクラウド【重要！】
Cloud VPN で安価に IPsec VPN 接続を構成する
図：Cloud VPN のアーキテクチャ例
Cloud VPN は、オンプレミス NW や他のクラウド環境と Google Cloud の VPC とを IPsec VPN で接続するサービスで、安価にハイブリッドクラウド環境を構築するのに適しています 。
ミッションクリティカルな本番環境では、BGP を使用した高可用性の HA VPN 構成が推奨 されています。
本番環境に適した Cloud VPN（SLA 99.99 %）
Cloud Interconnect で大容量の閉域網（専用線）を構成する
図：Cloud Interconnect のアーキテクチャ例
Cloud Interconnect は、オンプレミス NW や他のクラウド環境と Google Cloud の VPC とを 閉域網（専用線）で物理的に接続する サービスです。通信帯域や安定した回線を確保するのに適しています 。
Cloud VPN と同様に、ミッションクリティカルな本番環境では、高可用性の HA 構成が推奨 されています。
https://cloud.google.com/network-connectivity/docs/interconnect/concepts/ha-vpn-interconnect?hl=ja
Cloud Interconnect の接続方式
Cloud Interconnect の接続方式
表：Cloud Interconnect の接続方式
接続名
ユースケース
帯域幅
価格
Dedicated Interconnect
Google Cloud to On-Premises の接続
10Gbps〜80Gbps
高額
Partner Interconnect
Google Cloud to On-Premises の接続
50Mbps〜50Gbps
低額
Cross-Cloud Interconnect
Google Cloud to Public Cloud の接続
10Gbps〜80Gbps
高額
Cross-Site Interconnect
On-Premises to On-Premises の接続
10Gbps〜80Gbps
高額
Cloud Interconnect のアーキテクチャ
本番環境に適した Cloud Interconnect（SLA 99.99 % / 99.9%）
細かすぎて伝わらない「Dedicated Interconnect の接続要件」
!
Dedicated Interconnect は、ネットワーク デバイスが次の技術要件を満たしている必要があります。
10Gbps 回線、シングルモード ファイバー、10GBASE-LR（1310 nm）
100Gbps 回線、シングルモード ファイバー、100GBASE-LR4
10GBASE-LR または 100GBASE-LR4 optics 規格でサポートされる最長ファイバーは 10 km です。
DWDM（Dense Wavelength Division Multiplexing）といった高密度波長分割多重と呼ばれる高度な技術を用いた特殊な方法もありますが、かなり要件が高くなるため Partner Interconnect が無難になります。
Network Connectivity Center でハブアンドスポークを構成する
図：Network Connectivity Center のアーキテクチャ例
VPC Peering で多数の VPC をフルメッシュでピアリングする場合、ピアリング数が大量になり管理運用が煩雑になる恐れがあります。
NCC は、VPC とオンプレミスの相互接続を一元管理する ハブアンドスポーク型のサービス です。
上記の図の例では Cloud Interconnect で説明した Partner / Dedicated / Cross-Site / Cross-Cloud Interconnect および PSC の接続を、NCC がハブとなり一元管理することができます。
https://zenn.dev/cloud_ace/articles/db934c25b97f63#1.-network-connectivity-center（ncc）
ポイント解説：コンテンツキャッシュ
Cloud CDN によるコンテンツデリバリ
図：Cloud CDN のアーキテクチャ例
Cloud CDN は、Google のグローバルネットワークを使い、静的ウェブコンテンツをユーザに地理的に近い場所から配信することで、表示速度を高速化し、オリジンサーバの負荷を軽減するフルマネージドな CDN サービス です。
キャッシュ機能により、ウェブサイトやアプリケーションのパフォーマンスとセキュリティを向上させます。
さまざまなバックエンドに対応しており、現在は以下をサポートしています。
Instance Group
Zone NEG
Serverless NEG
Internet NEG
GCS バケット
また、ネガティブキャッシュ を活用してステータスコードごとにTTLをチューニングすることでパフォーマンスを向上させることもできます。
ポイント解説：ネットワークセキュリティ
ファイアウォール ルール【重要！】
暗黙のルール
FW ルールには Cloud Console（GUI）や gcloud コマンド（CLI）では確認することができない「暗黙の FW ルール 」が存在します。
暗黙の上り（Ingress）拒否ルール
暗黙の下り（Egress）許可ルール
すべての宛先（0.0.0.0/0）を対象に最も低い優先度（65535）ですべてのプロジェクトに適用されています。
https://cloud.google.com/firewall/docs/firewalls?hl=ja#default_firewall_rules
ファイアウォールのベストプラクティス
SS：gcloud コマンドで FW ルールを作成する例
ファイアウォール ルールのベストプラクティスとして、VM の通信を厳密に制御する必要がある場合、ネットワーク タグではなく、サービスアカウントによる制御を利用 してください。
ネットワーク タグは任意の属性のため、編集権限のあるユーザや悪意ある内部犯が編集してしまう恐れがあるためです。（Compute Engine インスタンス管理者 権限）
https://cloud.google.com/firewall/docs/firewalls?hl=ja#service-accounts-vs-tags https://www.cloudskillsboost.google/course_templates/21/video/488441?locale=ja
階層型 ファイアウォール ルールの継承
図：階層型ファイアウォール概要
通常、VPC ファイアウォール ルールは VPC ネットワークに対して関連付けられていますが、階層型ファイアウォール ポリシー は、Google Cloud リソース階層の組織ノードまたはフォルダノードレベルで適用される ファイアウォール ポリシー を作成できるサービスです。
階層型 ファイアウォール ポリシーは、組織ノードまたはフォルダノードに関連付けられているため、組織やフォルダノードより下に存在するプロジェクトと、今後作成されるプロジェクトのすべての VPC ネットワークにファイアウォール ポリシー ルールが継承され適用されます。
階層型ファイアウォール ポリシーの事前定義ルール
全ての階層型ファイアウォール ポリシーには事前定義のルールが存在するため、ソース範囲外のトラフィックは次の階層のファイアウォール ポリシー ルールで評価されます。
方向
優先度
ソース範囲
アクション
IPv4 の上り（内向き）ルール
ingress
2147483647
0.0.0.0/0
goto_next
IPv4 の下り（外向き）ルール
egress
2147483646
0.0.0.0/0
goto_next
IPv6 の上り（内向き）ルール
ingress
2147483645
::/0
goto_next
IPv6 の下り（外向き）ルール
egress
2147483644
::/0
goto_next
https://cloud.google.com/firewall/docs/firewall-policies?hl=ja https://zenn.dev/cloud_ace/articles/ebd86f443b35d5#階層型-ファイアウォール-ポリシー
Cloud Armor による WAF
図：Cloud Armor 概要
Cloud Armor は、DDoS 攻撃対策と Web アプリケーション ファイアウォール（WAF）を提供するサービス です。
図：公式ドキュメントより引用
Cloud Armor のセキュリティ ポリシーを使用すると、Google のネットワークエッジでトラフィックを許可または拒否することができます。
セキュリティ ポリシーは、次のロードバランサのバックエンド サービスに接続できます。
従来のアプリケーション ロードバランサを含む全ての外部アプリケーション ロードバランサ
リージョン内部アプリケーション ロードバランサ
グローバル外部プロキシ ネットワーク ロードバランサ（TCP/SSL）
従来のプロキシ ネットワーク ロードバランサ（TCP/SSL）
外部パススルー ネットワーク ロードバランサ（TCP / UDP）
https://cloud.google.com/armor/docs/cloud-armor-overview?hl=ja https://zenn.dev/cloud_ace/articles/86cd0d1581f2dc https://zenn.dev/cloud_ace/articles/0ea808072f6f0b
Cloud Armor には Standard と Enterprise という2つの Tier があります。
詳細は別記事にて解説しておりますのであわせてご確認ください。https://zenn.dev/cloud_ace/articles/cloud-armor-enterprise-overview
VPC Service Controls による境界型セキュリティ
図：VPC Service Controls 概要
Google Cloud ではリソースへの操作（編集や閲覧など）を行う際に、API を利用します。境界外からの不正なアクセスを防止するとともに、境界外へのデータの漏洩を防ぐ ことを目的としたサービスです。
GCS バケット内にあるデータをコピーされたくない
BQ データセット内にあるデータを閲覧されたくない
Spanner データベース内にあるデータを外部に持ち出されたくない
詳細については、「Professional Cloud Security Engineer 試験 完全攻略ガイド2025」で記載されていますのであわせてご一読ください。
https://zenn.dev/cloud_ace/articles/howtoget-certified-pcse-2025#vpc-service-controls（vpcsc）-【重要！】
ポイント解説：限定公開のアクセス【重要！】
オンプレミス ホスト用の限定公開の Google アクセス
Google Cloud には仮想的な IP アドレス（通称 VIP）と呼ばれる特殊な IP アドレス範囲があります。Cloud Interconnect などを使う際、Google APIs への通信もインターネット経由ではなく内部ネットワークを利用したい場合に使うのが VIP です。
一見外部 IP アドレスのように見えますが、Google の内部ネットワークに閉じたものであり、インターネット上に公開されているものではありません。
オンプレミスで用途に応じてどちらかを選択し、VIP を名前解決させることで、閉域網を利用した特殊な内部通信経路で Google APIs に到達することができます。
表：2 種類の VIP 比較
VIP
名前解決先
用途
199.36.153.4/30restricted.googleapis.comVPCSC で保護された環境下の API に対して通信するとき
199.36.153.8/30private.googleapis.comVPCSC がサポートしていない API に対して通信するとき
VIP に含まれる IP アドレス
Cloud DNS 限定公開ゾーン
図：公式ブログより引用
Cloud DNS は、IP アドレスとドメインを名前解決する SLA 100% を誇る DNS サービスです。限定公開ゾーン が用意されています。
図：限定公開ゾーン 概要
受信サーバー ポリシー、オンプレミスからの名前解決を Google Cloud で実施する
送信サーバー ポリシー、Google Cloud からの名前解決をオンプレミスにフォワーディングして実施する
DNS ピアリング、プロジェクト間の Cloud DNS 同士でゾーン情報を共有する
https://cloud.google.com/blog/ja/topics/developers-practitioners/cloud-dns-explained https://cloud.google.com/dns/docs/server-policies-overview?hl=ja
Cloud DNS からの通信で使われる送信元 IP アドレス
!
このとき、2 の DNS フォワーディング（送信サーバー ポリシー）を利用する場合、Google Cloud からの通信は 35.199.192.0/19 の IP アドレスが送信元となります。
受信サーバー ポリシーを VPC に適用すると、オンプレミスが DNS リクエストを送信できる宛先として、エントリ ポイントと呼ばれるリージョン内部 IP アドレスが作成されます。
GKE 限定公開クラスタ
図：限定公開クラスタ 概要
限定公開 GKE クラスタは、ノードにプライベート IP アドレスのみを割り当て、コントロールプレーンノードへのアクセスを公共のインターネットから遮断して安全性を向上 させます。
クラスタ管理者がコントロールプレーンノードへアクセスするとき、「承認済みネットワーク」を許可リストで定義しておくことで、クラスタの操作を事前に許可された IP アドレスからのみに制限することができます。
https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters?hl=ja https://www.slideshare.net/slideshow/ss-226446037/226446037
ポイント解説：ネットワークフォレンジック
Network Intelligence Center によるデバッグとフォレンジック【重要！】
図：公式ブログより引用
Network Intelligence Center（以下、NIC）は、ネットワークの可視化、モニタリング、トラブルシューティングを一元的に行うためのサービス です。複雑なクラウドネットワークの運用を効率化し、障害防止やセキュリティ強化に貢献 します。
主な機能は以下のとおりです。
Flow Analyzer
Connectivity Test
Performance Dashboard
Firewall Insights
Network Analyzer
Network Topology
https://cloud.google.com/blog/ja/topics/developers-practitioners/what-network-intelligence-center
Connectivity Test による疎通テスト
図：公式ブログより引用
Connectivity Test は、Google Cloud 内外からの接続性の問題を自己診断するテストツール です。
ロードバランサの設定を変更したので影響確認をしたい
許可されているはずの通信がなぜか遮断されるのでデバッグしたい
ファイアウォール ルールが適切かシミュレーションしたい
https://cloud.google.com/blog/ja/products/networking/announcing-network-intelligence-center
Firewall Insights による FW ルール分析
SS：Firewall Insights 概要
Firewall Insights は、ファイアウォール ルールの使用状況を分析 し、シャドウルールやヒットのないルール、制限が過度に緩いルールなどを特定するツールです。
設定したファイアウォール ルールが機能しているか確認をしたい
不要なファイアウォール ルールがないか確認をしたい
制限が過度に緩いセキュリティリスクのあるルールを特定したい
VPC Flow Logs vs Firewall Logs【重要！】
VPC Flow Logs と Firewall Logs はよく比較対象として挙げられますが、それぞれ役割と目的が異なります。
VPC Flow Logs
図：VPC Flow Logs 概要
VM によって送受信されたトラフィックをサンプリングする
フォレンジック・通信障害の切り分け・トラフィック変化の予測分析時に有用
Firewall Logs
図：Firewall Logs 概要
ファイアウォール ルールに抵触した通信を記録する
ファイアウォール ルールの効果を監査・検証・分析する時に有用
監視とアラート
監視とアラートについては、ACE（Associate Cloud Engineer）や PCA（Professional Cloud Architect）で問われる基礎的な知識を有していれば問題ありません。
VPC Flow Logs
Firewall Logs
ロードバランサや Cloud Armor のログ
ログベースのカスタム モニタリング ダッシュボードおよびアラート
Deep Packet Inspection
Google Cloud へ送信されるトラフィックを、パケットレベルで検査し悪意あるトラフィックが含まれていないか調査するにはいくつかの方法があります。
Multiple vNIC
Packet Mirroring
Cloud NGFW（IPS）
Cloud IDS
Multiple vNIC を活用したアプライアンス導入
Multiple vNIC を活用したアプライアンス導入
図：Multiple vNIC 概要
Compute Engine は専用の仮想 NIC（Network Interface Card、以下 vNIC）を利用しています。
この vNIC は利用するサブネットと1:1で紐づけられています。
ネットワークアプライアンスや IPS / IDS が稼働する GCE インスタンスが検査用の VPC とアプリケーション用の VPC の両方にアクセスをすることで、最小限の費用でパケット検査を行うことが可能です。
https://cloud.google.com/compute/docs/instances/create-instance-multiple-nics?hl=ja
Packet Mirroring によるフォレンジック
Packet Mirroring によるフォレンジック
図：Packet Mirroring 概要
Packet Mirroring は、受信したパケットをフォレンジック用途の別 VM に複製するサービスです。
ペイロードとヘッダを含むすべてのトラフィックとパケットデータをキャプチャすることができるため、フォレンジック用途に最適です。
エンタープライズ セキュリティ
アプリケーション パフォーマンスのモニタリング
https://cloud.google.com/vpc/docs/packet-mirroring?hl=ja
Cloud IDS による不正侵入検知システム
Cloud IDS による不正侵入検知システム
図：公式ドキュメントより引用
Google Cloud で IDS（Intrusion Detection System、不正侵入検知システム）を構成するには、Cloud IDS を利用します。
Packet Mirroring と組み合わせ、Palo Alto Networks が提供する脅威保護技術によって検査・可視化し、ネットワーク上の侵入、マルウェア、スパイウェア、コマンド＆コントロール攻撃の脅威を検出します。
PCI 11.4 や HIPAA といった高度な脅威の検出とコンプライアンスの要件を満たすこともできます。
https://cloud.google.com/security/products/intrusion-detection-system?hl=ja https://cloud.google.com/intrusion-detection-system/docs/overview?hl=ja
Cloud NGFW による不正侵入防止システム
Cloud NGFW による不正侵入防止システム
図：Cloud NGFW による IPS 概要
Google Cloud で IPS（Intrusion Prevention System、不正侵入防止システム）を構成するには、Cloud NGFW Enterprise Tier に含まれる IPS 機能を利用します。
ファイアウォールエンドポイント（以下、FWE）をデプロイし、VPC 内で侵入防御などのレイヤー 7 の高度な保護機能（IPS 等に相当）を提供します。
これらの脅威防止機能は、Palo Alto Networks の脅威防止テクノロジーを利用しており、次の脅威シグネチャ カテゴリをサポートしています。
https://zenn.dev/cloud_ace/articles/cloud-firewall-endpoint-about https://cloud.google.com/firewall/docs/about-intrusion-prevention?hl=ja
ポイント解説：組織ポリシーによるガバナンスの強制適用【重要！】
代表的なポリシーとユースケース
組織ポリシーは、特定の制約（例: IPアドレス、VPC、外部IP付与、共有VPCプロジェクト、デフォルトVPC作成）を組織配下のすべてのフォルダとプロジェクトに適用し、組織全体のガバナンスとセキュリティを強制 します。
主なユースケースとして、組織の情シス部門やセキュリティ部門が Cloud VPN や VPC Peering の接続先を許可リストで制限したり、セキュリティ リスクとなるデフォルト構成の変更を一元管理したい場合に利用されます。
表：代表的なポリシーとユースケース
関連サービス
ポリシー名
ユースケース
Cloud VPN
constraints/compute.restrictVpnPeerIpsCloud VPN の接続先（Peer）に設定できる IP アドレスを制限する
VPC Peering
constraints/compute.restrictVpcPeeringVPC Peering の接続先（Peer）に設定できる VPC を制限する
GCE
constraints/compute.disableExternalIpAccess外部IPアドレスの付与を禁止する
共有 VPC
constraints/compute.restrictSharedVpcHostProjects共有 VPC のホストプロジェクトに指定できるプロジェクトを制限する
VPC
constraints/compute.restrictDefaultNetworkCreation新規のプロジェクト作成時に Default VPC を作成しない
おまけ
おまけ：Google IPs
Google IPs
Google Cloud では、ロードバランサのヘルスチェックなど、Google Managed に動作するコンポーネントがあります。
表：Google Cloud で使われる代表的な IP アドレス範囲 一覧
IPアドレスレンジ
目的
関連するプロダクト
199.36.153.4/30
restricted.googleapis.com・VPCSC
199.36.153.8/30
private.googleapis.com・VPCSC
35.199.192.0/19
Cloud DNS の転送ゾーンを利用したときの送信元アドレス (Cloud DNS)
・Cloud DNS
35.191.0.0/16
LB のバックエンドに対するヘルスチェック基盤の送信元アドレス
・ほとんどのLB
209.85.152.0/22
LB のバックエンドに対するヘルスチェック基盤の送信元アドレス
・外部パススルーLBのみ
169.254.169.254
metadata server
・Compute Engine
35.235.240.0/20
IAP TCP フォワーディングで用いられる送信元アドレス
・Compute Engine
35.199.224.0/19
Serverless VPC Access の内部用アドレス
・Serverless VPC Access
おまけ：PUPI
PUPI（Privately Used Public IP）
Google Cloud では、内部通信での利用に限定して、プライベート利用のパブリック IP アドレス（PUPI、Privately Used Public IP）を利用することができます。
例として、GKE や Cloud Composer といった大きく IP アドレスを消費するサービスを利用した際に、プライベート IP アドレスが枯渇してしまう恐れがあります。
プライベート IP アドレスは一般的に RFC 1918 で定義されている以下の範囲が利用されます。
クラス A：10.0.0.0/8
クラス B：172.16.0.0/12
クラス C：192.168.0.0/16
PUPI を使えば、RFC 1918 外（e.g. 1.2.3.0/24）の範囲を利用することができます。
https://cloud.google.com/blog/ja/topics/developers-practitioners/ip-addressing-options-google-cloud-networking-basics https://datatracker.ietf.org/doc/html/rfc1918
試験準備
先に取得しておくべき資格
冒頭でも述べたとおり、以下の資格については必須知識と言えるほど基礎的なものです。
Associate Cloud Engineer（ACE）
Professional Cloud Architect（PCA）
https://zenn.dev/cloud_ace/articles/google-cloud-next-tokyo-2024-learning-booth-repo
模擬試験
公式案内にもある通り、模擬試験を受験してご自身の理解度をチェックしてみてください。
模擬試験 を受けて、Cloud Network Engineer 試験で出題される可能性のある質問の形式と内容を把握します。
https://docs.google.com/forms/d/e/1FAIpQLSenwtVgqT1eyc3_H_QFdFIAVGezCJ42qAJDmDxUC5Yiq-m-Pw/viewform
試験申し込み
ここまできたら試験を申し込むだけです。
結果受領
リモート受験/現地受験どちらであっても一時的な合否はすぐ確認できます。
筆者の場合は最終的な合否結果を2日ほどで受け取ることができました。
新規取得タイトル：おめでとうございます。Google Cloud Certified として認定されました。認定資格延長のお知らせ
SS：合格通知
おわりに
受験した感想（2023/07）
正直な感想として、身構えるほどの難易度ではなかった、というのが結論です。
ACE＋PCA＋基本的なハイブリッド/マルチクラウドネットワークとアーキテクチャ設計およびネットワーク運用の理解があれば十分合格ラインを突破できる試験ですので、肩の力を抜いてラフに受験してみることをお勧めします。
受験した感想（2025/07）
前回の受験時と同様に、ハードルは高くないと感じました。
まとめ
書き始め当初よりかなりボリューミーな記事となってしまいましたが、ここまで読んでいただきありがとうございます。
また、当然試験内容は随時新しいものへ更新されてしまうため、この記事を閲覧された方は可能な限りお早めの受験を推奨します。
