インフラエンジニアの羅針盤

インフラエンジニア1〜3年目のための技術ガイド

Google Cloud Assosiate Cloud Engineer 第5章　ネットワーク設計の基礎と実践

公開更新

Google Cloud Assosiate Cloud Engineer
第5章　ネットワーク設計の基礎と実践

目次
  1. 5.1 VPC の本質
    1. 5.1.1 なぜ VPC が「土台」なのか
    2. 5.1.2 グローバル VPC という発想
    3. 5.1.3 VPC ネットワークとサブネットの関係
    4. 5.1.4 ルート・ファイアウォールと VPC 内通信のイメージ
    5. 5.1.5 プロジェクトと VPC、Shared VPC の位置づけ
    6. 5.1.6 ACE 試験での「VPC の本質」チェックポイント
  2. 5.2 ルートとファイアウォール
    1. 5.2.1 ルートの本質：パケットの「行き先表」
    2. 5.2.2 ルートの種類と典型パターン
    3. 5.2.3 VPC ファイアウォールの本質：ステートフルな「入口チェック」
    4. 5.2.4 ファイアウォールルールの構成要素
    5. 5.2.5 暗黙ルール（implied rules）とデフォルト挙動
    6. 5.2.6 ルートとファイアウォールの「役割分担」
    7. 5.2.7 ACE 試験で頻出のミスと対策
    8. 5.2.8 まとめ：ルートとファイアウォールの「筋肉と神経」
  3. 5.3 NAT / Private Google Access
    1. 5.3.1 NAT の基本と Cloud NAT の役割
    2. 5.3.2 ACE 試験向け Cloud NAT の典型パターン
    3. 5.3.3 Private Google Access（限定公開の Google アクセス）の本質
    4. 5.3.4 Cloud NAT と Private Google Access の組み合わせ
    5. 5.3.5 ACE 試験での典型シナリオ整理
    6. 5.3.6 試験で頻出のミスとその対策
    7. 5.3.7 まとめ：NAT / Private Google Access の押さえどころ
  4. 5.4 Peering / Shared VPC
    1. 5.4.1 VPC Network Peering と Shared VPC のざっくり比較
    2. 5.4.2 VPC Network Peering の基本と権限制御
    3. 5.4.3 Shared VPC の基本と権限制御
    4. 5.4.4 ACE 試験向け：Peering / Shared VPC の使い分けシナリオ
    5. 5.4.5 Peering / Shared VPC まわりでの典型的な誤解
    6. 5.4.6 まとめ：ACE レベルで押さえておくべきポイント
  5. 5.5 負荷分散（L4 / L7）
    1. 5.5.1 Cloud Load Balancing 全体像
    2. 5.5.2 L7: Application Load Balancer（HTTP(S)）
    3. 5.5.3 L4: Network Load Balancer（TCP / UDP）
    4. 5.5.4 L4 / L7 負荷分散の構成判断軸
    5. 5.5.5 ACE 試験でよく出るパターン
    6. 5.5.6 試験で狙われやすいミスと対策

5.1 VPC の本質

この節では、Google Cloud のネットワークの土台である VPC（Virtual Private Cloud） を、「グローバル VPC」という特徴に焦点を当てて整理します。
ACE レベルでは、細かいコマンドよりも

  • VPC が何をしているのか
  • どこまでがグローバルで、どこからがリージョン／ゾーンなのか
  • プロジェクトやサブネットとの関係

を正しくイメージできることが重要です。

5.1.1 なぜ VPC が「土台」なのか

公式ドキュメントでは、VPC は Compute Engine、GKE、サーバーレス（Cloud Run など）に対してネットワーキング機能を提供する基盤と説明されています。

ポイントを整理すると:

  • Google Cloud 上で動く VM、コンテナ、サーバーレスは 必ず VPC ネットワークの上で通信する
  • VPC は、クラウドリソース同士をつなぐ「仮想スイッチ／ルータ」と「IP アドレス空間」を提供する
  • オンプレミスとの VPN / Cloud Interconnect 接続の終着点にもなる

つまり、「どの VPC に属しているか」＝「どのネットワーク空間で通信できるか」 を決めるものです。

5.1.2 グローバル VPC という発想

Google Cloud の VPC の最大の特徴が、「VPC ネットワークはグローバルリソース」という点です。

公式ドキュメントでは次のように説明されています。

  • VPC ネットワーク（およびそれに紐づくルート・ファイアウォールルール）は グローバルリソース であり、特定のリージョンやゾーンに属さない
  • 1 つの VPC ネットワークの中に、複数リージョンにまたがるサブネットを持てる
  • これらのサブネットは Google のグローバル WAN によって接続される

図式化すると、次のようなイメージです。

[ 単一の VPC ネットワーク（global） ]
    ├─ subnet-a（asia-northeast1）
    ├─ subnet-b（us-central1）
    └─ subnet-c（europe-west1）

この 1 つの VPC 内で、リージョンをまたいだ内部通信（内部 IP 同士の通信）が、特別な「VPC ピアリング設定なし」に行えるのが Google Cloud の特徴です。

ACE の観点では、

  • 「VPC = グローバル」「サブネット = リージョン」
  • 「VPC 内リージョン間は、自動でルーティングされる」

という 2 点を素早く思い出せるかどうかが重要です。

5.1.3 VPC ネットワークとサブネットの関係

VPC とサブネットの関係は、公式ドキュメントで明確に定義されています。

  • VPC ネットワーク
    • グローバルリソース
    • 「サブネットのリスト」と「共通ルール（ルート・ファイアウォール）」をまとめた入れ物
  • サブネット（subnet / subnetwork）
    • リージョンリソース
    • 各サブネットに CIDR ブロック（IP 範囲） が割り当てられる
    • そのサブネットに属する VM / コンテナの内部 IP アドレス空間を定義する

特徴的なのは次の点です。

  • Google Cloud では、「VPC 自体には CIDR を持たない」
  • IP 範囲は すべてサブネット側にのみ定義 される
  • 1 つの VPC に複数サブネットを定義し、それらをリージョンごとに配置する

ACE 試験では、

  • 「VPC ネットワークはグローバル、サブネットはリージョン」
  • 「IP 範囲はサブネットで定義する」

という構造が分かっていないと、サブネット設計や通信経路の問題で混乱しやすくなります。

5.1.4 ルート・ファイアウォールと VPC 内通信のイメージ

VPC の本質は「IP 空間」だけでなく、どこへどうルーティングし、何を許可 / 拒否するか の制御にあります。

公式ドキュメントでは、次のように整理されています。

  • VPC ネットワークには、ルート と ファイアウォールルール が紐づく
  • ルート・ファイアウォールルールともに VPC ネットワーク単位のグローバルリソース
  • ファイアウォールルールは VM の NIC に適用され、入出力トラフィックを制御する

イメージとしては:

[ VPC ネットワーク（global） ]
   ├─ 共通ルート（default ルート, サブネット向けルート など）
   ├─ 共通ファイアウォールルール（allow-ssh, allow-internal など）
   └─ サブネット（各リージョン）
          └─ VM / Pod の NIC にルールが適用される

ここでのポイントは、

  • ルート / ファイアウォールは VPC 単位でグローバルに効く
  • ただし適用対象は「特定サブネットの VM」「特定タグを持つ VM」などに絞れる

という構造です。

ACE のシナリオでは、例えば:

  • 「複数リージョンにまたがる VM 間で、内部通信を許可したい」
    → VPC レベルのファイアウォールルールで 10.x.x.x/xx を許可
  • 「一部のサブネットだけに SSH を許可したい」
    → ターゲットタグやサービスタグを使ってファイアウォールを適用

といった考え方ができていれば十分です。

