0.はじめに
みなさん、こんにちは！Google Cloud 認定トレーナーのラリオスです。
突然ですが、告白します。私がこの Professional Cloud Network Engineer 試験を受験したとき、全 50 問のうち、実に 25 問に見直しのチェックを入れました。つまり、半分もの問題に「これが正解だ」と自信を持って解答できなかったんです！
結果としてなんとか合格することはできましたが、「本当にこれで大丈夫だろうか…」という不安な気持ちで試験時間を過ごしました。この記事は、これから受験するみなさんに、私と同じような心細い思いをしてほしくない、という強い気持ちで書きました。
さて、ハイブリッド クラウドやマルチクラウドが当たり前になった今、オンプレミス環境とクラウドを、いかにしてシームレスかつセキュアに連携させるか。この課題は、多くのプロジェクトで成功の鍵を握っています。
この複雑な要件を満たし、可用性、パフォーマンス、セキュリティのすべてを考慮した最適なネットワーク アーキテクチャを設計・構築する専門家、それが「Cloud Network Engineer」です。クラウドのポテンシャルを最大限に引き出すこの専門的な役割の重要性は、日々高まっています。
この記事は、そんなクラウド ネットワークのプロフェッショナルを目指すみなさんのために、合格に必要な知識と戦略をまとめた実践的なガイドです。
「広範なサービス群を、どう体系的に整理すればいいのか…」
「シナリオ問題で問われる “ベストプラクティス” の判断基準が知りたい…」
「各技術の細かな仕様や、サービス間の連携方法が曖昧…」
そんな課題を解決するため、この資格を持つ私が、Google Cloud の広範なネットワーク サービスを、合格に必要なポイントに絞って、実践的なシナリオと共に解説していきます。
この記事を読み終える頃には、知識が整理され、自信を持って試験に臨める状態になっているはずです。さあ、一緒に合格への一歩を踏み出しましょう！
1. Professional Cloud Network Engineer 試験の全体像
本格的な対策を始める前に、まずは試験の全体像を正確に把握することが合格への第一歩です。この試験がどのような知識を、どのように問うのかを理解し、学習の方向性を定めましょう。
試験の特徴｜知識だけでは通用しない「シナリオベース」
この試験の最大の特徴は、単一のプロダクト知識を問う問題が少なく、実際のビジネスシーンを想定した「シナリオベース」の問題が中心である点です。
問われるのは「なぜ、それを選ぶのか」
単に「Cloud VPN とは何か」を問うのではなく、「A 社にはこういう要件があるが、最適な接続方法はどれか」といった形で、技術選定の背景にある思考プロセスが問われます。コスト、可用性、運用負荷など、複数のトレードオフを考慮した上で、Google のベストプラクティスに沿った最適な回答を導き出す必要があります。
図はほぼ無し！長文を読み解く読解力
問題文は長く、詳細な状況設定がされているケースがほとんどです。一方で、構成図などが示されることは稀です。書かれたテキストから正確にネットワーク構成や要件をイメージし、課題を特定する読解力が不可欠です。
主な出題範囲
公式の試験ガイドでは、以下の 5 つのセクションが示されています。実際の業務フローに沿って構成されているのが分かります。
1. Google Cloud のネットワークの設計と計画
ビジネス要件に基づき、VPC やハイブリッド接続、IP アドレス計画などを設計する能力が求められます。
2. VPC の実装
共有 VPC や VPC ネットワーク ピアリングなどを用いて、実際に VPC を構築・設定するスキル。
3. ネットワーク サービスの構成
要件に応じて、適切なロードバランサや Cloud DNS、Cloud CDN などを構成する能力。
4. ハイブリッド接続の実装
Cloud VPN や Cloud Interconnect を用いて、オンプレミス環境とのセキュアな接続を確立するスキル。
5. ネットワーク セキュリティの実装
ファイアウォール ルール、Cloud Armor、VPC Service Controls などを駆使して、多層的なセキュリティを実装する能力。
2. 学習の心構え｜「もし自分ならどう設計するか」をつねに考える
この試験を攻略する上で最も重要なのは、つねに当事者意識を持つことです。「もし自分がこのプロジェクトのネットワーク担当者なら、何を考慮し、どう設計するか？」という視点で学習を進めてください。
各サービスを学ぶ際には、「この機能は何ができるのか」だけでなく、「どのような課題を解決するために存在するのか」「他のサービスとどう違うのか」という点を意識することが、シナリオ問題への対応力を養う鍵です。
3. 【最重要】頻出トピック別！合格を掴むための技術解説
ここからは、試験の合否を分ける重要な技術トピックについて、一つひとつ掘り下げていきます。各技術の概要はもちろん、「試験ではどのような観点で問われるのか」という点をとくに意識して解説します。
3.1. すべての基礎！VPC ネットワークの設計
Virtual Private Cloud （VPC）は、Google Cloud におけるネットワークの土台です。この VPC の設計思想をいかに理解しているかが、あらゆる問題で問われます。
▼ 試験での問われ方
「複数チームが利用するネットワークを、ガバナンスを効かせつつ効率的に管理したい」
「将来のサービス拡大を見据えた、スケーラブルな IP アドレス設計を行いたい」
といった、組織全体のネットワーク基盤設計に関するシナリオで、その知識が問われます。
▼ 押さえるべきポイント
共有 VPC （Shared VPC）
- 目的｜ネットワーク管理の一元化と、権限分離を実現します。
- 仕組み｜ネットワーク リソース（VPC、サブネット、ファイアウォール等）を持つ「ホスト プロジェクト」と、そのネットワークを利用する VM などのリソースを持つ「サービス プロジェクト」に分離します。
これにより、ネットワーク管理者は組織全体のポリシーを維持しつつ、各開発チームは自律的にリソースをデプロイできます。
シンプルな共有 VPC（公式ドキュメントより引用）
VPC モード（カスタム vs 自動）
本番環境の設計において、「自動モード」が選択肢に挙がることはまずありません。試験でも、IP アドレス範囲の重複回避や効率的な利用が求められるため、サブネットの IP 範囲を自由に定義できる 「カスタムモード」 が大前提です。
動的ルーティング モードの選択
ハイブリッド接続や複数リージョンにまたがるネットワーク設計では、Cloud Router の動的ルーティング モード（Regional / Global） の選択が通信の可否を左右する重要なポイントです。
-
仕組み ｜ Cloud Router 自体はリージョンリソースですが、オンプレミスなどから学習したルート情報を、どの範囲まで広めるかをこのモードで決定します。
-
Regional ｜Cloud Router と同じリージョンにのみ、動的ルートを広めます。
-
Global ｜VPC 内の全てのリージョンに、動的ルートを広めます。
運用時の監視ポイント
Cloud Router の動的ルートは、Cloud Monitoring の Cloud Router 関連メトリクス（学習ルート数 / 広告ルート数） に routing_mode（regional / global） の属性が付きます。アラート条件に routing_mode を含めておくと、誤設定や想定外のリージョン到達性の変化に素早く気づくことができます。
IP アドレス設計（とくに GKE）
Google Kubernetes Engine（GKE）の IP 戦略は、この試験の頻出トピックです。現在の GKE では VPC ネイティブ クラスタがデフォルトで、Pod には VPC サブネットのセカンダリ IP 範囲から直接 IP が割り当てられます。これにより、Pod は VM と同様に VPC 内で直接ルーティングされ、ネットワーク設計がシンプルになります。
| ノードあたりの最大 Pod 数 | ノードあたりの CIDR 範囲 | IP アドレスの数 |
|---|---|---|
| 8 | /28 | 16 |
| 9～16 | /27 | 32 |
| 17～32 | /26 | 64 |
| 33～64 | /25 | 128 |
| 65～128 | /24 | 256 |
| 129～256 | /23 | 512 |
GKE と Cloud NAT の連携
Cloud NAT は、外部 IP アドレスを持たない VM やプライベート GKE クラスタに、インターネットへのアウトバウンド（Egress）接続を提供するためのマネージドサービスです。この Cloud NAT を使い、プライベート GKE クラスタから出ていく通信をまとめたい、というのも試験の定番シナリオです。ここでのポイントは、GKE クラスタ内部の通信と、インターネット向けの通信を正しく区別することです。
仕組み ｜ GKE の ip-masq-agent（IP マスカレード エージェント） という仕組みを利用して、VPC 内部やオンプレミス宛など、プライベートな通信は送信元 IP アドレスをそのまま保持します（SNAT しない = マスカレードしない）。一方で、それ以外のインターネット向けの通信のみ、Cloud NAT を経由して SNAT（送信元 IP アドレスの変換）を行うように設定します。
※ 技術的には、「SNAT」と「マスカレード」は、ほぼ同じ意味で使われますが、GKE のコンテキストでは「Pod の IP を Node の IP に変換する」という具体的な動作を指します。
GKE と Cloud NAT の落とし穴（SNAT をどこまで統一するか）ip-masq-agent の nonMasqueradeCIDRs（SNAT しない宛先リスト）の設定が不適切だと、VPC 内部やオンプレミス宛のプライベート通信まで Cloud NAT を経由してしまう可能性があります。
設計のコツ｜通信の種類に応じて SNAT の要否を明確に分離しますnonMasqueradeCIDRs は「GKE ノードで SNAT を しない 宛先リスト」であるという原則をつねに意識します。
基本的な考え方（主にプライベートクラスタ）
- 目的 ｜プライベート通信とインターネット通信を分離したい。
-
プライベート通信（VPC 内、オンプレ） ｜
nonMasqueradeCIDRsに含める → Pod IP のまま通信（SNAT しない）。 -
インターネット通信 ｜
nonMasqueradeCIDRsから除外する → Cloud NAT で SNAT される。 - 覚え方 ｜「内部は素通し、外部は NAT 経由」
応用的な考え方（主にパブリッククラスタ）
- 目的 ｜デフォルトの動作（ノードの外部 IP で SNAT）を上書きし、特定のインターネット宛通信を Cloud NAT 経由にしたい。
-
Cloud NAT を使いたい特定のインターネット宛先 ｜
nonMasqueradeCIDRsに含める → ノードでの SNAT を抑制し、Cloud NAT に処理を委ねる。
実装例 1. 基本的な構成（主にプライベートクラスタ）
- プライベート GKE クラスタで、オンプレミス（
10.0.0.0/8）には Pod IP のまま、インターネットへは Cloud NAT 経由にしたい場合
nonMasqueradeCIDRs:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
実装例 2. 応用的な構成（主にパブリッククラスタ）
- プライベート通信は Pod IP のままにしつつ、特定のインターネット宛先（例｜
35.100.0.0/16）だけを Cloud NAT 経由にしたい。（それ以外のインターネット通信は、従来通りノードの外部 IP を使わせる）
nonMasqueradeCIDRs:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- 35.100.0.0/16
Cloud NAT（Cloud Girl から引用）
サーバーレスからの VPC 接続
Cloud Run、Cloud Functions、App Engine などのサーバーレス サービスから、VPC 内のリソース（VM や Cloud SQL など）へプライベートにアクセスする方法も、試験範囲に含まれます。接続方法は 2 つあり、それぞれの特性を理解しておく必要があります。
Serverless VPC Access（コネクタ利用）
- 仕組み ｜VPC 内に「コネクタ」と呼ばれるマネージドな VM インスタンスを起動し、これを経由して VPC へアクセスします。
- 特徴 ｜設定は比較的容易で、IP アドレスの消費はコネクタのインスタンス数に応じて固定的です。しかし、コネクタの起動時間やスループット制限、VM 稼働コストが発生します。
Direct VPC Egress（ダイレクト VPC 下り）
- 仕組み ｜サーバーレス インスタンスから直接 VPC へトラフィックを送信します。コネクタは不要です。
- 特徴 ｜コネクタ方式に比べて高パフォーマンス（低遅延・高スループット）で、コスト効率も優れています。ただし、対応サービスや世代が限定される場合があります（例丨Cloud Run や 第 2 世代 Cloud Functions）。
- 注意点 ｜IP アドレスの消費モデルが異なります。Direct VPC Egress はスケールアウト時に /28（16 IP）単位などで IP ブロックを動的に予約することがあります。IP アドレス空間が限られているサブネットでは、この動作を考慮した設計が必要です。
エンタープライズ設計パターン｜ハブ ＆ スポーク
大規模な組織では、部門や環境（本番、開発など）ごとに VPC を分離しつつ、管理の効率化とセキュリティの確保のために「ハブ ＆ スポーク」モデルが広く採用されます。
中心となる「ハブ（Hub）」VPC を設け、各環境（「スポーク（Spoke）」VPC やオンプレミス）はハブにのみ接続します。
- 目的｜接続性の集約（オンプレミス接続などをハブに集約）、セキュリティの一元化（ハブで通信を検査）、ルーティングの簡素化。
Google Cloud でこれを実現するには、主に 3 つのアプローチがあり、試験では要件に応じた最適なパターンの選択が問われます。
パターン 1. 共有 VPC（Shared VPC）
最も推奨される基本的なアプローチです。ホストプロジェクトがハブ（ネットワーク基盤）を提供し、サービスプロジェクトがスポーク（リソース配置先）となります。
- 特徴｜ネットワークリソースはハブ（ホストプロジェクト）で一元管理されます。単一の VPC ネットワークを共有するため、スポーク（サービスプロジェクト）間は、デフォルトで（ファイアウォールで許可されていれば）直接通信可能です。
- 最適なシナリオ｜組織内のガバナンスを強化し、ネットワーク管理とリソース管理の責任を明確に分離したい場合。
パターン 2. VPC ネットワーク ピアリングによるハブ ＆ スポーク
ハブ VPC と複数のスポーク VPC を、VPC ネットワーク ピアリングで接続する構成です。
- 特徴｜各 VPC は独立した管理ドメインを持ちます。
- 制約（重要）｜VPC ネットワーク ピアリングは推移的ではありません。デフォルトでは、スポーク A → ハブ → スポーク B という通信はできません。スポーク間通信が必要な場合は、スポーク同士を直接ピアリングする（フルメッシュ）か、後述する NVA を利用する必要があります。
- 最適なシナリオ｜各部門や子会社が VPC の管理権限を持ちたいが、特定の共有サービス（ハブ）への接続が必要な場合。
パターン 3. Network Connectivity Center（NCC）
NCC をハブとして利用し、VPCスポークやハイブリッドスポーク（VPN / Interconnect）を接続する構成です。
- 特徴｜推移的なルーティングをサポートし、スポーク間の動的な接続をシンプルに実現できます。VPC ネットワーク ピアリングの複雑なメッシュ構成やクォータ（上限数）の問題を解決します。
- 最適なシナリオ｜多数の VPC やオンプレミス拠点を相互接続する、大規模で複雑なネットワークをシンプルに管理したい場合。
高度な通信制御｜NVA（Network Virtual Appliance）の活用
セキュリティ要件で「スポーク間の通信はすべてハブで検査したい」という場合があります。共有 VPC や NCC ではスポーク間が直接通信してしまうため、これを制御するには工夫が必要です。
- 解決策｜ハブ VPC に NVA（Network Virtual Appliance｜サードパーティ製の仮想ファイアウォールなど） を配置し、カスタムルートを使ってスポーク間のトラフィックが必ず NVA を経由するように誘導します。
-
仕組み（VPC ネットワーク ピアリングの場合）
- ハブ VPC で、スポーク VPC へのネクストホップを NVA の IP アドレスに向けるカスタムルートを作成します。
- VPC ネットワーク ピアリング設定で、このカスタムルートをスポーク VPC へエクスポートします。
- スポーク VPC は、他のスポークへの通信をハブ VPC の NVA 経由で行うようになります。
3.2. 試験の最重要関門！ハイブリッド / マルチクラウド接続
オンプレミス環境と Google Cloud を接続するハイブリッド接続は、この試験で最も重要かつ頻出のトピックです。とくに、要件に応じた適切な接続方式の選択と、可用性の設計が繰り返し問われます。
▼ 試験での問われ方
「オンプレミスのデータセンターと Google Cloud を、可用性 99.99% と 10 Gbps の帯域を確保しつつ接続したい。コストを最適化する構成はどれか」
といった、具体的な SLA や帯域、コストの要件を満たすためのアーキテクチャ設計力が試されます。
▼ 押さえるべきポイント
Cloud Interconnect vs Cloud VPN
ハイブリッド接続の選択肢は、この 2 つが基本です。どちらを選ぶかは、要件によって決まります。
Cloud Interconnect（専用線 / パートナー接続）
- 目的 ｜高帯域、低遅延、高信頼なプライベート接続を実現します。
- 特徴 ｜Google のエッジロケーションまで物理的な専用線を引く（Dedicated Interconnect）か、パートナー事業者のネットワークを経由して接続します（Partner Interconnect）。インターネットを経由しないため、安定したパフォーマンスと高いセキュリティが期待できます。
HA VPN
- 目的 ｜インターネット経由で、セキュアな IPsec VPN 接続を確立します。
- 特徴 ｜Cloud Interconnect に比べて低コストかつ短期間で導入できます。HA VPN は、Google 側で 99.99% の SLA を提供するよう設計されており、2 つのトンネルで冗長化された構成が標準です。
可用性 99.99% を実現する冗長構成
この試験では、可用性 99.99% を実現するための具体的な構成が頻繁に問われます。これは Google Cloud の SLA で定義された構成を正しく理解しているかを確認するためです。そして、鍵となるのは 「障害ドメインの分離」 です。
Interconnect の場合 (99.99% SLA)
異なる 2 つのメトロ（都市圏） において、それぞれ異なるエッジ アベイラビリティ ドメイン（EAD）に接続します。また、少なくとも 2 つの Google Cloud リージョンに Cloud Router と VLAN アタッチメントを構成し、VPC の動的ルーティング モードを Global に設定する必要があります。（※同一メトロ内での 2 接続は 99.9% SLA です）
99.99% の可用性のための冗長接続（公式ドキュメントより引用）
HA VPN の場合
Google Cloud が提供する 99.99% の可用性 SLA は、Google Cloud 側の構成で定義されます。
SLA 要件（Google Cloud 側） ｜HA VPN ゲートウェイが持つ 2 つのインターフェースから、それぞれピアゲートウェイ（オンプレミス側）に対してトンネルが確立されていること（合計 2 本のトンネル）。オンプレミス側が 1 台のゲートウェイであっても、この条件を満たせば SLA は提供されます。
ベストプラクティス（エンドツーエンド） ｜実際の運用では、オンプレミス側の機器障害にも備える必要があります。Google 側の HA VPN ゲートウェイ（2 インターフェース）と、オンプレミス側の冗長化されたゲートウェイ（2 台、または 1 台 2 インターフェース）の間で、合計 4 つの VPN トンネル（2 × 2） を構成し、動的ルーティング（BGP）を有効にすることで、エンドツーエンドでの高い可用性を実現します。
Interconnect と HA VPN の併用｜BGP で経路を制御する
実際の運用では、安定性とコストのバランスを取るために、Cloud Interconnect を主系（プライマリ）、HA VPN を副系（バックアップ） として併用する構成が一般的です。この自動切り替えを実現するのが、動的ルーティング プロトコルである BGP です。
Network Connectivity Center（NCC）
- 目的 ｜複数の VPC やオンプレミス拠点を、ハブ & スポーク モデルでシンプルに相互接続します。
- 仕組み ｜NCC を「ハブ」とし、各 VPC やオンプレミスへの接続（VPN、Interconnect、SD-WAN）を「スポーク」として登録することで、スポーク間の動的なルーティングを実現します。
スポークを VPC ネットワークに接続する（公式ドキュメントより引用）
3.3. ユースケースで選ぶ！ロードバランサの適切な選択
Google Cloud のロードバランサは多機能かつ種類が豊富ですが、試験で問われるのは「どのシナリオで、どのロードバランサを選択するのが最適か」という判断力です。選定のポイントは明確な判断軸（デシジョンツリー）に沿って整理すると理解しやすくなります。
▼ 試験での問われ方
「世界中のユーザーに HTTPS サービスを低遅延で提供し、Cloud Armor による保護も行いたい」
「VPC 内のマイクロサービス間で、高スループットな TCP 通信を実現したい」
といった、トラフィックの特性や要件に応じた最適なロードバランサの選択が問われます。
▼ 押さえるべきポイント
ロードバランサの選定は、以下の流れで考えます。
トラフィックの向きは？（外部 or 内部）
- 外部（External） ｜インターネットからのトラフィックを受ける場合。
- 内部（Internal） ｜Google Cloud 内部（VPC 内や接続されたオンプレミスから）のトラフィックを処理する場合。
トラフィックの範囲は？（グローバル or リージョン）
- グローバル（Global） ｜複数のリージョンにまたがるバックエンドにトラフィックを分散させたい場合。単一のエニーキャスト IP アドレスで世界中からのアクセスを受け付けます。
- リージョン（Regional） ｜ 単一リージョン内のバックエンドにのみトラフィックを分散させる場合。
トラフィックのプロトコルは？（HTTPS、TCP、UDPなど）
- HTTPS / HTTP｜Application Load Balancer を選択します。SSL オフロード、パスベースのルーティング、Cloud Armor との連携といった高度な機能を利用できます。
- TCP / UDP｜Network Load Balancer を選択します。こちらはパケットをそのままバックエンドに転送する（パススルー型）か、プロキシとして終端するか（プロキシ型）を選択できます。
動作モードは？（プロキシ型 or パススルー型）
プロトコルと合わせて、ロードバランサがどのようにトラフィックを処理するか（動作モード）も重要な選定軸です。
プロキシ型（Proxy）
- 仕組み ｜ロードバランサがクライアントからの接続を一度終端し、バックエンドへ新しい接続を確立します。
- 特徴 ｜L7 の高度な機能（例｜URL マップ、SSL オフロード）を利用できますが、バックエンドからはクライアントの送信元 IP を直接認識できません（X-Forwarded-For ヘッダなどで確認）。
- 該当サービス ｜Application Load Balancer、Proxy Network Load Balancer。
パススルー型（Pass-through）
- 仕組み ｜ロードバランサは接続を終端せず、パケットをそのままバックエンドへ転送します。
- 特徴 ｜バックエンドがクライアントの送信元 IP を直接認識できます。非常に高いパフォーマンスを発揮しますが、L7 の機能は利用できません。
- 該当サービス ｜Pass-through Network Load Balancer。
ロードバランサの選択（公式ドキュメントより引用）
▼ 試験で頻出のロードバランサ
グローバル外部アプリケーション ロードバランサ
- ユースケース ｜世界中に展開する Web サービス、API ゲートウェイなど。
リージョン内部パススルー ネットワーク ロードバランサ
- ユースケース ｜VPC 内の 3 層アーキテクチャにおける、Web サーバーから App サーバーへの TCP 通信など。
リージョン内部アプリケーション ロードバランサ
- ユースケース ｜VPC 内のマイクロサービス間での、パスベースルーティングを伴う HTTP / HTTPS 通信。
ロードバランサの構築前のチェックリストと注意点
ロードバランサの構築でつまずかないために、設計段階で確認すべき共通のポイントと、よくある「落とし穴」を整理しておきましょう。
ヘルスチェック用のファイアウォール設定｜疎通確認の基本
ロードバランサが正常に動作しない原因として最も多いのが、このヘルスチェックの疎通失敗です。ロードバランサは、バックエンドの VM やコンテナが正常に応答するかを定期的に確認しています。この通信がファイアウォールでブロックされていると、バックエンドは「不健康（UNHEALTHY）」と判断され、トラフィックが転送されません。
proxy-only サブネットの要否
これは特定のプロキシベースのロードバランサ（リージョン内部 / 外部アプリケーション LB など）で必須となる、Google が管理する特殊なサブネットです。Google 管理の L7 プロキシ（Envoy）用に proxy-only サブネットの IP を確保します。
Cloud CDN の注意点｜よくある設定ミスと対策
グローバル外部アプリケーション ロードバランサと組み合わせて利用する Cloud CDN は非常に強力ですが、設定を間違えると意図通りに動作しません。試験でも、キャッシュが効かないシナリオの原因特定が問われます。
Cloud Storage との連携｜正しい構成を理解する
静的コンテンツの配信元（オリジン）として Cloud Storage を使うのは定番の構成ですが、注意が必要です。Cloud Storage バケットを直接 CDN に設定することはできません。
キャッシュが効かない？｜確認すべき3つのポイント
「CDN を有効化したのに、キャッシュヒット率が上がらない」という問題では、以下の点を確認します。
オリジンの応答ヘッダ
Cloud Storage や Web サーバーが返す HTTP ヘッダ（Cache-Control、Expires）で、キャッシュが許可されているか。
キャッシュキーの最適化
デフォルトでは、URL のクエリ パラメータもキャッシュを区別するキーに含まれます。広告キャンペーンなどで使われる ?utm_xxx=... のようなパラメータをキャッシュキーから除外しないと、同じコンテンツでも別々にキャッシュされてしまい、ヒット率が低下します。
ネガティブ キャッシュ404 Not Found や 301 Redirect といったエラー応答も、短時間キャッシュ（ネガティブ キャッシュ）することで、オリジンへの不要な負荷を減らせます。
3.4. 多層防御を意識！ネットワーク セキュリティ
クラウド ネットワークの設計において、セキュリティは切り離せない要素です。この試験では、複数のセキュリティ サービスを適材適所で組み合わせ、多層的な防御を実現する能力が問われます。
▼ 試験での問われ方
「組織全体のファイアウォール ポリシーを一元管理しつつ、特定の VM へのアクセスはサービス アカウント ベースで制御したい」
「Web アプリケーションを OWASP Top 10 の脅威から保護したい」
「VPC 内のリソースから、許可された Google API へのアクセスのみを許可し、データの持ち出しを防ぎたい」
といった、ゼロトラストの原則に基づいた具体的なセキュリティ要件を満たすための設計が問われます。
▼ 押さえるべきポイント
VPC ファイアウォール vs 階層型ファイアウォール
どちらも通信を制御する機能ですが、適応されるスコープが異なります。
- VPC ファイアウォール ルール ｜特定の VPC ネットワークに適用されます。各プロジェクトの VPC ごとに設定が必要です。
- 階層型ファイアウォール ポリシー ｜組織またはフォルダ単位でポリシーを定義し、配下にある全てのプロジェクトの VPC に強制的に適用できます。
ファイアウォール制御のベストプラクティス（タグ vs サービスアカウント）
VPC ファイアウォール ルールで通信の対象（ターゲット）や送信元を指定する方法には、「ネットワーク タグ」と「サービス アカウント」があります。セキュリティと権限分離の観点から、Google Cloud ではサービス アカウントの使用が強く推奨されています。
ネットワーク タグ
VM インスタンスの編集権限を持つユーザーであれば、自由に変更できてしまいます。これにより、意図せずファイアウォール ルールが適用されたり、外されたりするリスクがあります。
サービス アカウント
VM に紐づけるサービス アカウントは IAM によって厳密に制御されます。ネットワーク管理者が意図した通りのポリシーを、よりセキュアに適用できます。
Cloud Armor
- 目的 ｜Google のエッジ ネットワーク上で、DDoS 攻撃や Web ベースの攻撃（SQL インジェクション、クロスサイト スクリプティングなど）からアプリケーションを保護します。
- 仕組み ｜グローバル外部アプリケーション ロードバランサ と組み合わせて使用する WAF（Web Application Firewall）サービスです。
Cloud Armor（公式ブログより引用）
VPC Service Controls
- 目的 ｜データ漏洩のリスクを防ぐための、非常に強力なセキュリティ機能です。
- 仕組み ｜ファイアウォールが VM 間の通信（North-South / East-West トラフィック）を制御するのに対し、VPC Service Controls は Google マネージド サービス（Cloud Storage や BigQuery など）への API アクセスを制御します。サービス境界（Service Perimeter）を作成し、境界の外部からのアクセスや、境界の内部から外部へのデータの持ち出しをブロックします。
より高度な脅威検知と防御｜主要サービスの役割分担
多層防御をさらに強化するためには、目的の異なる複数のセキュリティサービスを使い分けることが重要です。とくに以下の 3 つのサービスの守備範囲を正しく理解することが、試験問題を解く上で重要です。
Cloud NGFW (Cloud Next Generation Firewall)
- 守備範囲 ｜VPC 内部の通信（East-West）、および VPC と外部間の通信（North-South / Ingress および Egress）。
- 役割 ｜従来の VPC ファイアウォール（L4 制御）に加え、侵入防止サービス（IPS）による脅威検知や、FQDN（ドメイン名）に基づいた高度な通信制御（L7）を行います。VPC 境界および内部における包括的な脅威対策を提供します。
Secure Web Proxy
- 守備範囲 ｜VPC からインターネットへの Web アクセス（Egress / アウトバウンド）。
- 役割 ｜いわゆる「アウトバウンド Web プロキシ」です。「開発用の VM から、特定のライブラリ配布サイトへのアクセスのみを許可したい」といった、URL やドメイン名ベースでのきめ細かなアウトバウンド制御が必要な場合に選択します。
Cloud Armor
- 守備範囲｜ インターネットから Google Cloud への Web トラフィック（Ingress / インバウンド）。
- 役割 ｜ 先述の通り、Google のネットワークエッジで Web アプリケーションを保護する WAF および DDoS 対策サービスです。
守備範囲の整理
| サービス | インバウンド (Ingress) | アウトバウンド (Egress) | East-West (VPC内部) | 主な機能 |
|---|---|---|---|---|
| Cloud NGFW | 〇 | 〇 | 〇 | IPS、FQDN 制御、L7 検査 |
| Secure Web Proxy | × | ◎ （Web） |
× | URL / ドメイン制御（外向き） |
| Cloud Armor | ◎ （Web） |
× | × | WAF、DDoS 対策 |
| VPC ファイアウォール | 〇 | 〇 | 〇 | L4 制御 （IP / ポート） |
3.5. ハイブリッドの要！DNS と限定公開アクセス
ハイブリッド環境では、オンプレミスと Google Cloud のリソースが、お互いの名前を正しく解決（名前解決）できる必要があります。また、セキュリティの観点から、Google の各種サービスへインターネットを経由せずにアクセスしたい、という要件も頻繁に登場します。
▼ 試験での問われ方
「オンプレミスのサーバーが、外部 IP を持たない Google Cloud の VM のホスト名を解決できるようにしたい」
「オンプレミスから Cloud Storage にアクセスしたいが、インターネット経由は許可できない。どうすればよいか」
といった、ハイブリッド環境における名前解決とセキュアなアクセス経路の設計が問われます。
▼ 押さえるべきポイント
Google サービスへのプライベート接続オプション（PGA、PSA、PSC）
Google Cloud のリソースから、Google のマネージド サービス（Cloud Storage、BigQuery、Cloud SQL など）へ、インターネットを経由せずにプライベートに接続する方法は複数あります。試験では、これらの違いと使い分けが頻繁に問われます。
Private Google Access（PGA） – 限定公開の Google アクセス
- 目的 ｜VM などから Google API（Cloud Storage、BigQuery など）へ、Google の内部ネットワーク経由でアクセスします。
-
仕組み ｜サブネット単位で有効化します。
*.googleapis.comへの通信が特別に扱われます。 - ユースケース ｜外部 IP のない VM から gcloud コマンドを実行するなど。
Private Service Access（PSA） – プライベート サービス アクセス
- 目的 ｜特定の Google マネージド サービス（Cloud SQL、Memorystore など）と、ユーザーの VPC をプライベートに接続します。
- 仕組み ｜Google が管理する VPC とユーザーの VPC を「VPC ネットワーク ピアリング」で接続します。そのため、事前に VPC 内に IP アドレス範囲を予約する必要があります。
- ユースケース ｜VPC 内から Cloud SQL インスタンスのプライベート IP へ接続するなど。
Private Service Connect（PSC） – プライベート サービス コネクト
- 目的｜他の VPC で公開されているサービスや、Google API へ、柔軟かつセキュアに接続します。
- 仕組み ｜VPC 内に「エンドポイント（プライベート IP アドレス）」を作成し、それを経由して対象のサービスへアクセスします。VPC ネットワーク ピアリングを使わないため、IP アドレスの重複を気にする必要がありません。
- ユースケース ｜SaaS プロバイダが提供するサービスへの接続、組織内の部門間でのセキュアなサービス連携など。
Cloud DNS｜双方向の名前解決を実現する
ハイブリッド環境をシームレスに連携させるには、オンプレミスから Google Cloud へ、そして Google Cloud からオンプレミスへ、双方向でのプライベートな名前解決が不可欠です。Cloud DNS は、この双方向解決を実現するための2つの重要な機能を提供します。
オンプレミス → Google Cloud の名前解決（Inbound）
-
目的 ｜オンプレミスのサーバーが、VPC 内の VM のホスト名（例｜
server1.asia-northeast1-a.c.my-project.internal）などを解決できるようにします。 -
仕組み ｜VPC に 「受信サーバー ポリシー」 を作成します。これにより、オンプレミスからの DNS クエリを受け付けるための専用の IP アドレス（エントリポイント）が VPC 内に作成されます。オンプレミス側の DNS サーバーで、Google Cloud 側のドメイン（例｜
.internal）に関する問い合わせを、この IP アドレスに転送（フォワード）するよう設定します。
Google Cloud → オンプレミスの名前解決（Outbound）
-
目的｜Google Cloud の VM が、オンプレミスの社内サーバー（例｜
fileserver.corp.example.com）の名前を解決できるようにします。 -
仕組み ｜Cloud DNS に 「フォワーディング ゾーン」 を作成します。ここで、社内ドメイン（例｜
corp.example.com）の名前解決を、オンプレミスの DNS サーバーの IP アドレスに転送するよう設定します。
VPC 間の名前解決（DNS Peering）
複数の VPC が存在する場合、VPC をまたいだ名前解決が必要になることがあります。
- 目的 ｜VPC-A から、VPC-B に関連付けられた Cloud DNS プライベート ゾーンの名前を解決できるようにします。
- 仕組み ｜Cloud DNS に「ピアリング ゾーン（Peering zone）」を作成し、名前解決の要求をターゲットとなる VPC（VPC-B）へ転送します。
- 特徴｜VPC ネットワーク ピアリングでネットワークが接続されていなくても、名前解決だけを共有することが可能です。
オンプレミスからの限定公開の Google アクセス｜VIP を使い分ける
- 目的 ｜オンプレミスのホストから、インターネットを経由せずに Cloud Storage や BigQuery などの Google API へセキュアにアクセスします。
- 仕組み ｜DNS とルーティングを組み合わせ、Google API への通信を閉域網（VPN / Interconnect）経由に誘導します。この際に利用するのが、VIP（Virtual IP Address） と呼ばれる特別な IP アドレス範囲です。
3.6. 運用とトラブルシューティング
ネットワークは構築して終わりではありません。安定して稼働しているかを監視し、問題が発生した際には迅速に原因を特定して解決する必要があります。この試験では、Google Cloud が提供するモニタリング・トラブルシューティングツールを、状況に応じて適切に使い分ける能力が問われます。
▼ 試験での問われ方
「ある VM から特定の宛先への通信ができない。ファイアウォールでブロックされているのか、ルーティングの問題なのかを切り分けたい」
「最近ネットワークのレイテンシが悪化しているように感じる。どの経路で遅延が発生しているか可視化したい」
といった、具体的なトラブルシューティングのシナリオで、最も効率的なツールの選択が問われます。
▼ 押さえるべきポイント
トラブルの発生時、やみくもに調査を始めるのではなく、症状に応じて最適なツールを素早く選択することが、迅速な解決の鍵です。試験では、特定の症状に対して、どのツールを「最初の一手」として使うべきかが問われます。
Connectivity Tests
ネットワークの 2 点間（例｜VM と VM、VM とオンプレミス ホスト）の到達可能性をテストし、その経路上の設定（ルート、ファイアウォール、ロードバランサなど）を総合的に分析します。
Firewall Insights
ファイアウォール ルールの利用状況を分析し、構成の最適化や意図しない通信のブロックを特定するのに役立ちます。
Network Intelligence Center
Google Cloud のリージョン間、および Google Cloud とインターネット間のネットワーク レイテンシとパケットロスを可視化します。
Network Intelligence Center（Cloud Girlより引用）
VPC フローログ
VPC 内の VM インスタンスによって送受信されるネットワーク フロー（IP トラフィック）を記録、サンプリングし、可視化します。
Packet Mirroring
実際のネットワーク パケットをキャプチャし、分析用の VM（コレクタ）などに転送します。
4. 【試験直前】最終チェック！重要ポイント総ざらい
ここまでの学習お疲れ様でした。このセクションでは、試験直前に見直すことで、知識を確実に得点に結びつけるための重要ポイントをまとめました。
▼ 合格に必須！重要サービス・用語チェックリスト
共有 VPC（Shared VPC）
ネットワーク管理を一元化。ホストプロジェクトとサービスプロジェクトの概念を再確認。
HA VPN
SLA 99.99% を提供するインターネット VPN。オンプレ側も冗長化することでエンドツーエンドの高可用性を実現。
Cloud Interconnect（Dedicated / Partner）
高帯域・低遅延な閉域網接続。99.99% SLA のための冗長構成要件（複数リージョン、複数メトロ）は必須知識。
Network Connectivity Center
複数拠点（VPC、オンプレミス）をハブ & スポークで接続。推移的ルーティングを実現。
グローバル外部アプリケーション LB
HTTPS、グローバル、Cloud Armor、Cloud CDN とセットで覚える。
階層型ファイアウォール
組織・フォルダ単位での一元的なファイアウォール管理。ガバナンス強化。
VPC Service Controls
データ漏洩対策の切り札。サービス境界（Perimeter）で API アクセスを制御。
private.googleapis.com
オンプレミスから閉域網経由で Google API にアクセスするための VIP。
restricted.googleapis.com
VPC Service Controls と連携し、対応サービスへのアクセスのみを許可する VIP。
Connectivity Tests
接続性の問題が発生した際の、最も効率的なトラブルシューティングツール。
▼ シナリオ別・アーキテクチャ選択パターン集
高帯域（＞10Gbps）、安定した低遅延、閉域網での接続
→ Cloud Interconnect（Dedicated）
コストを抑えつつ、迅速にSLA 99.99% の暗号化接続を実現
→ HA VPN
複数 VPC とオンプレミス拠点を、メッシュ構成を避けてシンプルに相互接続
→ Network Connectivity Center（NCC）
組織全体で SSH（TCP / 22）へのアクセスを原則禁止したい
→ 階層型ファイアウォール ポリシー
Web サイトを DDoS 攻撃や SQL インジェクションから保護したい
→ グローバル外部アプリケーション LB + Cloud Armor
機密データ（BigQuery）へのアクセスを、特定の VPC からのみに制限したい
→ VPC Service Controls
▼ 間違えやすいポイント Top 7
1. VPC ネットワーク ピアリングは推移的ではない！
VPC-A と VPC-B、VPC-B と VPC-C をピアリングしても、VPC-A と VPC-C は直接通信できません。この要件がある場合は Network Connectivity Center を検討します。
2. private.googleapis.com と restricted.googleapis.com の違い
どちらも閉域網からのアクセスに使いますが、restricted は VPC Service Controls をサポートするサービスのみに制限する点が異なります。データ漏洩対策の文脈では restricted が選ばれます。
3. Google Cloud からの（オンプレミス向け）DNS クエリ送信元 IP
Cloud DNS 転送ゾーン（Outbound）を利用して Google Cloudからオンプレミスへ転送する際、オンプレミス側で許可すべき Google Cloud からの DNS クエリの送信元 IP は 35.199.192.0/19 です。このアドレスをファイアウォールで許可する必要があります。
4. Cloud Armor のログはどこに出力される？
Cloud Armor のログは、関連付けられたロードバランサのロギングを有効化することで、Cloud Logging に出力されます。Cloud Armor 自体にはロギング設定はありません。
5. 内部 LB のアクセス範囲（リージョン vs クロスリージョン）
内部ロードバランサ（とくにアプリケーション LB）には、リージョン版と クロスリージョン版 があります。バックエンドが複数リージョンに分散しており、リージョン障害時の自動フェイルオーバーが必要な場合はクロスリージョン版を検討します。
6. Cloud NAT はリージョン単位（「1 台で全リージョン」は不可）
Cloud NAT はリージョン リソースです。VM（または該当リソース）が属するリージョンにある Cloud NAT しか使えません。たとえば、us-central1 と asia-northeast1 に VM がある場合、各リージョンに Cloud NAT を作成し、それぞれの 対象サブネット（または MIG / タグ） を関連付けます。1 つの NAT でグローバルに対応することはできません。
7. NCC（Network Connectivity Center）移行時のアドバタイズ衝突を「除外」で回避
VPC ネットワーク ピアリングのメッシュから NCC（ハブ ＆ スポーク） へ移行する際に起こりがちなのが、重複 / 競合プレフィックスの広報です。VPC スポーク登録時の「除外レンジ（exclude-export-ranges）」を使えば、特定の宛先プレフィックスをハブへ広告しないよう制御でき、段階移行でも衝突を避けられます。
5. まとめ｜自信を持って試験に臨もう！
今回は、Professional Cloud Network Engineer 試験合格に向けて、VPC 設計からハイブリッド接続、ロードバランサ、セキュリティ、そして運用まで、重要となるトピックを網羅的に解説してきました。
この試験で問われる知識は、単なる資格取得のためだけのものではありません。クラウドとオンプレミスが複雑に連携する現代の IT システムにおいて、ネットワークはすべてを支える土台であり、その設計スキルはプロジェクトの成否を左右する、極めて重要な要素です。
ここで学んだ設計思想やサービス選択の判断軸は、みなさんが今後、より複雑で大規模なプロジェクトを成功に導くための、強力な武器になると考えています。この記事で整理した知識とパターンを自信に変えて、試験に臨んでください。
みなさんの合格を、心から応援しています！
Views: 0
