はじめに
Google Cloud Partner Top Engineer で
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 のベストプラクティス ・ ユースケースに応じた製品選定 ・ PGA / PSA / PSC ・ 階層型 ファイアウォール 概要 ・ トラフィック種別に応じたロードバランサの選定 ・ ハイブリッドクラウド接続 ・ マルチクラウド接続 ・ ネットワークセキュリティ |
・ Cloud Logging ・ Cloud Monitoring ・ トラブルシューティング（ファイアウォール分析、疎通テスト） ・ ネットワークフォレンジック ・ 組織ポリシーによるガバナンスの強制適用 |
試験の対策
基本的に Google Cloud の試験には以下の方法が有効だと筆者は考えています。
既にいくつかの Google Cloud 資格（特に Professional Cloud Architect）を取得していればハードルはかなり下がります。
- 本記事を試験直前まで読み込んでおく ← 【重要！！！】
- 関連するプロダクトの公式ドキュメントを確認する
- 概要、注意事項、料金、制限事項をよく読む
- Google Cloud 公式ベストプラクティスをよく読む
- 手元で試せるプロダクトはまず触れてみる
- Google Cloud Skills Boost などの教材を受講する
各章の重要度
出題範囲から各章の重要度をまとめておりますが、重要度 = 出題数というわけではなく原則としてまんべんなく学習していただくことを推奨します。
各章の重要度
| 章名 | ポイント | 重要度 |
|---|---|---|
| VPC のベストプラクティス | VPC ネットワークのベストプラクティスを十分に理解しているか | ★★★ |
| Google Cloud ネイティブな接続 | Google Cloud 特有の接続手法を十分に理解しているか | ★★★ |
| ロードバランサの選定 | 最適なロードバランサの選定方法を十分に理解しているか | ★★★ |
| ハイブリッド/マルチクラウド | オンプレミスや他クラウドとのハブアンドスポーク構成を十分に理解しているか | ★★★ |
| コンテンツキャッシュ | CDN による大規模コンテンツ配信について、チューニングを含めた管理手法を理解しているか | ★ |
| ネットワークセキュリティ | FW ルールや境界型ネットワークセキュリティのベストプラクティスを十分に理解しているか | ★★ |
| 限定公開のアクセス | ハイブリッドクラウド/マルチクラウドで閉域網を通じた限定公開のアクセスを十分に理解しているか | ★★★ |
| ネットワークフォレンジック | デバッグ、フォレンジック、監視運用のベストプラクティスを十分に理解しているか | ★★ |
| 組織ポリシーによるガバナンスの強制適用 | 組織全体でガバナンスを強制する最適なポリシーを選定できるか | ★★ |
ポイント解説：VPC のベストプラクティス【重要！】
自動モードとカスタムモード
図：リージョナル サブネットと グローバル VPC
VPC ネットワークは、Google Cloud 上に構成するグローバルなネットワークのことで、リージョンごとにサブネット（IP アドレス帯）を持ちます。
つまり、異なるリージョン間の IP アドレス空間が VPC の中で通信できる、ということです。
プロジェクトを新規に払い出したとき、default という名前の VPC が自動的に作成されているのをご存知でしょうか。
デフォルトネットワークはすべてのリージョンにサブネットが払い出される「自動モード」で作成されています。
すぐに PoC を始められるメリットもありますが、不要な IP アドレスの払い出しや緩いファイアウォールが適用されてしまい、セキュリティの大きな懸念があります。
本番環境で利用するには必ず自身でサブネットを作成する「カスタムモード」 で作成することを強く推奨します。
利用できない IP アドレス
共有 VPC による組織のガバナンス
図：共有 VPC 概要
共有 VPC は、1つの VPC ネットワークを複数のプロジェクトで共有する機能です。
ネットワーク管理を一元化し、セキュリティや接続性をシンプルに保てます。
イメージとしては、ホストプロジェクト（親）から複数のサービスプロジェクト（子）に対して、サブネットを払い出すような動きをします。
主なユースケースとして、組織の情シス部門やマルチベンダー開発を統括するシステム部門が、アドレス範囲や FW ルールなどを一元管理したい場合に利用されます。
ここで、親であるホストプロジェクトが所有権を持っている点に注目してください。
これはサービスプロジェクトでサブネットを利用するためには、親に対する IAM 権限が必要になります。（roles/compute.networkUser）
共有 VPC で必要な IAM 権限の設定例
サービスプロジェクトで VM を構築する場合の例：
- プロジェクト：ホストプロジェクト
- リソース：サブネット単位
- プリンシパル：サービスプロジェクトの SA
- 権限：ネットワークユーザ権限
Cloud NAT によるアドレス変換
図：Cloud NAT 概要
Cloud NAT は、VPC ネットワーク内の VM が外部 IP アドレスを持たずにインターネットと通信できるようにするいわゆる NAT のフルマネージドサービスです。
Cloud NAT は SNAT であり、DNAT ではない、という点に注意してください。
- SNAT（Source NAT）：送信元の IP アドレスを変換する
- DNAT（Destination NAT）：宛先の IP アドレスを変換する
あくまでも、VPC からの通信を NAT してインターネット上のサービスにアクセスできるようにするもので、インターネットからの通信は遮断されます。
これにより、インターネットに VM が晒されるセキュリティリスクを抑えながら、アプリケーションライブラリや SaaS サービスに安全に接続できるようになります。
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 になったことから、試験の回答として選択肢に含まれていない可能性もありますが、知識として持っておくとよいでしょう。
GKE と VPC
VPC ネイティブな GKE クラスタ
公式ドキュメントより引用
GKE の IP アドレスは、クラスタ内のノード、Pod、Service などのリソースに割り当てられます。
GKE では、VPC ネットワーク内のサブネットを基盤として IP アドレスが管理されます。
- ノード：プライマリアドレス
- Pod と Service：セカンダリアドレス
ベストプラクティスとして、VPC サブネットから払い出されるプライマリアドレスとセカンダリアドレスを利用する、VPC ネイティブ クラスタを構成することが推奨されます。
これにより、適切な IP アドレスを利用者側で設計することができ、FW ルールなども厳格に管理することが可能です。
GKE クラスタの IP アドレス設計
GKE クラスタのコンポーネントが必要とする IP アドレスの計算方法については理解しておく必要があります。
例えば、VM が n 台必要で、Pod と Service が将来的に n 個まで拡張される計画がある、と問われたときに必要なアドレスの範囲（CIDR）がすぐ暗算できるように何度も計算しておきましょう。
ポイント解説：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 マネージド サービスへアクセスする |
VPC Peering による内部通信経路の確保
図：VPC Peering 概要
VPC Peering は、その名の通り 2 つの VPC を接続することで、各ネットワーク内のリソースが相互に内部通信できるようにする機能です。
図：VPC Peering の推移的接続の制限
注意点として、直接接続された VPC 同士でしか通信ができません。
これを推移的接続の制限と呼び、フルメッシュで通信するには、すべての VPC 間でピアリングを行う必要があります。
ポイント解説：ロードバランサの選定【重要！】
トラフィック種別に応じたロードバランサの選定
図：公式ドキュメントより引用
ロードバランサの選定でもっとも重要視すべきポイントはどんなトラフィックを待ち受けるかという点です。
最適なロードバランサの選定手順として、以下の流れで絞り込みをすると良いでしょう。
- どんな種類のトラフィックが想定されるか？（LB 種別の絞り込み）
- パススルートラフィックをサポートする必要があるか？（パススルー LB かの絞り込み）
- インターネットからのトラフィックか？（外部 LB か 内部 LB かの絞り込み）
- トラフィックはリージョンをまたぐか？（単一リージョンかクロスリージョンかの絞り込み）
表：ロードバランサ一覧とサポートするトラフィックの種類
| ロードバランサの種類 | トラフィックの種類 |
|---|---|
| アプリケーション ロードバランサ | HTTP または HTTPS |
| パススルー ネットワーク ロードバランサ | TCP または UDP ESP、GRE、ICMP、ICMPv6 などの IP プロトコル |
| プロキシ ネットワーク ロードバランサ | TCP とオプションの SSL オフロード |
プロキシ型とパススルー型
図：プロキシ型とパススルー型のロードバランサ
ロードバランサには「プロキシ型」と「パススルー型」の2種類が存在します。
「プロキシ型」は、ロードバランサのフロントエンド部分（Google Front End または Cloud Front End）に Envoy と呼ばれるプロキシがデプロイされており、1度受け取ったトラフィックのヘッダー情報などをみてバックエンドに転送をする動きをします。
そのため、トラフィックはフロントエンドで終端され、ロードバランサとバックエンドで新たな通信が始まります。
「パススルー型」は、ロードバランサのフロントエンド部分に Maglev と呼ばれる分散処理方式のロードバランサがデプロイされており、受け取ったトラフィックをバックエンドまでそのまま流すため、End to End で終端することができます。
ポイント解説：ハイブリッド/マルチクラウド【重要！】
Cloud VPN で安価に IPsec VPN 接続を構成する
図：Cloud VPN のアーキテクチャ例
Cloud VPN は、オンプレミス NW や他のクラウド環境と Google Cloud の VPC とを IPsec VPN で接続するサービスで、安価にハイブリッドクラウド環境を構築するのに適しています。
ミッションクリティカルな本番環境では、BGP を使用した高可用性の HA VPN 構成が推奨されています。
本番環境に適した Cloud VPN（SLA 99.99 %）
本番環境に適した Cloud VPN（SLA 99.99 %）
図：Google Cloud 公式ブログより引用
必要なリソースは以下の通りです。
- VPN 接続あたり2つの VPN ゲートウェイ
- VPN ゲートウェイあたり2本の冗長化されたトンネル
Cloud VPN は定期的にダウンタイムを伴うメンテナンスが発生します。
ミッションクリティカルな本番環境に Cloud VPN をデプロイする場合、高可用性の HA VPN 構成を強く推奨します。
Cloud Interconnect で大容量の閉域網（専用線）を構成する
図：Cloud Interconnect のアーキテクチャ例
Cloud Interconnect は、オンプレミス NW や他のクラウド環境と Google Cloud の VPC とを 閉域網（専用線）で物理的に接続するサービスです。
物理的にケーブルを敷設するため高価ではありますが、通信帯域や安定した回線を確保するのに適しています。
Cloud VPN と同様に、ミッションクリティカルな本番環境では、高可用性の HA 構成が推奨されています。
Cloud Interconnect の接続方式
Cloud Interconnect の接続方式
表：Cloud Interconnect の接続方式
| 接続名 | ユースケース | 帯域幅 | 価格 |
|---|---|---|---|
| Dedicated Interconnect | Google Cloud to On-Premises の接続 大規模通信を必要とする場合に最適 |
10Gbps〜80Gbps 100Gbps〜200Gbps |
高額 |
| Partner Interconnect | Google Cloud to On-Premises の接続 小規模通信を必要とする場合に最適 |
50Mbps〜50Gbps | 低額 |
| Cross-Cloud Interconnect | Google Cloud to Public Cloud の接続 マルチクラウドに最適 |
10Gbps〜80Gbps 100Gbps〜200Gbps ※ OCI のみ 1Gbps 〜 |
高額 OCI のみ低額から利用可能 |
| Cross-Site Interconnect | On-Premises to On-Premises の接続 Cloud WAN に最適 |
10Gbps〜80Gbps 100Gbps〜200Gbps |
高額 |
Cloud Interconnect のアーキテクチャ
本番環境に適した Cloud Interconnect（SLA 99.99 % / 99.9%）
本番環境に適した Cloud Interconnect（SLA 99.99 % / 99.9%）
相互接続の可用性を高めるためには、SLA 99.99% が適用される冗長構成を採用することを強く推奨します。
とくに、日本では災害等が発生しやすく、単一リージョンに限定された運用はリスクがあります。
東京・大阪双方で相互接続をホストし、高可用性を実現しましょう。
必要なリソースは以下の通りです。
- 異なるリージョンにそれぞれ分散された Interconnect 回線（相互接続）
- 相互接続あたり正副2本の冗長化された接続
表：SLA 99.9% の構成と SLA 99.99% の構成
| SLA 99.9% | SLA 99.99% |
|---|---|
 |
 |