5.1.5 プロジェクトと VPC、Shared VPC の位置づけ

ここで一度、「プロジェクトと VPC の関係」も整理しておきます。

  • 基本形: 1 プロジェクト内に 1 つ以上の VPC ネットワークを持つ
  • 各 VPC は、そのプロジェクトのリソース（VM / GKE など）にネットワークを提供

公式ドキュメントでは、これに加えて Shared VPC という仕組みが紹介されています。

Shared VPC の概要:

  • ホストプロジェクト に VPC ネットワークを作成
  • サービスプロジェクト から、そのホストプロジェクトの VPC / サブネットを利用できる
  • 組織として、ネットワーク（アドレス設計・ルート・ファイアウォールなど）を集中管理しつつ、
    各プロジェクトは自分のリソースと請求を持つ構造にできる

ACE 出題の観点では、

  • 「VPC ネットワークを複数プロジェクトで共有したい」 → Shared VPC
  • 「ネットワーク管理を中央チームに集約し、開発チームごとにプロジェクトを分離したい」 → Shared VPC

という対応を理解しておけば十分です。

5.1.6 ACE 試験での「VPC の本質」チェックポイント

最後に、この節で扱った内容を ACE 試験視点で要約します。

  1. VPC の役割
    • Compute Engine、GKE、サーバーレスにネットワーキングを提供するクラウドネットワークの土台
  2. グローバル VPC の概念
    • VPC ネットワークはグローバルリソースで、特定リージョンに属さない
    • 一つの VPC に複数リージョンのサブネットを持てる
  3. サブネットとの関係
    • サブネットはリージョンリソースで、IP 範囲はサブネットごとに定義
    • 「VPC に CIDR がある」のではなく、「サブネットに CIDR がある」
  4. ルート・ファイアウォールの位置づけ
    • ルート / ファイアウォールルールは VPC 単位のグローバルリソース
    • 適用対象をタグやサブネットで絞りながら、VPC 全体の通信方針を決める
  5. プロジェクトと Shared VPC
    • 基本は「プロジェクト内の VPC」を使う
    • 複数プロジェクトで共通ネットワークを使いたいときは Shared VPC（ホストプロジェクト / サービスプロジェクト）

この章のゴールは、「VPC = グローバルな論理ネットワーク」「サブネット = リージョンごとの IP 空間」「ルート / ファイアウォール = VPC 全体に効く通信ルール」という三層構造を頭に描けるようにすることです。
これができていれば、以降の VPC ピアリング、ハイブリッド接続、セキュリティ設計の理解が格段に楽になります。

5.2 ルートとファイアウォール

この節では、VPC ネットワークの「血管」にあたる ルート（routes） と、「免疫システム」にあたる VPC ファイアウォールルール を扱います。
ここを勘違いすると、「通信できない」「なぜかインターネットに出られない」「SSH が通らない」系の問題を延々とデバッグすることになります。

5.2.1 ルートの本質：パケットの「行き先表」

公式ドキュメントでは、ルートは次のように定義されています。

ルートは、VM インスタンスから他の宛先（VPC 内の別 VM や、Google Cloud 外部の宛先）へのトラフィックの経路を定義する。

もう少し平易に言うと、「この IP 宛のパケットは、どこに渡すか」 を決める表がルーティングテーブルで、その 1 行 1 行がルートです。

1 つのルートは、必ず次の 2 要素だけで構成されます。

  • 宛先（Destination）
    • CIDR 形式の IP プレフィックス（例: 10.10.0.0/24, 0.0.0.0/0）
  • 次ホップ（Next hop）
    • その宛先に送りたいときに、どこへパケットを渡すか
    • 例: インターネットゲートウェイ、特定インスタンス、Cloud VPN トンネル、Cloud Router 等

VM はパケットを送るたびに、VPC のルーティングテーブルを見て「一番マッチする」ルートを探します。

  • 宛先 IP が複数のルートにマッチする場合、最もプレフィックスが長い（最も具体的な CIDR） が選ばれる
  • 選ばれたルートの「次ホップ」にパケットが送られる

Google Cloud のルーティングは、物理ルータではなく分散仮想ルータとして実装されており、ネットワーク内でスケーラブルに処理されています。

5.2.2 ルートの種類と典型パターン

VPC では、ルートには大きく次の種類があります。

  1. システム生成ルート（system-generated routes）
  2. カスタム静的ルート（custom static routes）
  3. 動的ルート（dynamic routes：Cloud Router 経由）
  4. ピアリングルート（VPC Network Peering 経由）
(1) システム生成ルート

各 VPC ネットワークには、最初から次のようなルートが自動で作成されます。

  • 各サブネット用のルート
    • 例: 10.10.0.0/24 のサブネットがあれば、
      「宛先 10.10.0.0/24 → 次ホップ VPC 内」のようなルートが自動作成
    • これにより、同じ VPC 内のサブネット間通信が内部でルーティングされる
  • デフォルトルート（0.0.0.0/0 → default internet gateway）
    • 外部 IP を持つ VM からインターネットへ出るためのルート
    • NAT や VPN／Interconnect を使う構成では、このルートをカスタマイズすることもある

ACE 的には、「サブネットを作ると、そのプレフィックス向けのルートが勝手に生えてくる」という感覚があれば十分です。

(2) カスタム静的ルート

ユーザーが追加で作るルートです。

  • 例: オンプレミスの 192.168.0.0/16 に行くトラフィックを、Cloud VPN トンネルに送る
    • 宛先: 192.168.0.0/16
    • 次ホップ: Cloud VPN トンネル
  • 例: 特定の宛先を、仮想アプライアンス（FW 用 VM）経由でルーティングする
    • 宛先: 10.100.0.0/16
    • 次ホップ: 特定インスタンス

「特定の宛先に行くトラフィックだけ、デフォルトと違う経路にしたいときに使う」もの、と理解しておきましょう。

(3) 動的ルート（Cloud Router）

Cloud Router は、BGP を使ってオンプレミスや他ネットワークとルート情報を交換するマネージドサービスです。

  • Cloud VPN / Cloud Interconnect を使うときに併用
  • オンプレ側のネットワークプレフィックスを BGP で学習し、VPC 内のルーティングテーブルに動的ルートとして追加する
  • 逆方向に、VPC のサブネットプレフィックスやカスタムルートをオンプレに広告することも可能

Cloud Router の動的ルートが「どこまで広がるか」は、VPC の 動的ルーティングモード（regional / global） によって決まります。

  • regional: ルーターが存在するリージョン内にのみ適用
  • global: VPC 全体に広がる

ACE では、「オンプレとの経路交換は Cloud Router（BGP）」「Cloud Router のルートは dynamic routes」と整理できていれば十分です。

(4) ピアリングルート

VPC Network Peering を張ると、お互いのサブネットルートが「ピアリングルート」として自動共有されます。

  • VPC-A のサブネットプレフィックスが VPC-B のルーティングテーブルに反映され、逆も同じ
  • これにより、異なる VPC 間で内部 IP による通信が可能になる

ピアリングでは、基本的に「サブネットルートのみが自動交換される」点を覚えておくと、カスタムルートの扱いを間違えにくくなります。

5.2.3 VPC ファイアウォールの本質：ステートフルな「入口チェック」

ルートが「どこへ送るか」を決めるのに対し、VPC ファイアウォールルールは「そのパケットを通すかどうか」を決める仕組みです。

公式ドキュメントでは、VPC ファイアウォールルールについて次のように説明されています。

  • VPC ファイアウォールルールは、VPC 内の VM インターフェースに入出するトラフィックを制御する
  • ルールにより、送信元 / 送信先 / ポート / プロトコル / ターゲット（タグやサービスアカウント）に基づいて allow / deny を指定できる

