G-gen の杉村です。Professional Cloud Network Engineer は Google Cloud のプロフェッショナルレベルの認定資格の1つです。Google Cloud のネットワーク系サービスに関する高度な知識を確認する難関試験です。当記事では、試験の合格に役立つ Tips、勉強方法、出題傾向等を紹介します。

概要

Professional Cloud Network Engineer 試験について

Professional Cloud Network Engineer 試験は、Google Cloud のネットワーク系サービスや専用線、VPN 等に関する知識が問われる、Google Cloud の認定試験です。

試験問題は50〜60問、試験時間は120分です。英語版と日本語版が提供されています。

当試験では問題文が長く、複雑なネットワーク構成が文章で説明されるため、ネットワーク設計に慣れていないと読み解きに時間がかかることが想定されます。構成図で説明してくれるような問題は無く、問題文をしっかり読み解く必要があります。

参考 : Professional Cloud Network Engineer

難易度

Professional Cloud Network Engineer 試験の難易度は、中〜高程度だと言えます。

当試験では、VPC や専用線、Network Connectivity Center などを中心に、Google Cloud のネットワークの仕様に関する深い知識が問われます。また、Cloud DNS を複数の VPC ネットワークから、あるいはオンプレミスから利用するなどの特別なユースケースに関する問題も問われます。

公式の試験要項には「業界経験が 3 年以上（Google Cloud を使用したソリューションの設計と管理の経験 1 年以上を含む）。」という要件が記載されていますが、必ずしもここまでの経験は必要ありません。 Google Cloud に関する Professional Cloud Architect 程度の知見に加えて、一般的なネットワーク技術の知見、特にルーティングやファイアウォールなどに関する知識を持っていることが望ましいです。とはいえ、Google Cloud の VPC は独特の仕様を持っていますので、一般的な知識に加えて、Google Cloud 特有のネットワーク仕様をしっかりと学んでおく必要があります。

勉強方法

推奨の勉強方法は、以下となります。

試験ガイドを読む
試験ガイドで把握した試験範囲について勉強する
この際 Google Cloud に限らない一般的なネットワーク知識についても穴埋めをする
模擬試験を受ける
当記事を読み、出題傾向を把握し、知らない知識を穴埋めする

特に VPC ネットワークや Cloud VPN などについて、実際に検証環境を構築してみることをお勧めします。コンソールの構築画面や CLI のコマンド構造を見ることで、Google Cloud のリソース構成が直感的に理解できるため、理解が飛躍的に進みます。

ルーティングや Cloud DNS、Cloud Interconnect などについては、以下の書籍が設計要素などについて詳しく解説しており、オススメです。

参考 :

ネットワーク基礎知識

当試験の出題内容を適切に理解するには、Google Cloud の知識以前に、一般的なネットワーク用語（特に L3 〜 L4 レイヤ）を理解している必要があります。もし以下のような用語の概要を理解していない場合、まずはそこから学習することを強く推奨します。

TCP/IP 参照モデル、OSI 参照モデル、TCP、UDP、IP、パケット、フレーム
ルーター、ルーティング、ルート（経路）、ルート広報（Advertisement）、ネクストホップ
ネットワーク、サブネット、VLAN
ルーティングプロトコル、BGP、AS 番号（ASN）
ファイアウォール、ステートフルインスペクション、ステートレスインスペクション、L3/L4 レイヤネットワークセキュリティ
Web Application Firewall（WAF）、IPS/IDS、L7 レイヤネットワークセキュリティ
NAT（Network Address Translation）
ロードバランシング
HTTP、HTTPS、SSL/TLS、証明書、非対称暗号化
専用線、インターネット VPN、IPSec
DNS、ドメインツリー、権威 DNS サーバー、ゾーン、ゾーンフォワーディング

Google Cloud 知識

VPC のルーティングや専用線、Network Connectivity Center、Cloud DNS に関する問題が非常に多く出題されます。「Google Cloud のネットワーク設計の際に、適切なトポロジを選択できるか」「可用性とセキュリティを考慮した設計ができるか」「実運用時のトラブルに対処できるか」といった観点の出題が多いです。

出題範囲は、以下のような Google Cloud サービスです。

VPC
Cloud NGFW
Packet Mirroring
Cloud Router
Cloud NAT
Cloud Load Balancing
VPC Service Controls
Dedicated / Partner Interconnect
Cloud VPN
Cloud DNS
Cloud Armor
Network Connectivity Center
Network Intelligence Center
Google Kubernetes Engine（GKE）