細かすぎて伝わらない「Dedicated Interconnect の接続要件」
Network Connectivity Center でハブアンドスポークを構成する
図：Network Connectivity Center のアーキテクチャ例
VPC Peering で多数の VPC をフルメッシュでピアリングする場合、ピアリング数が大量になり管理運用が煩雑になる恐れがあります。
そこで、単一のハブを介してスポークと呼ばれる枝分かれした接続先同士を通信可能にするためのサービスが Network Connectivity Center（以下、NCC）です。
NCC は、VPC とオンプレミスの相互接続を一元管理する ハブアンドスポーク型のサービス です。
多様な接続オプションを統合し、広域ネットワークとして Google のバックボーンを活用することで、効率的でスケーラブルなネットワーク接続を実現します。
上記の図の例では Cloud Interconnect で説明した Partner / Dedicated / Cross-Site / Cross-Cloud Interconnect および PSC の接続を、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）ですべてのプロジェクトに適用されています。
これは、Google Cloud へのアクセスには明示的に許可リストで制御し、逆に Google Cloud からのアクセスには明示的に拒否リストで制御するという設計思想が反映されています。
ファイアウォールのベストプラクティス
SS：gcloud コマンドで FW ルールを作成する例
ファイアウォール ルールのベストプラクティスとして、VM の通信を厳密に制御する必要がある場合、ネットワーク タグではなく、サービスアカウントによる制御を利用してください。
ネットワーク タグは任意の属性のため、編集権限のあるユーザや悪意ある内部犯が編集してしまう恐れがあるためです。（Compute Engine インスタンス管理者 権限）
階層型 ファイアウォール ルールの継承
図：階層型ファイアウォール概要
通常、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 (次のステップへ進む) |
Cloud Armor による WAF
図：Cloud Armor 概要
Cloud Armor は、DDoS 攻撃対策と Web アプリケーション ファイアウォール（WAF）を提供するサービス です。
設定したセキュリティポリシーに従い、OWASP Top 10 などの代表的な悪意のあるトラフィックを検知・ブロックし、アプリケーションを保護します。
図：公式ドキュメントより引用
Cloud Armor のセキュリティ ポリシーを使用すると、Google のネットワークエッジでトラフィックを許可または拒否することができます。
これにより、悪意あるトラフィックを遮断したり VPC ネットワークへの侵入を防止することができます。
セキュリティ ポリシーは、次のロードバランサのバックエンド サービスに接続できます。
- 従来のアプリケーション ロードバランサを含む全ての外部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
- グローバル外部プロキシ ネットワーク ロードバランサ（TCP/SSL）
- 従来のプロキシ ネットワーク ロードバランサ（TCP/SSL）
- 外部パススルー ネットワーク ロードバランサ（TCP / UDP）
Cloud Armor には Standard と Enterprise という2つの Tier があります。
Enterprise Tier には Standard Tier の全機能に加えて、高度な DDoS 攻撃からの料金保護、機械学習を用いた Adaptive Protection、DDoS 対応サポートなどが含まれます。
詳細は別記事にて解説しておりますのであわせてご確認ください。
VPC Service Controls による境界型セキュリティ
図：VPC Service Controls 概要
Google Cloud ではリソースへの操作（編集や閲覧など）を行う際に、API を利用します。
VPC Service Controls（以下、VPCSC）とは、この APIを仮想的な境界を用いて保護することで、境界外からの不正なアクセスを防止するとともに、境界外へのデータの漏洩を防ぐ ことを目的としたサービスです。
- GCS バケット内にあるデータをコピーされたくない
- BQ データセット内にあるデータを閲覧されたくない
- Spanner データベース内にあるデータを外部に持ち出されたくない
詳細については、「Professional Cloud Security Engineer 試験 完全攻略ガイド2025」で記載されていますのであわせてご一読ください。
ポイント解説：限定公開のアクセス【重要！】
オンプレミス ホスト用の限定公開の Google アクセス
Google Cloud には仮想的な IP アドレス（通称 VIP）と呼ばれる特殊な IP アドレス範囲があります。
Cloud Interconnect などを使う際、Google APIs への通信もインターネット経由ではなく内部ネットワークを利用したい場合に使うのが VIP です。
一見外部 IP アドレスのように見えますが、Google の内部ネットワークに閉じたものであり、インターネット上に公開されているものではありません。
オンプレミスで用途に応じてどちらかを選択し、VIP を名前解決させることで、閉域網を利用した特殊な内部通信経路で Google APIs に到達することができます。
表：2 種類の VIP 比較
| VIP | 名前解決先 | 用途 |
|---|---|---|
199.36.153.4/30 |
restricted.googleapis.com |
VPCSC で保護された環境下の API に対して通信するとき |
199.36.153.8/30 |
private.googleapis.com |
VPCSC がサポートしていない API に対して通信するとき |
VIP に含まれる IP アドレス
Cloud DNS 限定公開ゾーン
図：公式ブログより引用
Cloud DNS は、IP アドレスとドメインを名前解決する SLA 100% を誇る DNS サービスです。
インターネットからのリクエストに応答する公開ゾーンと、VPC 内部や Cloud Interconnect 経由の内部通信に限定した限定公開ゾーンが用意されています。
図：限定公開ゾーン 概要
- 受信サーバー ポリシー、オンプレミスからの名前解決を Google Cloud で実施する
- 送信サーバー ポリシー、Google Cloud からの名前解決をオンプレミスにフォワーディングして実施する
- DNS ピアリング、プロジェクト間の Cloud DNS 同士でゾーン情報を共有する
Cloud DNS からの通信で使われる送信元 IP アドレス
GKE 限定公開クラスタ
図：限定公開クラスタ 概要
限定公開 GKE クラスタは、ノードにプライベート IP アドレスのみを割り当て、コントロールプレーンノードへのアクセスを公共のインターネットから遮断して安全性を向上 させます。
ノード上で動くコンテナだけでなく、コントロールプレーンノードに関しても外部からの不正アクセスを防ぎ、セキュリティを強化します。
クラスタ管理者がコントロールプレーンノードへアクセスするとき、「承認済みネットワーク」を許可リストで定義しておくことで、クラスタの操作を事前に許可された IP アドレスからのみに制限することができます。
ポイント解説：ネットワークフォレンジック
Network Intelligence Center によるデバッグとフォレンジック【重要！】
図：公式ブログより引用
Network Intelligence Center（以下、NIC）は、ネットワークの可視化、モニタリング、トラブルシューティングを一元的に行うためのサービス です。
ネットワークトポロジ、接続テスト、パフォーマンスダッシュボードなどで構成され、複雑なクラウドネットワークの運用を効率化し、障害防止やセキュリティ強化に貢献 します。
主な機能は以下のとおりです。
- Flow Analyzer
- Connectivity Test
- Performance Dashboard
- Firewall Insights
- Network Analyzer
- Network Topology
Connectivity Test による疎通テスト
図：公式ブログより引用
Connectivity Test は、Google Cloud 内外からの接続性の問題を自己診断するテストツール です。
構成変更の影響を検証したり、意図しない通信断の原因を調査したり、ネットワーク障害をシミュレーションすることができます。
Connectivity Test は、Google Cloud のサポートチームがお客様の問題を解決するときに社内で使用されていたものです。
- ロードバランサの設定を変更したので影響確認をしたい
- 許可されているはずの通信がなぜか遮断されるのでデバッグしたい
- ファイアウォール ルールが適切かシミュレーションしたい
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）を利用しています。
インスタンススペック と vCPU に応じてサポートしている帯域幅が異なります。
この vNIC は利用するサブネットと1:1で紐づけられています。
つまり、GCE インスタンスに複数の vNIC を設定することで、複数のサブネット / VPC にアクセスをすることが可能になります。
ネットワークアプライアンスや IPS / IDS が稼働する GCE インスタンスが検査用の VPC とアプリケーション用の VPC の両方にアクセスをすることで、最小限の費用でパケット検査を行うことが可能です。
Packet Mirroring によるフォレンジック
Packet Mirroring によるフォレンジック
図：Packet Mirroring 概要
Packet Mirroring は、受信したパケットをフォレンジック用途の別 VM に複製するサービスです。
アプリケーション VM で受信したパケットを複製し、内部 パススルー ネットワーク ロードバランサ経由でフォレンジック VM に転送します。
ペイロードとヘッダを含むすべてのトラフィックとパケットデータをキャプチャすることができるため、フォレンジック用途に最適です。
- エンタープライズ セキュリティ
- アプリケーション パフォーマンスのモニタリング
Cloud IDS による不正侵入検知システム
Cloud IDS による不正侵入検知システム
図：公式ドキュメントより引用
Google Cloud で IDS（Intrusion Detection System、不正侵入検知システム）を構成するには、Cloud IDS を利用します。
Packet Mirroring と組み合わせ、Palo Alto Networks が提供する脅威保護技術によって検査・可視化し、ネットワーク上の侵入、マルウェア、スパイウェア、コマンド＆コントロール攻撃の脅威を検出します。
また、VM 間の通信をモニタリングしてラテラル ムーブメントを検出することができます。
PCI 11.4 や HIPAA といった高度な脅威の検出とコンプライアンスの要件を満たすこともできます。
Cloud NGFW による不正侵入防止システム
Cloud NGFW による不正侵入防止システム
図：Cloud NGFW による IPS 概要
Google Cloud で IPS（Intrusion Prevention System、不正侵入防止システム）を構成するには、Cloud NGFW Enterprise Tier に含まれる IPS 機能を利用します。
ファイアウォールエンドポイント（以下、FWE）をデプロイし、VPC 内で侵入防御などのレイヤー 7 の高度な保護機能（IPS 等に相当）を提供します。
既存の VPC のルーティングを変更することなく FWE で透過的にトラフィックを検査し、Google Cloud 内の通信をセキュアに保ちます。
（このような動作をパケットインターセプトと呼びます。）
これらの脅威防止機能は、Palo Alto Networks の脅威防止テクノロジーを利用しており、次の脅威シグネチャ カテゴリをサポートしています。
- スパイウェア対策
- 脆弱性保護
- ウイルス対策
ポイント解説：組織ポリシーによるガバナンスの強制適用【重要！】
代表的なポリシーとユースケース
組織ポリシーは、特定の制約（例: IPアドレス、VPC、外部IP付与、共有VPCプロジェクト、デフォルトVPC作成）を組織配下のすべてのフォルダとプロジェクトに適用し、組織全体のガバナンスとセキュリティを強制 します。
主なユースケースとして、組織の情シス部門やセキュリティ部門が Cloud VPN や VPC Peering の接続先を許可リストで制限したり、セキュリティ リスクとなるデフォルト構成の変更を一元管理したい場合に利用されます。
表：代表的なポリシーとユースケース
| 関連サービス | ポリシー名 | ユースケース |
|---|---|---|
| Cloud VPN | constraints/compute.restrictVpnPeerIps |
Cloud VPN の接続先（Peer）に設定できる IP アドレスを制限する |
| VPC Peering | constraints/compute.restrictVpcPeering |
VPC 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 に動作するコンポーネントがあります。
それらのコンポーネントが利用する IP アドレスは定義されており、必要に応じてファイアウォール ルールの許可設定を検討する必要があります。
表：Google Cloud で使われる代表的な IP アドレス範囲 一覧
| IPアドレスレンジ | 目的 | 関連するプロダクト |
|---|---|---|
| 199.36.153.4/30 | restricted.googleapis.com |
・VPCSC ・Cloud Interconnect |
| 199.36.153.8/30 | private.googleapis.com |
・VPCSC ・Cloud Interconnect |
| 35.199.192.0/19 | Cloud DNS の転送ゾーンを利用したときの送信元アドレス (Cloud DNS) | ・Cloud DNS |
| 35.191.0.0/16 130.211.0.0/22 |
LB のバックエンドに対するヘルスチェック基盤の送信元アドレス | ・ほとんどのLB |
| 209.85.152.0/22 209.85.204.0/22 |
LB のバックエンドに対するヘルスチェック基盤の送信元アドレス | ・外部パススルーLBのみ |
| 169.254.169.254 | metadata server | ・Compute Engine |
| 35.235.240.0/20 | IAP TCP フォワーディングで用いられる送信元アドレス | ・Compute Engine ・Cloud IAP |
| 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 アドレスが枯渇してしまう恐れがあります。
Cloud Interconnect などでオンプレミス ネットワークと 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）の範囲を利用することができます。
苦肉の策となりますので可能な限り IP アドレスを整理することを推奨します。
試験準備
先に取得しておくべき資格
冒頭でも述べたとおり、以下の資格については必須知識と言えるほど基礎的なものです。
まだ取得していない方はまずはこちらを取得して Google Cloud の基礎を学び、そのうえで応用として本試験にチャレンジすることを強く推奨します。
- Associate Cloud Engineer（ACE）
- Professional Cloud Architect（PCA）
模擬試験
公式案内にもある通り、模擬試験を受験してご自身の理解度をチェックしてみてください。
必ずしも模擬試験の傾向や問題そのものがそっくり出題されるわけではないですが、あくまで参考値として理解度を知ることができます。
（ここで点数が取れなくても落ち込むほどのものではありません）
模擬試験を受けて、Cloud Network Engineer 試験で出題される可能性のある質問の形式と内容を把握します。
試験申し込み
ここまできたら試験を申し込むだけです。
Webassessor にて任意の日時で受験申し込みをし、当日受験をすれば完了です。
資格試験あるあるですが、受験申し込みをするまでに自分を奮い起こすのが1番の難関です。
結果受領
リモート受験/現地受験どちらであっても一時的な合否はすぐ確認できます。
「合格」という文字が表示されたら無事に合格ラインに到達できたという判定です。
筆者の場合は最終的な合否結果を2日ほどで受け取ることができました。
新規取得タイトル：おめでとうございます。Google Cloud Certified として認定されました。
継続更新タイトル：認定資格延長のお知らせ
SS：合格通知
おわりに
受験した感想（2023/07）
正直な感想として、身構えるほどの難易度ではなかった、というのが結論です。
これは Google Cloud の SIer として従事した経験というのも十分影響を与えていますが、「Associate Cloud Engineer」「Professional Cloud Architect」の2資格に合格できた人であれば正直難易度は高くないと感じると思います。
ACE＋PCA＋基本的なハイブリッド/マルチクラウドネットワークとアーキテクチャ設計およびネットワーク運用の理解があれば十分合格ラインを突破できる試験ですので、肩の力を抜いてラフに受験してみることをお勧めします。
（少なくとも日本語ローカライズされていない試験と比べれば言語の壁がないため難しくありません）
受験した感想（2025/07）
前回の受験時と同様に、ハードルは高くないと感じました。
前回同様に事前学習0で挑みましたが、全問即答できる程度に余裕をもって合格することができました✌
次回更新もがんばります！
まとめ
書き始め当初よりかなりボリューミーな記事となってしまいましたが、ここまで読んでいただきありがとうございます。
ここまで読破し理解を深めることができたならば、十分合格できる知識量をお持ちのはずです。
よい結果を迎えられることを祈ります。
また、当然試験内容は随時新しいものへ更新されてしまうため、この記事を閲覧された方は可能な限りお早めの受験を推奨します。
Views: 0