さらに重要なのが、ステートフル（stateful） であるという点です。

  • ある方向の通信が許可されてコネクションが確立されると、戻りのトラフィックは自動で許可される
  • したがって、「アウトバウンドを許可しただけで戻りの応答も通る」

ACE のよくある誤解は「戻りトラフィック用に別途ルールが必要」と思い込むことなので、ここはきちんと上書きしておきましょう。

5.2.4 ファイアウォールルールの構成要素

VPC ファイアウォールルールは、次のような属性を持ちます。

  • 方向（Direction）
    • ingress（受信） / egress（送信）
  • アクション（Action）
    • allow / deny
  • 優先度（Priority）
    • 0〜65535 の整数。値が小さいほど優先度が高い
    • 最初にマッチしたルールで許可 / 拒否が決まる
  • 対象（Target）
    • このルールが適用される VM を絞り込む
    • ネットワークタグ / サービスアカウント / 全インスタンス など
  • 送信元 / 宛先（Source / Destination）
    • ソース IP レンジ（例: 0.0.0.0/0, 10.0.0.0/8）
    • 方向が egress の場合は destination の範囲も指定可能
  • プロトコル / ポート
    • TCP/UDP ポート番号、ICMP 等

この「誰からどこへ / どのプロトコルで / どの VM に対して」という 4 つを揃えて、最後に allow / deny を決めるイメージです。

5.2.5 暗黙ルール（implied rules）とデフォルト挙動

すべての VPC には、ユーザーが消せない「暗黙のファイアウォールルール」が設定されています。

  • 暗黙許可 egress ルール
    • 全インスタンスから、どの宛先への送信も許可（優先度は最も低い）
  • 暗黙拒否 ingress ルール
    • すべての受信トラフィックを拒否（これも最も低い優先度）

つまり、「何もルールを作らないと、VM から外向き通信はできるが、外からの新規接続はすべて拒否」という挙動になります。

ここから ACE でよく出るポイントが 2 つあります。

  1. SSH できないのはルートではなくファイアウォールのせい
    • 外部 IP が付いていてルートも正常でも、
      tcp:22 を許可する ingress ルールがなければ SSH は通らない
    • デフォルトの暗黙拒否 ingress ルールに落ちるため
  2. 戻りトラフィックには追加ルール不要
    • egress allow（または暗黙 allow）で外向き通信を許可していれば、
      そのコネクションに対する戻りのトラフィックは自動で通る

この 2 つを混同すると、永遠にルートをいじり続けることになります。

5.2.6 ルートとファイアウォールの「役割分担」

ルートとファイアウォールの違いは、ACE のシナリオ問題で非常に頻出です。次のように整理しておきましょう。

  • ルート（routes）
    • 「パケットをどこに送るか」を決める
    • 宛先プレフィックスと次ホップのマッピング
    • 例: 0.0.0.0/0 → インターネットゲートウェイ、192.168.0.0/16 → VPN
  • VPC ファイアウォールルール
    • 「そのパケットを通してよいか」を決める
    • 方向 / ソース / デスティネーション / プロトコル / ポート / ターゲット VM に基づいて allow / deny

したがって、通信トラブルの切り分けは次の順番になります。

  1. ルートがあるか
    • 宛先へのルートが存在するか
    • デフォルトルートを別経路に変えていないか
  2. ファイアウォールでブロックされていないか
    • 方向は正しいか（ingress/egress）
    • ソース / ターゲットタグ / サービスアカウントの指定は合っているか
    • 優先度の低い deny に先にマッチしていないか

ACE 試験では、「どちらを設定すべきか？」という選択問題がよく出ます。

  • 宛先ネットワークへの経路そのものがない → ルートを追加
  • 経路はあるがポートが閉じている → ファイアウォールルールを修正

この区別ができれば、かなりの問題で点が取れます。

5.2.7 ACE 試験で頻出のミスと対策

最後に、ACE でよく出る「やりがちなミス」と、その対策をまとめておきます。

ミス 1: 「SSH できない → ルートがない？」と思い込む

ありがちパターン

  • 外部 IP 付き VM に SSH 接続できない
  • ルーティングを疑うが、実は ingress tcp:22 を許可していないだけ

対策

  • 「到達不能」系の問題はまず ファイアウォールの ingress を確認する癖をつける
  • ルートはデフォルトでインターネットゲートウェイへの 0.0.0.0/0 があることを思い出す
ミス 2: 戻りトラフィック用のルールを勝手に追加

ありがちパターン

  • egress allow を作ったあと、「戻りも必要だ」と思い、
    ingress allow を広く開けてしまう

対策

  • VPC ファイアウォールはステートフルであることを明確に覚える
  • 「新規接続の方向にだけルールを書けばよい」と考える
ミス 3: タグ / サービスアカウントの指定ミス

ありがちパターン

  • ルール自体は正しいが、ターゲットタグが VM に付いていない
  • サービスアカウントを変えたのに、ファイアウォールの適用先を変えていない

対策

  • ルールの「適用先（target）」を毎回チェックする
  • 「タグ or サービスアカウント ベースで制御する」という発想を持つ
ミス 4: カスタムルートで「戻り経路」を忘れる

ありがちパターン

  • 特定の宛先へのルートだけ VPN に向けるが、逆方向のルートをオンプレ側に設定し忘れる
  • 結果として、一方向通信はできても戻りパケットが正しい経路で戻ってこない

対策

  • ルートは「行き」と「帰り」の両方が必要
  • Cloud Router（BGP）で動的に経路を交換する方がヒューマンエラーを減らせる場面が多い
ミス 5: 「VPC ファイアウォール = すべての入口」と思い込む

実際には、Google Cloud には 階層型ファイアウォールポリシー や ネットワークファイアウォールポリシー など、VPC ファイアウォール以外の層も存在します。

ACE レベルでそこまで深掘りはされませんが、問題文に「組織全体で共通のファイアウォールポリシーを適用したい」とあれば、
VPC だけではなく階層型ファイアウォールポリシーも候補になる、という感覚は持っておくと有利です。

5.2.8 まとめ：ルートとファイアウォールの「筋肉と神経」

この節の内容を一言でまとめると、

  • ルート
    • VPC の中で「パケットをどこへ運ぶか」を決める経路表
    • システム生成ルート / カスタム静的ルート / 動的ルート / ピアリングルートがある
  • VPC ファイアウォール
    • VM の NIC を通過するトラフィックを、条件に応じて allow / deny するステートフルな仕組み
    • 暗黙 allow egress / 暗黙 deny ingress がベース挙動
  • よくあるミス
    • SSH できないのをルートのせいにする
    • 戻りトラフィックにもルールが必要と思い込む
    • ターゲットタグ / SA の指定ミス
    • 片方向ルートだけ設定して戻り経路を忘れる

このあたりを整理しておけば、ACE 試験のネットワーク問題で「何を直すべきか」を冷静に判断できるようになります。

5.3 NAT / Private Google Access

この節では、VPC ネットワークにおける

  • Cloud NAT（NAT ゲートウェイ）
  • Private Google Access（限定公開の Google アクセス）

の役割と動作を整理します。
ACE 試験では、

  • 「外部 IP を持たない VM をどうインターネットや Google API に出すか」
  • 「NAT と Private Google Access の違いは何か」

がよく問われます。

5.3.1 NAT の基本と Cloud NAT の役割

NAT の基本イメージ

Network Address Translation（NAT）は、プライベート IP とパブリック IP を変換する仕組みです。
多くのクライアントが 1 つまたは少数のパブリック IP を共有しながら外部と通信するために使われます。