本記事ではこれ以降、試験合格のために「具体的に何を知っているべきか」について細かく記述します。試験の利用規約の関係上、具体的な出題内容はご紹介できませんが、当記事が試験合格のための参考になれば幸いです。

ルーティング

仕様に関する参考記事

Google Cloud のルーティングの仕様に関する参考記事として、以下を参照してください。

medium.com

blog.g-gen.co.jp

カスタムルート広報とピアリング

VPC Peering や Cloud VPN を駆使した複雑なネットワーク構成について問われる問題が多く出題されます。

なかでも Hub-and-Spoke 型 (スター型とも呼ばれる) のネットワークトポロジに関する問題が頻出です。以下に例を挙げます。

このネットワークは VPC (A) をハブとして、オンプレミスサイト、 VPC (B) 、 VPC (C) と接続されています。VPC (A) とオンプレミスは Cloud VPN (IPSec VPN) で接続されており、 VPC 間は VPC Peering で接続されています。

このとき、Cloud Router や VPC Peering がデフォルトの設定のままだと、「オンプレミスから VPC (B) へ」といったハブ VPC を経由した通信はできず、直接接続されているネットワーク間のみでしか通信できません。

しかし、適切に設定しさえすれば、図右下の表のように相互にネットワーク間通信が実現できます。設定内容は、以下のとおりです。

Cloud Router にてオンプレミスの対向ルーターに広報するルートを明示的に設定する
- デフォルトだと Cloud Router が紐づいている VPC (A) のサブネットの CIDR しか広報されない
- Peering で繋がっている VPC (B) と (C) のルートも追加で広報するよう、明示的に設定
VPC (A) 側の 2 つある Peering 設定にてカスタムルートをエクスポートするよう設定する
- これにより対向である VPC (B) および (C) にカスタムルート (オンプレから受け取った 10.0.0.0/8 のルート) を渡せる
VPC (B) および (C) の Peering 設定にて対向である VPC (A) からカスタムルートをインポートするよう設定する
- これにより対向である VPC (A) からカスタムルート (オンプレから受け取った 10.0.0.0/8 のルート) を受け取れる

1 つ目の設定をしないと、オンプレミスルーターは VPC (B) と (C) への経路を知ることができません。Cloud Router はデフォルトだと、自分が紐付いている VPC のルートのみを、対向ルーターへ広報するからです。VPC (B) と (C) の経路を対向ルーターへ広報するよう、明示的に設定してあげる必要があります。これをカスタムルート広報といいます。

2 つ目と 3 つ目の設定をしないと、 VPC (B) と (C) はオンプレミスへの経路を知ることができません。カスタムルートのインポート・エクスポートの設定をしてあげることで、 VPC (A) がオンプレミスから受け取った 10.0.0.0/8 というルートを VPC (B) と (C) に教えてあげることができます。なおここでいうカスタムルートとは Google Cloud によって自動的に生成されるルート (デフォルトルートやサブネット間のルート) 以外の動的・静的なルートを指しています。この図でいえば、オンプレミスから BGP で受け取った 10.0.0.0/8 へのルートがカスタムルートになります。

複雑ですが、上記のような一通りの設定を行うと、 VPC (A) をハブとした相互通信が可能になるのです。

VPC 間の推移的ピアリング

VPC (B) と (C) 同士の通信ですが、これは VPC Peering で繋がった VPC を経由して通信をする推移的ピアリングと呼ばれる形になり、 VPC ではこの通信ができない仕様になっています。これは AWS の VPC Peering でも同様で、「2 ホップ制限」とも呼ばれています。

VPC Peering では直接繋がっている VPC 間でしか通信できないと覚えておきましょう。

VPC (B) と (C) を通信させたい場合は、これらを直接、VPC Peering で繋ぐ必要があります。つまり VPC Peering で複数の VPC 間通信を実現したい場合、接続はフルメッシュになります。フルメッシュ構成ではネットワークの数を n とすると n * (n-1) / 2 の数の Peering を作成することになります。

しかし、そのようなフルメッシュ構成は複雑性を高め、運用性を下げるため、これを避ける方法もあります。それは VPC 間を Peering ではなく、Cloud VPN で接続することです。

Cloud VPN で繋がっていれば、先程の図でオンプレミスと行ったのと同じように経路の交換ができますので、ハブ VPC を中心としたトポロジで VPC 間通信をさせることができます。

Cloud VPN には利用料金がかかってしまうため、実際の設計ではコストと運用性のトレードオフを検討することになります。

Cloud NAT

セキュリティ上、VM に外部 IP アドレスを持たせることはできれば避けたいものです。Cloud NAT を使えば、外部 IP アドレスを持たない VM もインターネットへ出ていくことができます。

Cloud NAT が VM のパケットを NAT するのはパケットが 0.0.0.0/0 → default internet gateway のルートを使うときだけであり、ネクストホップが default internet gateway 以外（Cloud VPN 等）であったり、0.0.0.0/0 より狭いターゲットが指定されている場合は、Cloud NAT は使われません。

参考 : Cloud NAT プロダクトの相互作用

限定公開の Google アクセスと Private Service Connect

限定公開の Google アクセスまたは Private Service Connect を構成して、プライベートネットワークから Google Cloud APIs にアクセスする方法を把握してください。DNS およびルーティングの設定手順をイメージできるようにしておいてください。

なお限定公開の Google アクセスの有効化は、サブネットのレベルで行う設定です。

ポリシーベースのルート

VPC ネットワークのルートテーブルには、ポリシーベースのルートを追加できます。ポリシーベースのルートとは、パケットの送信元 VM のネットワークタグなどに応じて、ネクストホップを内部パススルーロードバランサーに向けられるルートです。

パケットを仮想ネットワークアプライアンスに向けて、パケットの検査等をできるようにするユースケースで使用されます。ユースケースや設定方法を理解しておいてください。

参考 : ポリシーベースのルート

Network Connectivity Center

基本的な知識

Network Connectivity Center は、Google Cloud でハブアンドスポークのネットワーク構成を実現するためのフルマネージドサービスです。当試験では頻出ですので、基本的な知識を以下の記事で学んでください。

参考 : Network Connectivity Centerを徹底解説！ - G-gen Tech Blog

スタートポロジとメッシュトポロジ

メッシュトポロジとスタートポロジの構成を理解してください。センタースポークグループとエッジスポークグループのそれぞれにスポークを登録することになります。どちらにスポークを登録すると、どこに通信できるようになるのかを把握してください。

参考 : Network Connectivity Centerを徹底解説！ - G-gen Tech Blog - メッシュトポロジとスタートポロジ

経路交換の仕様

ハブにおける exclude-export-ranges フラグや、ハイブリッドスコープにおける include-import-ranges 設定など、Network Connectivity Center における経路交換をコントロールする設定について概要を把握してください。

Cloud NGFW

基本的な知識

Cloud NGFW や VPC ファイアウォールルールの仕組みを問う問題が出題されます。ステートフルインスペクションや Ingress、Egress、ターゲット、ネットワークタグ、サービスアカウントの概念を押さえておきます。

以下の記事を読み、VPC ファイアウォールルールとファイアウォールポリシーの違い、そしてそれぞれでどのような制御ができるかを理解してください。

参考 : Cloud Next Generation Firewall(Cloud NGFW)を徹底解説！ - G-gen Tech Blog

FQDN オブジェクト

ファイアウォールポリシー（階層型、グローバル、リージョン）では、FQDN オブジェクトや位置情報オブジェクトなどを使って、高度なパケットの制御ができます。これらのアクセス制御は VPC ファイアウォールルールでは使えないことに注意してください。

参考 : Cloud NGFW Standardの通信制御オブジェクトを解説！ - G-gen Tech Blog

評価順

デフォルトでは、ファイアウォールルールとファイアウォールポリシーの評価順は以下のようになっています。

しかし、VPC ネットワークの設定を BEFORE_CLASSIC_FIREWALL に変更することで、この評価順を変更できることに注意してください。

またルールのアクションに goto_next が指定されているとどのような挙動になるか、などについても確実に把握してください。

参考 : ファイアウォールポリシー - ネットワークファイアウォールポリシーの適用順序

ターゲット VM の指定

Google Cloud のベストプラクティスとして、 VPC ファイアウォールルールを適用する VM を指定する際は、ネットワークタグよりもサービスアカウントを利用することが推奨されています。このようなベストプラクティスも押さえておく必要があります。