Google Cloud が提供する NAT が Cloud NAT です。公式ドキュメントでは次のように説明されています。

  • Cloud NAT は Google Cloud が管理する フルマネージド NAT サービス
  • 目的は「外部 IP を持たないリソースのアウトバウンド通信を可能にすること」
  • NAT は 送信元アドレス変換（SNAT） を行い、戻りトラフィックに対してのみ宛先アドレス変換（DNAT）を行う

Cloud NAT がアドレス変換を行う代表的リソースは次のとおりです。

  • Compute Engine VM インスタンス
  • GKE クラスタ（特に Private cluster）
  • Cloud Run / Cloud Functions / App Engine（Serverless VPC Access 経由）
Cloud NAT の動作の特徴

公式の Cloud NAT 概要から重要なポイントを整理します。

  • アウトバウンド専用
    • Cloud NAT は 確立済みの戻りトラフィックに対する DNAT のみ サポート
    • インターネットからの「新規の着信接続（un solicited inbound）」は許可されない
  • フルマネージド・分散型
    • プロキシ VM やアプライアンスではなく、VPC を支える Andromeda SDN によって実装
    • 単一障害点にならず、高いスケーラビリティと可用性を提供
  • リージョン・VPC 単位のゲートウェイ
    • Cloud NAT ゲートウェイは
      • 1 つの VPC ネットワーク
      • 1 つのリージョン
      • 1 つの Cloud Router
        に紐付く
    • 対象とするサブネット（主/副 IP 範囲）を指定すると、その範囲に属する VM / ノードに NAT が自動適用される
  • SNAT による IP 共有
    • NAT 用に割り当てた外部 IP プールを使って、複数 VM のアウトバウンドをまとめる
    • 送信元ポートを分割して多くの接続をさばく（ポート割当の仕様は別ページで説明）

重要:
外部 IP を持つ VM がある場合、その VM からのトラフィックは基本的に自分の外部 IP で一対一 NAT され、Cloud NAT は使われません。Cloud NAT は「外部 IP を持たないリソース」用と押さえておきます。

5.3.2 ACE 試験向け Cloud NAT の典型パターン

ACE で問われる Cloud NAT の利用パターンは、ほぼ次に集約できます。

パターン 1: 外部 IP を持たない VM からインターネットへ

要件:

  • 外部 IP を VM に付与したくない（セキュリティ / コスト / IP 枯渇対策）
  • ただし OS のアップデート、パッケージ取得、外部 API へのアクセスは必要

この場合の設計:

  • 対象サブネットを Cloud NAT ゲートウェイに紐付ける
  • VM には内部 IP のみを割り当てる
  • egress ファイアウォールルールで HTTP/HTTPS 等を許可する

公式ハンズオンでも「外部 IP のない VM に対して Private Google Access と Cloud NAT を構成し、Google API とインターネット両方へのアクセスを検証する」という内容が出てきます。

パターン 2: GKE / サーバーレスからのアウトバウンド

要件:

  • Private GKE クラスタや Serverless VPC Access 経由で外部サービスにアクセス
  • ノードやサーバーレス実行環境に外部 IP を持たせない

この場合も、プライベートサブネットに対して Cloud NAT を構成するのが標準パターンです。

5.3.3 Private Google Access（限定公開の Google アクセス）の本質

Private Google Access とは

公式ドキュメントでは、Private Google Access（PGA）は次のように説明されています。

  • 外部 IP を持たない VM（内部 IP のみ） が
  • Google APIs / services の外部 IP アドレス に到達できるようにする仕組み
  • 対象は Cloud Storage、BigQuery、Cloud Logging など、Google のプロダクション基盤上で動作するサービス（*.googleapis.com 等）

ポイントを整理すると:

  • 対象 VM
    • ネットワークインターフェースに 外部 IP がない ことが前提
  • 動作
    • サブネット単位で Private Google Access を有効化
    • そのサブネット上の VM が、Google API 用の外部 IP へ内部 IP からアクセスできるようになる
  • 影響範囲
    • 外部 IP を持つ VM には影響なし（もともとインターネット経由で Google API にアクセスできる）

公式仕様では、Private Google Access の有効化条件として次のように記載されています。

  • VM のネットワークインターフェースが
    • Private Google Access を有効化したサブネットに属している
    • 外部 IP アドレスを持たない
    • 送信元 IP が内部 IP（または alias IP / IPv6）である
  • VPC ネットワークが Google APIs / services へのネットワーク要件（ルートなど）を満たしている
何が「Private」なのか

Private Google Access は、

  • インターネット全体へのアクセスを開くのではなく
  • Google APIs / services への通信だけを、Google のバックボーン内で完結させる

ための機能です。

「インターネットには出したくないが、Cloud Storage や BigQuery にはアクセスしたい」という要件を満たすための機構と理解すると分かりやすくなります。

5.3.4 Cloud NAT と Private Google Access の組み合わせ

役割の違い

両者の役割を一言でまとめると次のとおりです。

  • Cloud NAT
    • 外部 IP を持たないリソースの
    • インターネット全般・外部サービスへのアウトバウンド通信 を可能にする
  • Private Google Access
    • 外部 IP を持たないリソースの
    • Google APIs / services へのみのプライベートなアクセス を可能にする

つまり、

  • 「Google API 以外にも GitHub や外部 SaaS に出たい」 → Cloud NAT
  • 「インターネットには出したくないが Google API だけ使いたい」 → Private Google Access

という棲み分けになります。

典型構成 1: 両方有効（Google API + インターネット）

Cloud Skills Boost のラボなどで紹介されるパターンです。

  • サブネットで Private Google Access を有効化
  • 同じサブネットを対象に Cloud NAT ゲートウェイを構成
  • 外部 IP のない VM から
    • Google APIs / services へは Google のバックボーン経由でアクセス
    • その他インターネット宛は Cloud NAT 経由でアクセス

この構成をイメージしておくと、試験問題のシナリオを読みやすくなります。

典型構成 2: Private Google Access のみ（インターネット遮断）

要件:

  • セキュリティポリシーにより、インターネットへの直接アクセスは禁止
  • ただし Cloud Storage や BigQuery など Google Cloud API にはアクセスしたい

設計:

  • 対象サブネットで Private Google Access を有効化
  • インターネットへのデフォルトルートを張らない、あるいはファイアウォールで外向き宛先を厳しく絞る
  • 必要なら Private Service Connect 等と組み合わせて、より厳密な制御も可能
典型構成 3: オンプレミスからの Private Google Access

オンプレミス環境から Google APIs / services へ、インターネットを経由せずに到達させるための機能が
Private Google Access for on-premises hosts です。

概要は次のとおりです。

  • オンプレミスと VPC を Cloud VPN / Cloud Interconnect で接続
  • オンプレ側のトラフィックを private.googleapis.com または restricted.googleapis.com の VIP に向ける
  • VPC 側の Cloud Router / ルート / ファイアウォールを適切に構成
  • 結果として、オンプレミスから Google APIs にプライベート経路でアクセス可能

ACE レベルでは、「こういう機能があり、ハイブリッド構成で Google API にプライベート接続できる」という認識があれば十分です。

5.3.5 ACE 試験での典型シナリオ整理

ACE の問題文にそのまま出そうなシナリオを、観点別に整理します。

シナリオ A: 外部 IP なし VM からインターネットへ

要件:

  • セキュリティ上、VM に外部 IP は付けたくない
  • OS アップデートや外部 API へのアクセスは必要

正解パターン

  • 対象サブネットに対して Cloud NAT を構成
  • VM には内部 IP のみ
  • egress ファイアウォールを適切に許可

※ Private Google Access は「Google API 専用」のため、インターネット全般へのアクセスには Cloud NAT が必要です。

シナリオ B: 外部 IP なし VM から Cloud Storage / BigQuery のみアクセス