参考 : VPC 設計のためのおすすめの方法とリファレンスアーキテクチャ - ターゲットフィルタリング

ネットワークタグは VM に対する管理権限 ( Compute Instance Admin ロール等 ) を持っていれば編集ができてしまうのに対し、サービスアカウントはサービスアカウントごと個別に IAM でアクセス制御ができるため、インスタンス管理者がネットワーク管理者の許可なく、禁止されている通信を可能にしてしまう、ということを抑止することができます。これがポイントとされる問題も出題されます。

共有 VPC

概念とユースケース

共有 VPC（Shared VPC）を使うユースケースが多く出題されます。ホストプロジェクトやサービスプロジェクトといった用語など、基本的な概念を理解してください。

共有 VPC を使うことで、中央のネットワーク管理者がネットワーク設定を集中管理し、開発者側はそのネットワークを利用するだけ、といった運用が可能になります。

参考 : 共有 VPC

IAM

共有 VPC に関連する IAM ロールについても把握してください。共有 VPC の管理者が、サブネットにおいて利用者に Compute ネットワークユーザー（roles/compute.networkUser）ロールを付与することで、利用者側は自分の VM 等を共有されたサブネットに配置することができるようになります。

参考 : 共有VPCの設定や利用に必要なIAM権限 - G-gen Tech Blog

Cloud Load Balancing

ロードバランサーの選択

各種用途のために、適切なロードバランサーを選択できるようにしておきましょう。

参考 : ロードバランサを選択する

ロードバランサーは種類が多く一見大変に思えますが、軸を覚えてしまえばそこまで大変ではありません。以下の軸の組み合わせで、10種類のロードバランサーが存在します。

軸	選択肢
トラフィックの種類	HTTP（S）か、TCP/UDP か
公開	外部か、内部か
スコープ	グローバルか、リージョンか、クロスリージョンか
パケット終端	プロキシ型か、パススルー型か

例えば「社内のみに公開するシステムで、パススルー型の（リクエストの接続元 IP アドレスを書き換えない）ロードバランサーが必要である」という状況であれば「リージョン内部パススルーネットワークロードバランサー」を選択することになります。「インターネット公開するシステム。ユーザーは世界中におり、プロトコルは HTTPS」であれば「グローバル外部アプリケーションロードバランサー」を選択します。

また、以下のようなアーキテクチャのシステムがあるとします。

[Web サーバー] -> [AP サーバー] -> [DB サーバー]

Web サーバーの負荷分散のためには、Web サーバーの手前に「グローバル外部アプリケーションロードバランサー」を配置して、Web サーバーから AP サーバーへのトラフィックの負荷分散のために「リージョン内部パススルーネットワークロードバランサー」を配置するというように、1つのシステムで複数のロードバランサーを使用する場合もありえます。

アプリケーションロードバランサー

最も一般的なユースケースで使われるのが、グローバル外部アプリケーションロードバランサーです。グローバル外部アプリケーションロードバランサーは、単一のエニーキャスト IP アドレスを使用して、世界中のユーザーからのリクエストを受け付け、リージョンのバックエンドにトラフィックをルーティングしてくれます。これにより、グローバルレベルの可用性が確保されます。

この際、グローバル外部アプリケーションロードバランサーは1つだけ構築し、それに紐づけるバックエンドサービス（グローバルリソース）も1つです。そのバックエンドサービスの背後に、リージョンごとのインスタンスグループを紐づけます。

Cloud Router

Cloud Router の基本

Cloud Router の以下のような仕様を知っておく必要があります。

Cloud Router は特定のリージョンに紐づくリージョンリソースである
Cloud Router は特定の VPC ネットワークに紐づく
Cloud Router は AS 番号（ASN）を持つ
Cloud Router はデフォルトでは、紐づく VPC ネットワークのすべてのサブネットへの経路を対向ルーターに広報する
Cloud Router が学習したルートがどのリージョンに広報されるかは「動的ルーティングモード」がリージョンかグローバルかによって挙動が異なる
- 動的ルーティングモードがリージョンの場合、Cloud Router と同じリージョンに動的ルートを作成する
- 動的ルーティングモードがグローバルの場合、すべてのリージョンに動的ルートを作成する

特に最後の動的ルーティングモードについては、設定をリージョンにするかグローバルにするかによって、Cloud Router のあるリージョン（VPN や Cloud Interconnect を接続したリージョン）とは違うリージョンのサブネットにある VM 等が、オンプレミスと通信できるかどうかが決まってきます。この仕様をある程度理解しておきましょう。