要件:

  • インターネットへは出したくない
  • Cloud Storage や BigQuery 等の Google API だけ利用したい

正解パターン

  • 対象サブネットで Private Google Access を有効化
  • VM には内部 IP のみ
  • 必要に応じて、ファイアウォールで宛先を Google API 用の VIP に制限

Cloud NAT は必須ではありません。Google API へのアクセスは Private Google Access によって実現されます。

シナリオ C: オンプレミスから Google APIs にプライベート接続

要件:

  • オンプレミスからインターネットに出ずに Google APIs を利用したい

正解パターン

  • オンプレミスと VPC を Cloud VPN / Interconnect で接続
  • Private Google Access for on-premises hosts を構成
  • オンプレ側の DNS / ルートを private.googleapis.com 等の VIP 向きにする
シナリオ D: Private Google Access と Private Service Connect の違い

ACE では Private Service Connect の詳細までは深掘りされにくいですが、ざっくり次の違いを押さえておくと選択肢を絞りやすくなります。

  • Private Google Access
    • Google が用意した共有の VIP／アドレスレンジを使う
    • サブネットに対して有効化するだけで比較的簡単
    • Google APIs / services 向け
  • Private Service Connect
    • 自分の VPC 内に「専用の Private エンドポイント」を作る
    • 内部 IP で Google API を公開でき、ルーティング制御が柔軟
    • 設定はやや複雑

5.3.6 試験で頻出のミスとその対策

最後に、NAT / Private Google Access まわりでよくある誤解を整理します。

ミス 1: 「Cloud NAT を設定したら外部からアクセスできる」

誤り

  • Cloud NAT があれば、外部から VM に接続できると考えてしまう

正しくは

  • Cloud NAT は アウトバウンド専用
  • 「確立済みの戻りトラフィックに対する DNAT のみ」をサポートし、
    インターネットからの新規着信は一切受け付けない
  • 内部専用 VM に接続したい場合は、IAP / Bastion / VPN など別の仕組みが必要
ミス 2: 「Private Google Access を有効にすればインターネットに出られる」

誤り

  • PGA = インターネットに出られる設定、と誤解する

正しくは

  • Private Google Access は Google APIs / services 専用
  • インターネット全般に出るための仕組みではない
  • インターネット宛通信が必要なら、別途 Cloud NAT などが必要
ミス 3: Private Google Access を「VM 単位の設定」と思い込む

正しくは

  • Private Google Access は サブネット単位の設定
  • そのサブネット上の「外部 IP なし VM」が対象になる

よって、問題文に「特定サブネットの VM だけ Google API にアクセスさせたい」と書かれていたら、
「サブネットで Private Google Access を有効化する」という回答を選ぶのが自然です。

ミス 4: Cloud NAT のスコープを誤解する

誤り

  • Cloud NAT を「特定 VM に張り付けるもの」とイメージする

正しくは

  • Cloud NAT ゲートウェイは
    • 1 VPC ネットワーク
    • 1 リージョン
    • 1 Cloud Router
      に紐付き、
  • 対象として指定したサブネット（IP 範囲）に属するリソースに自動適用される

5.3.7 まとめ：NAT / Private Google Access の押さえどころ

ACE レベルで押さえておきたいポイントを最後に一覧で整理します。

  • Cloud NAT
    • 外部 IP を持たない VM / GKE / サーバーレスのアウトバウンド用
    • アウトバウンド専用（戻りトラフィックのみ DNAT、着信は不可）
    • リージョン・VPC 単位のゲートウェイとして Cloud Router に紐付く
  • Private Google Access
    • 外部 IP を持たない VM が Google APIs / services にアクセスするための仕組み
    • サブネット単位で有効化
    • インターネット全般ではなく、Google APIs / services 向け
  • 構成パターン
    • Google API + インターネット → Cloud NAT + Private Google Access（両方）
    • Google API のみ → Private Google Access のみ
    • オンプレ → Private Google Access for on-premises + VPN / Interconnect

このあたりまで整理できていれば、「外部 IP を付けないでどう外に出すか」「Google API にだけプライベートに接続したい」といった ACE の典型問題には十分対応できるはずです。

5.4 Peering / Shared VPC

この節では、VPC 間接続で頻出の

  • VPC Network Peering
  • Shared VPC

を、「誰がどこまで触れるのか」という 権限制御 の観点で整理します。
ACE レベルでは、細かいフラグや CLI オプションよりも、

  • どんなユースケースでどちらを使うか
  • どのロールにどの権限を与えるべきか
  • どこまでネットワーク権限を委譲してよいか

が問われやすいので、そのレベルにフォーカスします。

5.4.1 VPC Network Peering と Shared VPC のざっくり比較

まず大枠を整理します。

  • VPC Network Peering
    • 2 つの VPC ネットワークをプライベートに接続し、内部 IP で相互に通信できるようにする機能
    • VPC は同一プロジェクト / 同一組織 / 異なる組織のいずれの組み合わせでもよい
    • それぞれの VPC は 管理上は完全に別。ルートのみを交換し、IAM やファイアウォールルールは共有しない
  • Shared VPC
    • 1 つの VPC ネットワークを「ホストプロジェクト」に持たせ、それを複数の「サービスプロジェクト」と共有する仕組み
    • 組織のネットワークチームが、サブネット / ルート / ファイアウォールをホスト側で一括管理しつつ、サービスプロジェクト側の開発チームに VM や GKE などの作成権限だけを渡すモデル

イメージとしては：

  • 「別々の VPC 同士を横に繋ぐ」のが VPC Peering
  • 「1 つの VPC を複数プロジェクトで使い回す」のが Shared VPC

です。

5.4.2 VPC Network Peering の基本と権限制御

VPC Network Peering の基本仕様

公式ドキュメントの要点を整理します。

  • 2 つの VPC ネットワークを Peering で接続し、内部 IPv4 / IPv6 による通信を可能にする
  • Peered VPC は
    • 同一プロジェクトでもよいし
    • 異なるプロジェクト、さらには異なる組織でもよい
  • Peering トラフィックのレイテンシ / スループット / 可用性は、「同じ VPC 内のトラフィック」と同等
  • トランジティブルーティングは提供されない
    • net-a ↔ net-b、net-a ↔ net-c が Peering していても、net-b ↔ net-c は自動ではつながらない
  • Peering する VPC 同士のサブネット IP 範囲は重複不可
    • どのサブネットも、Peering 相手のサブネットと「完全一致・包含・被包含」してはならない
    • Peering 作成時や新しいサブネット作成時に重複チェックが実行される

ACE 試験では、
「トランジティブルーティングができない」「IP 範囲が重なると Peering できない」あたりがよく選択肢に紛れます。

VPC Network Peering における権限制御

Peering は「ルートだけ共有するが、管理は完全に別」という思想で設計されています。

管理境界
  • Peering された 2 つの VPC は、管理上は別々
    • それぞれの VPC のルートテーブルが、「どのルートを相手にエクスポート / インポートするか」を設定する
    • 交換されるのはルートだけで、IAM やファイアウォールポリシーは交換されない
  • ファイアウォールについて
    • VPC Peering は ファイアウォールルールや firewall policy を共有しない
    • それぞれの VPC のセキュリティ管理者が、自分の VPC に対して独立してルールを定義する
    • sourceRanges に Peering 相手の CIDR を指定するなどして制御する
IAM と作業ロール

VPC Network Peering を作成・更新・削除するためには、プロジェクトに対して次のいずれかが必要です。

  • Compute Network Admin ロール（roles/compute.networkAdmin）
  • または、以下の権限を含むカスタムロール:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