参考 : 学習したルート - 動的ルーティングモード

BGP セッション

Cloud VPN における BGP セッションの設定方法は、実際に一度検証してみることが望ましいです。Google Cloud では VPC ネットワーク間で VPN 接続を行うことが可能であるため、Google Cloud 検証環境があれば試してみることができます。

BGP IP アドレスは 169.254.x.x というリンクローカルアドレスであり、また ASN が Private ASN（64512-65535 または 4200000000 - 4294967294）である必要があります。

参考 : ピア VPN ゲートウェイに対する HA VPN ゲートウェイを作成する - BGP セッションを作成する

なお Cloud VPN の設定においては、「ローカル」という言葉は Google 側を指し、「ピア」という言葉は対向側を指していることに留意してください。

Cloud Interconnect

Dedicated Interconnect

Cloud Interconnect は専用線サービスであるため、検証するのが難しいサービスです。ドキュメントを中心に理解を深めましょう。

例えば Dedicated Interconnect の利用開始手順は以下のドキュメントに記載されているため、流れを把握しておきます。

参考 : Dedicated Interconnect のプロビジョニングの概要

Partner Interconnect

Partner Interconnect で Google が推奨するトポロジーはどのようなものか、についても把握しておきましょう。

参考 : Partner Interconnect の概要 - 99.99% の可用性のトポロジ

99.99% の可用性を確保するには上記のドキュメントのような構成にする必要があります。Cloud Router のルーティングモードを Global にすることで片方の回線がダウンしても冗長性が確保される、という点に注意してください。

別々の 2つのリージョンにそれぞれ Cloud Router を配置
各 Cloud Router からは違うゾーンに向けた2つずつの VLAN アタッチメントを作成する
Cloud Router の動的ルーティングモードを Global にする

また Partner Interconnect には Layer 2 と Layer 3 の2種類が存在している点にも留意してください。L2 だと自社ルーターと Cloud Router 間で BGP セッションの確立が必須です。L3 だと、Cloud Router とオンプレミスの間で BGP セッションを確立するのは、ネットワーク業者のルーターです。

参考 : Partner Interconnect の概要 - レイヤ 2 とレイヤ 3 の接続

Direct Peering / Carrier Peering

Direct Peering や Carrier Peering は、Google Workspace 等のパブリックな Google サービスと接続するためのサービスです。深く理解する必要はありませんが、その存在と概要は把握しておきましょう。

参考 : ダイレクトピアリングの概要
参考 : キャリアピアリングの概要

Cross-Cloud Interconnect

Cross-Cloud Interconnect は、Google Cloud と、Amazon Web Services（AWS）などの他クラウドを、広帯域、高信頼性の専用線で接続するサービスです。他クラウドと大規模なネットワークを接続する際には、この選択肢があることを理解してください。

参考 : Cross-Cloud Interconnectを徹底解説！

暗号化

レイヤ3での暗号化を確保するため、Cloud Interconnect の専用線上で HA VPN を確立することができます。専用線の中に暗号化トンネルを通すことで、より強固な盗聴防止となります。

参考 : Cloud Interconnect を介した HA VPN を構成する

なお、Cloud Interconnect では MACsec を構成できます。MACsec はレイヤ2の暗号化方式です。どの手法がどのレイヤで暗号化をするものなのか、把握してください。

参考 : Cloud Interconnect の MACsec の概要

Cloud DNS

転送ゾーン

Cloud DNS で転送ゾーンを作成することで、クラウド上の VM 等から、一部のドメイン名をオンプレミスの DNS サーバーにフォワードすることができます。フォワードするクエリは、Cloud Interconnect や Cloud VPN を通してオンプレミスに到達できます。

参考 : DNS ゾーンの概要 - 転送ゾーン

注意点として、転送を受ける方の DNS サーバから見たクエリの接続元 IP アドレスは 35.199.192.0/19 となります。プライベートネットワーク経由でクエリが転送されていても、接続元 IP アドレスが RFC 1918 のプライベートアドレスではないため不自然に見えますが、そのような仕様です。

これは、Cloud DNS からオンプレミス DNS へのフォワーディングを実現するためには、以下のような追加の設定が必要であることを意味します。