実務的には、

  • それぞれの VPC を管理する Network Admin が、自分の側の Peering 設定を行う
  • 別組織間であれば、両組織の Network Admin 同士で事前に IP 設計とルートエクスポートポリシーを調整したうえで、それぞれのプロジェクトで Peering 設定を実行

というイメージです。

セキュリティ観点での注意点（ACE 向け）

VPC Network Peering を使うときの代表的な注意点をまとめます。

  • Firewall は共有されない
    • 「Peering 相手の VM に付いている service account や network tag を、こちらの VPC の Firewall で参照する」といったことはできない
    • 各 VPC の Firewall の対象 / ソースは、その VPC 内のインスタンスに限られる
  • 暗黙の deny ingress / allow egress は VPC ごとに独立
    • 各 VPC には暗黙の「全ての ingress deny」「全ての egress allow」が存在する
    • Peering しただけでは ingress は許可されないので、明示的に許可ルールを作る必要がある
  • DNS / Cloud DNS の扱いも独立
    • Compute Engine の内部 DNS 名は、Peering 先からは利用できない
    • Private Zone を共有するには Cloud DNS の peering zone など別機能が必要

ACE 試験では、

「2つのプロジェクトの VPC を相互接続したい。組織が異なり、互いの IAM や Firewall 管理は分離したい」

という条件が出てきたら、VPC Network Peering を使う選択肢が最有力となります。

5.4.3 Shared VPC の基本と権限制御

Shared VPC の構成モデル

Shared VPC は、1 つの組織内でプロジェクトを分割しつつ、ネットワークだけは集中管理したい場合に使う仕組みです。

公式ドキュメントの要点は次のとおりです。

  • Shared VPC は組織（Organization）単位の機能
  • 1 つのプロジェクトを ホストプロジェクト として指定し、その中の VPC ネットワークが Shared VPC ネットワーク となる
  • 他のプロジェクトを サービスプロジェクト としてホストプロジェクトにアタッチすると、サービスプロジェクト内のリソース（VM, GKE など）がホストプロジェクトのサブネットを利用できる
  • ネットワークリソース（サブネット / ルート / ファイアウォールなど）はホストプロジェクト側で集中管理
  • サービスプロジェクト側では、インスタンスなどのリソースを、自分のプロジェクトに対してだけ作成・管理する

整理すると、

  • 「VPC をまとめる」のが Shared VPC
  • 「プロジェクトを分けつつ、ネットワークだけを共用」する設計

です。

Shared VPC の管理ロール（公式の役割）

Shared VPC では、管理者の役割がかなり細かく定義されています。公式の「Administrators and IAM」節から主要なロールだけ抜き出します。

  1. Organization Admin
    • ロール: resourcemanager.organizationAdmin
    • Shared VPC Admin を任命したり、組織ポリシーを設定する立場
  2. Shared VPC Admin
    • ロール:
      • roles/compute.xpnAdmin（Compute Shared VPC Admin）
      • roles/resourcemanager.projectIamAdmin（Project IAM Admin）
    • 主な責務:
      • プロジェクトをホストプロジェクトとして有効化
      • サービスプロジェクトをホストプロジェクトにアタッチ / デタッチ
      • サービスプロジェクトに対して、どのサブネットを利用可能にするかを委譲
  3. Service Project Admin
    • ロール:
      • roles/compute.networkUser（Network User）を、ホストプロジェクト全体または特定サブネットに対して付与
      • さらにサービスプロジェクト側では roles/compute.instanceAdmin などでインスタンス管理権限を持つ
    • 主な責務:
      • 自分のサービスプロジェクト内でインスタンス（VM / GKE など）を作成・削除
      • Shared VPC で共有されたサブネットを「使う」ことはできるが、ネットワーク設定そのものは変更できない
  4. Network Admin / Security Admin（任意で委譲）
    • Network Admin: roles/compute.networkAdmin
      • ホストプロジェクト内のネットワークリソース（VPC, サブネット, ルートなど）を管理
    • Security Admin: roles/compute.securityAdmin
      • ファイアウォールルールや SSL 証明書の管理

Google Cloud の IAM Job Functions のドキュメントでも、Shared VPC を前提としたロール構成例として、

  • 組織レベルで
    • Shared VPC Admin
    • Network Admin
    • Security Admin
  • ホストプロジェクトレベルで
    • Network User（開発者用）
  • サービスプロジェクトレベルで
    • Network User
    • Instance Admin

を割り当てる構成が紹介されています。

Shared VPC の権限制御のポイント

Shared VPC の肝は、「ネットワークの集中管理」と「開発チームへの最小限の権限委譲」です。

誰が何を管理するのか
  • Shared VPC Admin / Network Admin / Security Admin（ネットワークチーム）
    • ホストプロジェクトの VPC・サブネット・ルート・VPN・ファイアウォールなどを管理
    • どのサービスプロジェクトにどのサブネットを使わせるかを決定
  • Service Project Admin / 開発チーム
    • 自分のサービスプロジェクトに限定して、VM / GKE クラスタ / Cloud Run コネクタなどを作成
    • Shared VPC のサブネットを「利用」する立場であり、サブネット自体やファイアウォールルールは編集できない
compute.networkUser ロールの意味

roles/compute.networkUser は、Shared VPC で最も重要なロールの 1 つです。

  • 付与されたプリンシパルは、ホストプロジェクトの共有サブネットを「使う」権限を持つ
    • 具体的には、そのサブネットを NIC の接続先として指定して VM や GKE ノードを作成できる
  • Network User ロールは
    • ホストプロジェクト全体に対して付与することも
    • 特定サブネット単位で付与することもできる
  • サブネット単位で付与すると、
    • 「開発チーム A は dev-subnet のみ利用可」
    • 「開発チーム B は prod-subnet も利用可」
      といったきめ細かい分離が可能
組織ポリシーとの併用

Shared VPC では、組織ポリシーと IAM を組み合わせることで、さらに厳密な制御もできます。

例:

  • constraints/compute.restrictSharedVpcHostProjects
    • どのホストプロジェクトにサービスプロジェクトをアタッチできるか制限
  • constraints/compute.restrictSharedVpcSubnetworks
    • サービスプロジェクトが利用できる Shared VPC サブネットを制限

ACE レベルでは、「Shared VPC + Organization Policy でネットワーク利用を制約できる」程度の理解で十分です。

5.4.4 ACE 試験向け：Peering / Shared VPC の使い分けシナリオ

ここからは、試験に出やすいパターンを整理します。

シナリオ 1: 異なるチーム / 組織の VPC を相互接続したい

要件例:

  • プロジェクトや組織が異なる 2 つのチームが、それぞれの VPC 上のサービスを内部 IP で相互接続したい
  • しかし、ファイアウォールや IAM の管理は完全に分離したい

解答パターン

  • VPC Network Peering を使用
  • 各 VPC の Network Admin に roles/compute.networkAdmin を付与し、Peering 設定をそれぞれの側で実施
  • Firewall ルールは各 VPC 内で独立して設定

なぜ Shared VPC ではないか

  • Shared VPC は同一組織内かつネットワークを集中管理する前提
  • 「組織が異なる」「ネットワーク管理も分離したい」条件では Peering 一択
シナリオ 2: 単一組織内でネットワークだけ集中管理したい

要件例:

  • 大企業の中で、開発チームごとにプロジェクトを分け、コストや権限を分離したい
  • しかし VPC・サブネット・VPN・ファイアウォールはネットワークチームが集中管理したい

解答パターン

  • Shared VPC を利用し、
    • 組織レベルで Shared VPC Admin / Network Admin / Security Admin を設定する
    • ホストプロジェクトに共通 VPC を作成
    • 各アプリケーションチームのプロジェクトをサービスプロジェクトとしてアタッチ
    • サービスプロジェクトの開発者には
      • サービスプロジェクトに対して compute.instanceAdmin
      • ホストプロジェクトまたは特定サブネットに対して compute.networkUser
        を付与