オンプレミス側ファイアウォール設定で 35.199.192.0/19 からの TCP/UDP 53 番ポートを許可する
オンプレミス側 DNS の設定でこの IP アドレス帯からの DNS クエリを許可する
オンプレミスから Google Cloud 側にパケットを返せるように経路を設定する（BGP で Cloud Router から広報する等）

受信サーバーポリシー

受信サーバーポリシーを定義することで、オンプレミスのクライアントから Cloud DNS へと名前解決クエリを投入うしたり、オンプレミスの DNS サーバから一部のリクエストを Cloud DNS へフォワーディングすることができます。

受信サーバーポリシーを作成して VPC に適用すると、オンプレミスのクライアントや DNS サーバから Cloud DNS にリーチするためのプライベート IP アドレスを持ったエンドポイントが生成されます。

参考 : DNS サーバーのポリシー

スプリットホライズン

例えば example.com というパブリックゾーンと、同名の example.com というプライベートゾーンを両方作成すると、インターネットからの名前解決はパブリックゾーンが返し、VPC 内からの名前解決はプライベートゾーンが返すようになります。こういった設定を、スプリットホライズンと呼びます。

参考 : DNS ゾーンの概要 - スプリットホライズン DNS の例

DNS ピアリング

DNS ピアリングは、特定ドメインの名前解決を異なるプロジェクト、または異なる VPC ネットワークの Cloud DNS にフォワードするための設定です。

参考 : DNS ゾーンの概要 - ピアリングゾーン

例えば以下のようなケースで使うことができます。

VPC (A) はオンプレミスサイトと Cloud Interconnect で接続されている
VPC (A) の Cloud DNS では onpremiss.local のドメイン名をオンプレミスの DNS サーバーにフォワードするよう設定されている
VPC (B) は VPC (A) と VPC Peering で接続されている
VPC (B) で onpremiss.local を名前解決したい

このようなときに VPC (B) から VPC (A) への DNS ピアリングを設定することで要件を満たせます。VPC (B) の中にいる VM は Cloud DNS に対して onpremiss.local の名前解決クエリを投げると、 DNS Peering に従い VPC (A) に名前解決をフォワードします。VPC (A) は forwarding zone に従いオンプレミス DNS に名前解決をフォワードします。クエリへの返答は、VPC (B) に返ります。

DNSSEC

DNSSEC（DNS Security Extensions）は、DNS キャッシュポイズニングや DNS スプーフィングといった脅威に対抗するための、DNS のセキュリティ機能です。IETF で定義されています。

Cloud DNS では DNSSEC を構成できます。DNSSEC の基本的な仕組みの概要や、設定手順は簡単に押さえておいてください。

参考 : DNS Security Extensions（DNSSEC）の概要

ネットワークセキュリティ

Secure Web Proxy

Secure Web Proxy は、VM からインターネットへ HTTP（S）アクセスする際のアクセス制御（出口管理）ができるフルマネージドサービスです。

Secure Web Proxy には「プロキシモード」「ネクストホップモード」「Private Service Connect モード」の3種類のデプロイ方法があることに留意してください。

参考 : Secure Web Proxy の概要

前述のファイアウォールポリシーの FQDN オブジェクトでも、宛先ドメインに応じたアクセス制御（許可したドメイン一覧にのみアクセスさせる等）はできますが、FQDN オブジェクトの場合はその名の通り、ドメイン名までしか検査されません。Secure Web Proxy では、ドメイン名部分だけではなく、パスの部分まで検査できます。

参考 : UrlList の構文リファレンス

VPC Service Controls

VPC Service Controls と限定公開の Google アクセス（Private Google Access）を組み合わせる方法についても理解してください。

オンプレミスと VPC が Cloud Interconnect や VPN で接続されており、オンプレミスのクライアントから Google API を「限定公開の Google アクセス」経由でアクセスするよう構成されているネットワークにおいて、VPC Service Controls を使った API を保護実現したいケースが出題されます。

このようなケースで、限定公開の Google アクセスのためのドメイン名として restricted.googleapis.com を使うのか private.googleapis.com を使うのか、答えられるようにしておきましょう。

また VPC Service Controls に対して直ちに設定を変更すると本番環境への予期せぬ影響が懸念されるため、事前の検証を行うためのドライラン構成も可能です。

VPC Service Controls や限定公開の Google アクセスについては、以下の記事を参照してください。「限定公開の Google アクセス」は難解なので、実際に検証環境で構築してみると理解が深まります。

Cloud Armor

WAF サービスである Cloud Armor も出題範囲です。

概要を理解することに加え、細かいところでは、 Cloud WAF で偽陽性などが発生した際に、どのログを見て調査すれば良いか、などは把握しておきましょう。Cloud Armor の検知に関するログは Cloud Armor の Cloud Audit Log ではなく、Cloud Load Balancing のアクセスログに出力されます。

以下の記事を参照してください。

参考 : Cloud Armorを徹底解説。GoogleのフルマネージドWAF - G-gen Tech Blog

Cloud CDN

基本的な知識

Cloud CDN は、Google Cloud ネイティブなコンテンツデリバリーネットワークサービスです。最大の注意点は、Cloud CDN は外部アプリケーションロードバランサーのバックエンドサービスまたはバックエンドバケットでのみ、有効化できるという点です。

参考 : Cloud CDN の概要

キャッシュ無効化

Cloud CDN では、明示的なキャッシュの無効化（invalidation）が可能です。以下のようなコマンドを実行して、パスを明示したキャッシュの無効化ができます。これにより、古いコンテンツが配信されてしまうことを防げます。

gcloud compute url-maps invalidate-cdn-cache ${URL_MAP_NAME} \
    --path "/images/file.jpg"

参考 : キャッシュ無効化の概要

Google Kubernetes Engine（GKE）

GKE に関する出題

Google Kubernetes Engine（GKE）に関する出題もされます。GKE クラスタを VPC ネイティブクラスタとして起動して、エイリアス IP アドレス範囲を使用することで IP アドレスリソースを効率的に使用できます。

またクラスタやノードプールの仕組みなど、GKE の基本は押さえておいてください。

参考 : Google Kubernetes Engine（GKE）を徹底解説 - G-gen Tech Blog

IP マスカレードエージェント

IP マスカレードエージェントによって Pod からのトラフィックの送信元 IP アドレスを SNAT する、といった概念について理解しておいてください。

参考 : IP マスカレードエージェント

モニタリング

Packet Mirroring と VPC フローログ

例えば「VM から Egress する全てのトラフィックを検査しなければならない」といったセキュリティ要件がある際に活躍するのが Packet Mirroring です。

参考 : Packet Mirroring

Packet Mirroring は、VM のネットワークインターフェイスからパケットをミラーして、内部ロードバランサの背後にあるモニタリング用の VM へ渡す機能です。これによりモニタリング用の VM 上でパケットの解析を行うことができます。VPC を流れる全てのパケットをミラーできる訳ではなく、VM のネットワークインターフェースを出入りするパケットのみが対象です。

似たような場合で、パケットのメタデータのみ（接続元/先 IP アドレス、接続元/先ポート番号、プロトコル、パケットのサイズなど）を解析したいケースがあります。この場合は、パケットの中身まで見る必要はないので、VPC フローログを有効化することを検討します。

参考 : VPC フローログ

パケットの中身を解析したいのか、パケットのメタデータを解析したいのか、問題文をよく確認します。

ファイアウォールのログ

ファイアウォールのログの基本も押さえておきましょう。ファイアウォールのログは、ルールごとに有効化する必要があります。もちろん、取得できるのはそのルールに評価されたパケットだけです。問題文に書かれている要件に Firewall Logging が本当に合致しているかには注意して回答が必要です。

専用線や VPN のモニタリング

専用線や VPN をモニタリングするにあたり、Cloud Monitoring の指標（metrics）を監視することができます。

BGP ピアリングの死活状況や、光ファイバー回線の光信号の強さ（Tx パワーと Rx パワーの光レベル）を確認する指標が用意されています。

参考 : 接続をモニタリングする - Google Cloud コンソールで指標を確認する
参考 : ログと指標の表示

Network Intelligent Center

Google Cloud のネットワーク管理補助ツールである Network Intelligent Center には、パケットの到達性をチェックする接続テスト（Connectivity Test）機能が用意されています。接続テストは、Network Connectivity Center の経路の確認にも対応しています。

ただし注意しなくてはいけないのは、接続テスト機能はあくまで、ネットワーク設定が正しいかを確認するための機能であり、ネットワークのモニタリングを想定したものではない点です。定常的なモニタリングには、前述の Cloud Monitoring 指標を使います。