ポイント

  • 「ネットワークとセキュリティは中央チーム、それ以外は開発チーム」という職務分離を IAM で表現できる
シナリオ 3: サービスプロジェクトから Shared VPC を使って GKE / Cloud Run をデプロイ

要件例:

  • Shared VPC 環境で、サービスプロジェクト側のチームが
    • GKE クラスタ
    • Serverless VPC Access コネクタ
    • Cloud Run など
      を自律的に作成したい

解答パターン

  • Shared VPC Admin / Network Admin はホストプロジェクトのサブネットとファイアウォールを設計
  • サービスプロジェクト側には
    • Shared VPC のサブネットに対する compute.networkUser
    • 自プロジェクトに対する compute.instanceAdmin など
      を付与し、リソース作成を可能にする
  • ファイアウォールルールの作成 / 更新は、原則ホストプロジェクト側の Security Admin が実施
    • 例: Cloud Run からのトラフィックを許可する Firewall ルールは compute.securityAdmin を持つユーザーがホストプロジェクトで作成する

5.4.5 Peering / Shared VPC まわりでの典型的な誤解

最後に、試験で狙われやすい勘違いを整理します。

誤解 1: 「Peering するとファイアウォールやタグも共有される」

実際は

  • VPC Network Peering はルートのみを交換し、
    • Firewall ルールや Firewall Policy は共有しない
  • network tag や service account を、Peering 先のファイアウォールから参照することはできない
誤解 2: 「Shared VPC を使えば組織をまたいでネットワークを共有できる」

実際は

  • Shared VPC は 同一 Organization 内のプロジェクト 同士を対象とする機能
  • 組織をまたぐ場合は VPC Network Peering や Private Service Connect など別の手段
誤解 3: 「Shared VPC でサービスプロジェクトに Network Admin を渡せば楽」

実際は

  • Shared VPC の目的は、「ネットワークを集中管理しつつ、サービスプロジェクト側には最小限の権限だけ渡す」こと
  • サービスプロジェクト側には compute.networkUser + compute.instanceAdmin など、リソース作成に必要なロールのみに留めるのがベストプラクティス
誤解 4: 「Peering を 3 本張れば簡易ハブ＆スポークになる」

実際は

  • Peering は トランジティブではない
    • net-a ↔ net-b、net-a ↔ net-c だけでは net-b ↔ net-c はつながらない
  • ハブ＆スポークを実現したい場合は、
    • 各スポークとハブを Peering しつつ、Firewall とルート設計で要件を満たすか
    • Private Service Connect や Cloud VPN / Interconnect を検討する

5.4.6 まとめ：ACE レベルで押さえておくべきポイント

Peering と Shared VPC の出題は、「どの構成を選ぶか」「どのロールをどこに付けるか」で差がつきます。

  • VPC Network Peering
    • 別々の VPC を内部 IP で直接つなぐ
    • サブネット IP 範囲は重複不可、トランジティブではない
    • 管理は完全に分離。Firewall / IAM は共有されず、各 VPC の Network Admin / Security Admin が自分のネットワークだけを管理する
  • Shared VPC
    • 組織内の複数プロジェクトで、1 つの VPC を共有
    • ホストプロジェクトでネットワークを集中管理し、サービスプロジェクトには compute.networkUser など最低限の権限でサブネット利用を委譲
    • Shared VPC Admin / Network Admin / Security Admin / Service Project Admin といった役割に応じて IAM ロールを分ける

ここまで整理できていれば、ACE 試験の「Peering / Shared VPC / 権限制御」まわりの問題には、かなり余裕を持って対応できるはずです。

5.5 負荷分散（L4 / L7）

この節では、Google Cloud のロードバランサを L4 / L7 の観点から整理しつつ、

  • どの種類の LB をいつ選ぶべきか
  • ACE 試験でよく出る構成パターン

をまとめます。

Google Cloud の Cloud Load Balancing は、すべてフルマネージドでスケーラブルなサービスで、HTTP(S) / TCP / UDP / SSL などのトラフィックを扱えます。

5.5.1 Cloud Load Balancing 全体像

2023 年のリブランディング以降、Google Cloud のロードバランサはざっくり次の 2 系統に整理されています。

  1. Application Load Balancer（L7）
    • HTTP / HTTPS トラフィック向け
    • コンテンツベース（URL / ホスト名）でルーティング可能
    • TLS 終端、Cloud CDN / Cloud Armor との連携など「アプリ層」の機能を持つ
  2. Network Load Balancer（L4）
    • TCP / UDP / SSL などの L4 トラフィック向け
    • ゲーム、VoIP、独自プロトコルなどに利用
    • Proxy / Passthrough の 2 系統がある（後述）

さらに、以下の軸で分類できます。

  • トラフィックの向き
    • External（インターネットからの入口）
    • Internal（VPC 内 / ハイブリッド環境向け）
  • スコープ
    • Global / Cross-region（複数リージョンのバックエンドを束ねる）
    • Regional（単一リージョン内で完結）

ACE 試験の観点では、「HTTP(S) か、それ以外か」「外部向けか、内部向けか」「グローバルに配りたいか、リージョンで閉じたいか」を決めれば、ほぼ自動的に種類が絞れます。

5.5.2 L7: Application Load Balancer（HTTP(S)）

特徴

公式ドキュメントでは、Application Load Balancer は HTTP / HTTPS トラフィックを扱う L7 ロードバランサとして説明されています。

主な特徴は次の通りです。

  • コンテンツベースルーティング
    • URL パス / ホスト名 / ヘッダなどを見てバックエンドを切り替え
    • 例: /api/* は GKE、/static/* は Cloud Storage のバケット（Cloud CDN 経由）など
  • グローバル anycast IP（外部 Application LB の場合）
    • 単一のグローバル IP で世界中からのトラフィックを受け付け、
      近い Google フロントエンド（GFE）経由で最適なリージョンにルーティング
  • HTTPS / TLS 終端
    • LB で証明書を持ち、TLS 終端を実施
    • バックエンドとの間は HTTP / HTTPS のどちらも選択可能
  • バックエンドの種類
    • インスタンスグループ（MIG）
    • ネットワーク エンドポイント グループ（NEG、GKE / Serverless 向けなど）
    • Cloud Run / Cloud Functions / App Engine などのサーバーレス NEGs
  • Cloud Armor / Cloud CDN と統合
    • WAF / DDoS 防御（Cloud Armor）や、コンテンツキャッシュ（Cloud CDN）と密に連携
外部 / 内部 Application Load Balancer
  • 外部 Application Load Balancer（External ALB）
    • インターネット向けの HTTP(S) フロントエンド
    • 単一グローバル IP で複数リージョンのバックエンドに振り分け可能（グローバル LB）
  • 内部 Application Load Balancer（Internal ALB）
    • VPC 内（またはハイブリッド環境）からのみアクセスできる HTTP(S) LB
    • マイクロサービス間通信や、社内限定 Web アプリなどに利用

ACE では、問題文に「単一のグローバル IP」「パスベースルーティング」「Cloud CDN / Cloud Armor」あたりのキーワードが出たら、Application Load Balancer（外部 HTTP(S)） を選ぶパターンが多いです。

5.5.3 L4: Network Load Balancer（TCP / UDP）

Network Load Balancer の種類

Network Load Balancer は L4 トラフィック向けで、TCP / UDP / SSL などを扱います。

大きく以下の形態があります（細かい SKU 名は ACE ではそこまで重要ではありません）。

  1. 外部 Passthrough Network Load Balancer
    • クライアント → LB → バックエンド間で TCP/UDP セッションをほぼそのまま中継
    • ゲームサーバ / VoIP / 独自 TCP プロトコルなどに向く
    • クライアント IP をそのままバックエンドに届けやすい構造
  2. 外部 Proxy Network Load Balancer（TCP / SSL Proxy）
    • クライアントとの TCP / SSL セッションを LB で受け、バックエンドに別セッションとして中継
    • TLS 終端が必要だが L7 の高度な機能は不要なケースなどで利用
  3. 内部 TCP/UDP Load Balancer（Internal L4）
    • VPC 内 / ハイブリッド環境向けの L4 内部 LB
    • DB のフロント、アプリケーションの内部エンドポイントなどに利用
    • 「ILB Global Access」機能により、同一 VPC 内の他リージョンからのアクセスも可能
典型的なユースケース
  • オンラインゲーム / VoIP / 独自バイナリプロトコル:
    • → External Network Load Balancer（Passthrough）
  • 内部向けの TCP/UDP サービスをスケールさせたい:
    • → Internal TCP/UDP Load Balancer
  • TLS 終端をしたいが、HTTP レベルのルーティングは不要（L7 はいらない）:
    • → TCP / SSL Proxy Network Load Balancer

ACE では、「HTTP ではない TCP/UDP ワークロード」「クライアント IP をそのまま見たいリアルタイム系サービス」などが出てきたとき、Network Load Balancer 系列を選ぶかどうかがポイントになります。

5.5.4 L4 / L7 負荷分散の構成判断軸

ここからは、試験での「どれを選ぶか？」に直結する判断軸を整理します。

プロトコル: HTTP(S) か、それ以外か
  • HTTP / HTTPS / gRPC / WebSocket などアプリ層ベース
    • → Application Load Balancer（L7）
    • URL パス / ホスト / ヘッダでルーティングしたいときは必ずこちら
  • TCP / UDP / SSL のみ
    • → Network Load Balancer（L4）
    • ゲーム、VoIP、DB の TCP 接続など

試験の選択肢では、「HTTP(S) トラフィックだが L4 LB を選んでいる」パターンがわりと罠として出てきます。

外部向けか、内部向けか
  • インターネットからアクセスさせるサービス
    • External Application Load Balancer（HTTP(S)）
    • External Network Load Balancer（TCP/UDP）
  • VPC 内、またはオンプレ／VPN／Interconnect 経由の内部クライアント専用
    • Internal Application Load Balancer（HTTP(S)）
    • Internal TCP/UDP Load Balancer（L4）

問題文に「インターネットからアクセスさせない」「内部システム間のみ」とあれば、Internal 系を選ぶのが基本です。

グローバルか、リージョン閉じか
  • 世界中から単一の IP でアクセスさせたい / マルチリージョン配備を単一エンドポイントで隠したい
    • → Global / Cross-region の External Application Load Balancer
  • 特定リージョン内だけで閉じたい（データ所在・規制対応など）
    • → Regional Load Balancer（Regional ALB / NLB / Internal LB など）

ACE の問題では、「単一グローバル IP」「マルチリージョン」「最寄りリージョンへ自動ルーティング」などがあれば Global Application Load Balancer を選ぶ流れになります。

5.5.5 ACE 試験でよく出るパターン

ACE 試験ガイドでも、「ロードバランサの選択とデプロイ」が明示的なトピックになっています。

ここでは、問題文に出てきがちな典型シナリオを整理します。

パターン 1: グローバルに公開する HTTP(S) Web アプリ

要件:

  • 世界中のユーザーからアクセス
  • 単一グローバル IP / ドメインで提供したい
  • URL によってバックエンドサービスを分けたい（/api / /static など）
  • Cloud CDN / Cloud Armor も活用したい

正解パターン

  • External Application Load Balancer（グローバル HTTP(S)）
  • バックエンド:
    • MIG（Compute Engine）
    • NEG（GKE / Cloud Run / App Engine）など
パターン 2: 社内専用のマイクロサービス HTTP API

要件:

  • 社内システム / 他 VPC / オンプレからのみアクセス
  • HTTP ベースの API
  • サービス間通信を VPC 内だけで完結させたい

正解パターン

  • Internal Application Load Balancer
  • VPC 内からの HTTP(S) 通信を集約
  • Cloud VPN / Interconnect 経由のオンプレからも、内部 IP 宛にアクセスさせる
パターン 3: TCP ベースのゲームサーバ / VoIP

要件:

  • インターネットから TCP/UDP で接続
  • クライアント IP をアプリ側で認識したい
  • レイテンシ重視、HTTP レベルの機能は不要

正解パターン

  • External Network Load Balancer（Passthrough）
  • バックエンドは MIG / 個別 VM
  • 必要に応じて地域ごとの NLB を用意
パターン 4: VPC 内の DB への負荷分散

要件:

  • 内部専用の DB を複数レプリカで提供
  • アプリケーションからは単一 IP で接続したい
  • インターネットには公開しない

正解パターン

  • Internal TCP/UDP Load Balancer
  • バックエンドに複数 DB ノード（VM）を登録
パターン 5: 複数リージョンのバックエンドを単一 IP で束ねたい

要件:

  • asia-northeast1 と us-central1 にバックエンド
  • 利用者からは単一の IP / FQDN を見せたい
  • 近いリージョンに自動でルーティングしたい

正解パターン

  • Global External Application Load Balancer
  • 各リージョンに MIG / NEG を作成し、LB のバックエンドサービスに登録

5.5.6 試験で狙われやすいミスと対策

最後に、「やらかしポイント」を ACE 目線でまとめます。

ミス 1: HTTP アプリに Network Load Balancer を選ぶ

ありがち

  • 「TCP だし L4 でいいか」と考えて Network LB を選択
  • しかし、問題文には「パスベースルーティング」「Cloud CDN」など L7 機能が要求されている

対策

  • L7 機能（URL ルーティング / Cloud CDN / Cloud Armor / Host header ベースなど）が出てきたら、必ず Application Load Balancer を選ぶ
ミス 2: 内部向けシステムに External LB を選ぶ

ありがち

  • 「LB といえば外部 HTTP(S) LB」という思い込みで External の方を選んでしまう

対策

  • 問題文に「インターネットからアクセスさせない」「社内のみ」「オンプレ専用」などがあれば、Internal Application / Internal TCP/UDP Load Balancer を第一候補にする
ミス 3: クライアント IP の保持要件を見落とす

一部のプロキシ型 LB（特に HTTP(S) / TCP/SSL Proxy）では、バックエンドから見える「接続元 IP」は LB になることがあります。クライアント IP はヘッダ（X-Forwarded-For など）や Proxy Protocol で渡される形になります。

対策

  • 問題文に「アプリケーションはクライアント IP に基づき処理を行う」「L4 レベルでクライアント IP が必要」などがあれば、
    Passthrough Network Load Balancer を優先的に検討する
ミス 4: グローバルに配りたいのにリージョナル LB を選ぶ

ありがち

  • 「リージョン A と B にバックエンドを用意し、ユーザーから近いリージョンに自動で振り分けたい」
  • にもかかわらず、Regional LB を 2 つ作る選択肢を選んでしまう

対策

  • 「単一グローバル IP」「マルチリージョン」「自動ルーティング」と書かれていれば、
    → Global External Application Load Balancer 一択、というパターンを身体に刻んでおく

この節の内容が整理できていれば、

  • どの LB を選ぶか
  • L4 / L7・外部 / 内部・グローバル / リージョンといった切り分け

で迷うことはかなり減ります。
あとは問題文に出てくるキーワードを、ここで整理した判断軸に機械的にマッピングできるかどうか、という勝負になります。

前の記事
次の記事