Deep Dive: Networking
Professional Cloud Architect 試験で問われるネットワーク全領域を、公式ドキュメントベースで技術深掘りします。VPC・Shared VPC・PSC・Load Balancer 7 種・Interconnect・HA VPN・Cloud NAT・Cloud Armor・Cloud CDN まで、SLA・クォータ・アンチパターンを含めて網羅。
🌐 全 12 章
📊 数値・SLA・クォータ完全網羅
🎯 試験頻出パターン付き
📚 公式 13 ドキュメント参照
⚠️ アンチパターン解説
🔧 設計判断
🎯 試験頻出
⚠️ アンチパターン
📋 クォータ
✅ ベストプラクティス
🔑 TL;DR — このページの結論
VPC はグローバル、Subnet はリージョナル。プロジェクト境界をまたぐ通信は Shared VPC（同組織で統制したい）か VPC Peering（独立統制）か PSC（サービスとして公開）のどれか。グローバル展開は Global External Application LB（Premium Tier）を即答。ハイブリッドは可用性 99.99% なら Dedicated/Partner Interconnect 冗長構成または HA VPN 二重トンネル。マルチクラウドは Cross-Cloud Interconnect。ハブ&スポーク統合管理は Network Connectivity Center。インターネット向け WAF/DDoS は Cloud Armor Enterprise、エッジキャッシュは Cloud CDN。外部 IP なし VM の egress は Cloud NAT（ポート枯渇に注意）。
📚 参照する公式ドキュメント
本資料は以下の Google Cloud 公式ドキュメント（2026 年時点）から技術詳細・制限・SLA・ベストプラクティスを抽出しています。各章で都度引用と URL を併記します。
| # | 領域 | 公式 URL |
|---|---|---|
| 1 | VPC overview | cloud.google.com/vpc/docs/vpc |
| 2 | Shared VPC | cloud.google.com/vpc/docs/shared-vpc |
| 3 | VPC Peering | cloud.google.com/vpc/docs/vpc-peering |
| 4 | Private Service Connect | cloud.google.com/vpc/docs/private-service-connect |
| 5 | Network Connectivity Center | cloud.google.com/network-connectivity/docs/network-connectivity-center |
| 6 | Cloud Load Balancing | cloud.google.com/load-balancing/docs/load-balancing-overview |
| 7 | Cloud Interconnect | cloud.google.com/network-connectivity/docs/interconnect |
| 8 | HA VPN / Classic VPN | cloud.google.com/network-connectivity/docs/vpn |
| 9 | Cross-Cloud Interconnect | cloud.google.com/network-connectivity/docs/cci |
| 10 | Cloud NAT | cloud.google.com/nat/docs/overview |
| 11 | Cloud Armor | cloud.google.com/armor/docs/cloud-armor-overview |
| 12 | Cloud CDN | cloud.google.com/cdn/docs/overview |
| 13 | Firewall Rules | cloud.google.com/firewall/docs/firewalls |
1ネットワークの全体像
Google Cloud のネットワーク階層は、伝統的なオンプレや AWS の VPC とはスコープが大きく異なります。VPC がグローバル、サブネットがリージョナルで、ルートとファイアウォールはネットワーク全体に適用される、という構造を体に染み込ませることが第一歩です。
「VPC networks are global resources; subnets are regional resources; routes and firewall rules are global resources applied to VMs.」 — VPC overview
1.1 リソースのスコープ階層（SVG 図解）
図 1-1：VPC は Organization 配下の Project に属するが、ネットワーク自体はグローバル。サブネットだけがリージョン単位で、リージョン間通信は Google のプライベートバックボーンを経由します。
1.2 4 つのリソースタイプとスコープ
| リソース | スコープ | 用途 | 備考 |
|---|---|---|---|
| VPC Network | Global | 論理ネットワーク | 1 プロジェクトに複数作成可（デフォルトクォータ 5） |
| Subnet | Regional | IP レンジを切り出し | 1 リージョン 1 サブネットが基本（複数も可） |
| Route | Global (VPC 単位) | パケット転送先 | System / Static / Dynamic（BGP） |
| Firewall Rule | Global (VPC 単位) | 許可/拒否 | ステートフル、優先度 0-65535 |
| Internal IP | Regional | VM/LB 内部 IP | Primary + Alias + Secondary レンジ |
| External IP (Standard Tier) | Regional | 外部接続 | リージョンに紐付く |
| External IP (Premium Tier / Global LB) | Global Anycast | グローバル LB の VIP | 1 IP で全リージョン到達 |
🔑 試験頻出
「VPC は Global リソース、Subnet は Regional」「ファイアウォール / ルートは VPC 全体に適用」は反射的に答えられること。AWS の VPC=Regional / Subnet=AZ モデルとは根本的に異なる点が出題される。
1.3 ネットワーク作成モード（Auto / Custom / Default / Legacy）
| モード | サブネット作成 | 本番適性 | 使うべきケース |
|---|---|---|---|
| Default | 各リージョンに自動 + 6 つのデフォルトファイアウォール | 非推奨 | 学習・PoC のみ。組織ポリシーで無効化が推奨 |
| Auto mode | 各リージョンに 10.128.0.0/9 から自動 | 限定推奨 | シンプル PoC、CIDR 競合を気にしない場合 |
| Custom mode | 手動で CIDR を選択 | 推奨 | 本番、ハイブリッド、マルチクラウド全て |
| Legacy | サブネットなし（単一 IP レンジ） | 廃止 | 新規作成不可。既存マイグレーション対象 |
📋 公式制限 — Auto モードの落とし穴
Auto モードは
10.128.0.0/9 の固定 CIDR を使うため、オンプレや AWS と CIDR が重なる可能性が高く、後から Interconnect / VPC Peering を引いたときに衝突します。本番系は最初から Custom モードを選び、CIDR は IPAM で集中管理するのがベストプラクティス。
1.4 IP アドレスタイプの完全分類
| 分類 | レンジ | 持ち手 | 用途 |
|---|---|---|---|
| Subnet Primary IPv4 | 必須 1 つ | VM の NIC、LB | VM の標準内部 IP |
| Subnet Secondary IPv4 | オプション | Alias IP / GKE Pod / Service | GKE は Pod レンジと Service レンジを Secondary で確保 |
| Alias IP | VM 単位の追加内部 IP | VM | 1 つの VM に複数サービスをホスト |
| Internal IPv6 | VPC 内のみ | VM | Publicly Routable ではない（ULA 風） |
| External IPv6 | パブリック | VM/LB | Public Routable |
| Ephemeral External IP | 動的 | VM | VM 停止で解放 |
| Static External IP | 固定 | VM / Global LB | Regional / Global の 2 種 |
| PSC Endpoint IP | Consumer 側 Internal | サービス公開 | 後述 PSC 章 |
📖 各サブネット primary range で予約される 4 つの IP
公式仕様：「Four unusable addresses per primary IPv4 subnet」。たとえば 10.0.0.0/24 なら：
10.0.0.0— ネットワークアドレス10.0.0.1— デフォルトゲートウェイ（VPC 側）10.0.0.254— 第二リザーブ（将来用途）10.0.0.255— ブロードキャスト（GCP では使用不可）
つまり /24 は 256 − 4 = 252 個が VM に割り当て可能。大規模 GKE クラスタの Pod レンジを設計する際、この 4 個分の損失を考慮しないと、サブネットが満杯になって Pod を追加できない事故が起きます。
Secondary レンジも同様に 4 つ予約されますが、GKE はそれを織り込んでサイジング推奨表を出しています。
1.5 Dynamic Routing Mode（Regional vs Global）
Cloud Router で受信した BGP ルートを、VPC 内のどのリージョンに伝播させるかを決める設定です。これは設計時に必ず決断する重要パラメータ。
Regional
同一リージョンのみに学習
Cloud Router が受け取ったオンプレ ルートは、その Cloud Router と同じリージョンの VM だけが利用できます。
適合：データ ローカリティ厳格 / マルチリージョン VPN を独立して運用したい
Global
全リージョンに伝播
1 リージョンに引いた Interconnect / HA VPN を、VPC 内全リージョンの VM がオンプレ通信に利用できます。
適合：単一拠点接続を全社共通化したい / リージョン障害時のフェイルオーバー経路を確保したい
⚠️ よくある失敗 — Regional のまま放置
VPC を最初に作成するとデフォルトは Regional。後からマルチリージョン展開すると、東京の Cloud Router が学習したオンプレ ルートを大阪 VM が知らず、「なぜか大阪 VM がオンプレに繋がらない」事故が頻発。マルチリージョン化の予定がある VPC は最初から Global 推奨。
1.6 試験での出題パターン（Chapter 1）
🎯 頻出問題のパターン
- 「リージョン障害時に別リージョンの VM がオンプレへ通信を継続するには？」→ Dynamic Routing Mode = Global
- 「2 つの VPC で
10.0.0.0/16が重複している」→ サブネット CIDR をリナンバーするしかない（Peering 不可、PSC や NAT で迂回） - 「Custom mode vs Auto mode」→ 本番は Custom 一択。理由：CIDR コリジョン、不要サブネット、攻撃面
2VPC 設計パターン
「プロジェクトをいくつに分けるか」「VPC をいくつにするか」「どう繋ぐか」は、組織構造と統制レベルで決まります。Google Cloud の正解は基本的に 3 つに集約されます。
2.1 4 つの代表パターン
| パターン | プロジェクト数 | VPC 数 | 適合シナリオ | 長所 | 短所 |
|---|---|---|---|---|---|
| 1. 単一プロジェクト・単一 VPC | 1 | 1 | スタートアップ / PoC / 個人開発 | シンプル、課金一元化 | 権限分離不可、本番/開発混在リスク |
| 2. 環境別プロジェクト・独立 VPC | 3〜n (dev/stg/prd) | 各 1 | 中規模、環境完全分離が必要 | 権限・課金・障害が独立 | 共通サービスを各 VPC で重複構築 |
| 3. Shared VPC (Host + Service) | ホスト 1 + サービス n | 1（共通） | 大企業、集中ネットワーク統制 | 統制と分離の両立、コスト集中管理 | 組織が同一である必要、設計初期工数 |
| 4. Hub-and-Spoke (NCC) | 多数 | 多数 | マルチリージョン / マルチクラウド / 旧オンプレ + 子会社統合 | 推移性、第三者アプライアンス活用 | 運用複雑、コスト |
2.2 設計決定ツリー
Q1: 同一組織内のチームを 1 つのネットワークに統合したいか？
YES → Q2 へ
NO → 独立 VPC + VPC Peering / PSC
▼
Q2: ネットワーク管理を中央集権化したいか？
YES → Shared VPC
NO → 各プロジェクト独立 + Peering
▼
Q3: オンプレ・他クラウド・複数 VPC を統合管理したいか？
YES → Network Connectivity Center (Hub-and-Spoke)
NO → Shared VPC のまま運用
2.3 Shared VPC の構造（SVG）
図 2-1：Host Project がネットワーク（VPC、Subnet、Firewall）を集中管理し、Service Project は Network User ロールを Subnet 単位で受けて VM を建てます。課金はリソース所有 Service Project に分散。
「Billing for resources that participate in a Shared VPC network is attributed to the service project where the resource is located.」 — Shared VPC docs
2.4 Shared VPC の重要ポイント
構造
- Host Project は 1 つ、Service Project は複数（n:1 関係）
- 1 Service Project は 1 Host Project にのみアタッチ可（多重所属不可）
- Host Project に他の Service Project を兼ねさせることは不可
- 組織（Organization）内のみで成立。組織を跨ぐ場合は VPC Peering
統制と分離
- ネットワーク統制は Host で集中（CIDR、Firewall、Route）
- 各 Service Project の IAM は独立（チーム自治）
- Service Project は Subnet 単位で Network User を付与
- 課金は Service Project に分散（部門ごとに把握可能）
⚠️ よくある失敗 — Service Project を別組織に移動
Shared VPC は同一 Organization 内でのみ成立します。買収・分社で Service Project を別 Organization に移そうとすると、まず Shared VPC のアタッチを解除する必要があり、その間 VM が新規作成不可になります。設計段階で Organization の境界を確定させてください。
2.5 Hub-and-Spoke パターン
図 2-2：Hub-and-Spoke は VPC Peering の非推移性を回避するパターン。NCC のフルメッシュ機能、または Hub に NVA を置いてルーティングします。
💡 ベストプラクティス
Hub-and-Spoke は 3 拠点以上を統合するときに採用。2 拠点なら単純 Peering で十分。NCC を使うと、複数 VPC・Interconnect・VPN・Router Appliance を 同じハブに登録して、推移的なルーティングを宣言的に管理できます（後述 §7）。
2.6 試験での出題パターン（Chapter 2）
🎯 頻出問題のパターン
- 「セキュリティチームが全 VPC のファイアウォールを統制したい」→ Shared VPC + 階層型ファイアウォール（Hierarchical FW Policy）
- 「各事業部に課金を分けたいが、ネットワークは一元管理」→ Shared VPC（課金は Service Project に分散）
- 「複数の買収子会社（別 Organization）を統合」→ Shared VPC は不可、Peering または NCC を使用
- 「Service Project を別 Host にも所属させたい」→ 不可（1:1 制約）。NCC を検討
3VPC Peering vs Shared VPC vs PSC
「VPC を跨いだ接続」の選択肢は 3 つ：VPC Peering（ネットワーク同士を平面接続）、Shared VPC（複数プロジェクトで 1 つの VPC を共有）、Private Service Connect（サービスとして公開）。混同しがちですが、用途は明確に異なります。
3.1 3 方式の本質比較
| 観点 | VPC Peering | Shared VPC | Private Service Connect |
|---|---|---|---|
| 本質 | 2 VPC をネットワークレイヤで結合 | 1 VPC を複数プロジェクトで共有 | サービスを内部 IP で公開 |
| 方向 | 双方向（フルメッシュ可） | n:1（複数 Service が 1 Host を利用） | Producer → Consumer の片方向 |
| Organization 越え | ✅ 可能（別組織でも OK） | ❌ 不可（同一 Org のみ） | ✅ 可能 |
| CIDR 重複 | ❌ 不可（リナンバー必要） | ❌ 不可 | ✅ 可能（NAT で吸収） |
| 推移性 | ❌ 非推移（A↔B、B↔C があっても A↔C 不可） | ✅ 推移（同じ VPC 内） | — |
| クォータ | 1 VPC あたり 25 Peering | Host あたり Service 数制限あり | Consumer 側 Endpoint 数制限あり |
| DNS | ⚠️ 内部 DNS 非伝播 | ✅ 同一 VPC 内で解決 | Service Directory 連携可 |
| ファイアウォール | 各 VPC で独立管理 | Host で集中管理 | Consumer 側で制御 |
| 典型ユース | 本社 ↔ 子会社、別組織連携 | 大企業内の統制された分離 | SaaS 公開、マネージドサービス利用 |
3.2 選定決定ツリー
Q1: 接続したい先は「サービス」か「ネットワーク」か？
サービス (DB / API / SaaS) → Private Service Connect
ネットワーク (VM/サブネット) → Q2 へ
▼
Q2: 同じ Organization か？
YES → Q3 へ
NO → VPC Peering
▼
Q3: ネットワーク統制を中央集権化したいか？
YES → Shared VPC
NO → VPC Peering
3.3 VPC Peering の落とし穴
「No subnet IP range can exactly match, contain, or fit within another subnet IP range in a peered VPC network.」 — VPC Peering docs
⚠️ Pitfall 1
非推移性
A ↔ B、B ↔ C があっても、A ↔ C は通信できません。3 拠点以上をフルメッシュにするには 3 つの Peering（A-B / B-C / A-C）が必要で、n 拠点では n(n-1)/2 接続になりクォータ 25 をすぐ超えます。
⚠️ Pitfall 2
CIDR 重複不可
Peering 先の VPC とサブネット CIDR が 1 ビットでも重なれば Peering 自体が作成できません。買収後の VPC 統合で頻発する障害。
⚠️ Pitfall 3
内部 DNS 非伝播
Peering 先の VM の内部 DNS 名（vm.zone.c.project.internal）は解決できません。Cloud DNS Peering や Service Directory を別途設定。
⚠️ Pitfall 4
Firewall タグ非伝播
Peering 先の Network Tag や Service Account はソース指定で参照できません。IP 範囲ベースでファイアウォールを書く必要があります。
📖 VPC Peering の公式制限値（クリックで展開）
- 1 VPC あたり最大 25 Peering（増加リクエスト可）
- サブネット CIDR の重複・包含・含有禁止（プレフィックス長違いでも不可）
- サブネット ルートは常に交換（IPv4 プライベート）
- カスタム ルート（静的 / BGP）は
--export-custom-routes/--import-custom-routesで明示的に有効化が必要 - パブリック ルーティング IP は交換オプション
- 非推移性：A↔B、B↔C で A↔C は通信不可
- Connection tracking は最小 10 分（ファイアウォール ステートフル）
3.4 試験での出題パターン（Chapter 3）
🎯 頻出問題のパターン
- 「PostgreSQL を自社 VPC でホストし、別組織の顧客にプライベート提供」→ PSC for Published Services（CIDR 重複も吸収）
- 「Shared VPC と VPC Peering の使い分け」→ Shared = 同一組織で統制、Peering = 別組織 or 独立統制
- 「20 拠点を全てフルメッシュ Peering」→ クォータ超過。NCC または Hub VPC + NVA に変更
4Private Service Connect 完全解剖
PSC は近年の試験で必出。「外部 IP を持たずにマネージドサービスに接続したい」「自社サービスをプライベートに公開したい」「マルチテナント SaaS を提供したい」という設計要件への即答カードです。
4.1 3 つのバリエーション
バリエーション 1
PSC for Google APIs
Cloud Storage、BigQuery、Pub/Sub などの Google APIs を、外部 IP なしの VM から内部 IP 経由で利用。
対比：Private Google Access (PGA) はサブネット属性、PSC はエンドポイント。PSC の方が IP 名前空間を自由に選べ、VPC 単位で制御可能。
バリエーション 2
PSC for Published Services
自社が運用するサービス（VM / GKE / Internal LB）を、PSC Service Attachment 経由で他組織の VPC からプライベート利用させる。
用途：SaaS プロバイダー、組織を跨ぐマネージドサービス公開。
バリエーション 3
PSC for Managed Services
Cloud SQL、Memorystore、Vertex AI Online Prediction などの Google マネージドサービスを、Consumer VPC の内部 IP で利用。
対比：Private Services Access (PSA / VPC Peering 方式) より柔軟、CIDR コリジョン回避。
4.2 アーキテクチャ図（PSC for Published Services）
図 4-1：Consumer 側は好きな内部 IP で PSC Endpoint を建て、Producer 側は Service Attachment と NAT Subnet で受ける。CIDR の重複を気にせずプライベート接続できる点が PSC の最大の差別化要素。
「Private Service Connect delivers explicit authorization through granular controls and no shared dependencies since traffic between consumer and producers uses NAT.」 — PSC docs
4.3 Endpoint vs Backend の使い分け
PSC Endpoint
L4 直結
Consumer 側で Forwarding Rule を作るだけ。シンプルで遅延最小。
- 1 Endpoint = 1 Service Attachment 対応
- Failover は Producer 側責任
- Cloud SQL や Vertex AI など Google API 系で多用
PSC Backend
Consumer 側 LB
Consumer 側で Internal LB を建て、その backend に NEG として PSC Service Attachment を登録。
- 独自ドメイン・TLS 証明書を使える
- 複数リージョンの PSC を一つの LB で束ねる Failover が可能
- Consumer 側でレート制限や WAF を適用可
4.4 PSC for Managed Services（PSA との対比）
| 項目 | Private Services Access (PSA) | Private Service Connect (PSC) |
|---|---|---|
| 仕組み | VPC Peering で Google 管理 VPC と接続 | Endpoint + NAT で接続 |
| CIDR 重複 | ❌ 不可（Allocated IP Range を確保） | ✅ 可能（Consumer が IP 選択） |
| マルチ VPC 利用 | ⚠️ Peering を都度設定 | ✅ Endpoint を VPC ごとに作るだけ |
| 権限粒度 | Peering 単位 | Endpoint 単位（最小権限） |
| 対応サービス | Cloud SQL、Memorystore など旧来 | Cloud SQL、Filestore、Vertex AI Online、Memorystore、Spanner Data Boost など拡大中 |
| 推奨 | レガシー / 既存設計 | 新規はこちら |
📖 PSC 設定の流れ（Consumer Endpoint）
- Producer 側で Internal LB を作成
- Producer 側で NAT Subnet を作成（Service Attachment 専用）
- Producer 側で Service Attachment を作成し、許可する Consumer Project を指定（または自動承認）
- Consumer 側で Forwarding Rule（PSC Endpoint）を作成、target に Service Attachment URI を指定
- Consumer VM から PSC Endpoint の IP に接続 → Google Backbone 経由で Producer LB に到達
承認モードには ACCEPT_AUTOMATIC（全許可）と ACCEPT_MANUAL（明示許可）があり、SaaS 公開では Manual が安全。
4.5 試験での出題パターン（Chapter 4）
🎯 頻出問題のパターン
- 「外部 IP なし VM から BigQuery にアクセス」→ PSC for Google APIs（または PGA / restricted.googleapis.com）
- 「顧客の AWS VPC からも繋がる SaaS 公開」→ PSC + Hybrid（Interconnect/VPN）。Consumer 側で内部 IP として見える
- 「Cloud SQL に複数 VPC から接続したい」→ PSC for Managed Services（PSA だと Peering ハブが必要）
5Cloud Load Balancing 7 種 完全選定
Google Cloud の LB は 3 軸 ×（実質）7 タイプ。試験では「グローバル展開」「内部マイクロサービス」「TCP/UDP パススルー」など要件キーワードから即座にタイプ名を引き出す必要があります。
5.1 3 つの選定軸
軸 1：Global vs Regional
サービスの到達範囲。Global は 単一 Anycast IP で全リージョン、Regional は そのリージョン内のみ。
軸 2：External vs Internal
External はインターネット公開、Internal は VPC 内（または Interconnect/VPN 経由のオンプレ）からのみアクセス可。
軸 3：Application(L7) vs Network(L4)
Application は HTTP/HTTPS の高度なルーティング、Network は TCP/UDP/ESP/GRE。Network はさらに Proxy / Passthrough に分岐。
5.2 7 種完全比較表
| LB タイプ | スコープ | レイヤ | Proxy / Passthrough | 外部 / 内部 | Tier |
|---|---|---|---|---|---|
| Global External Application LB | Global | L7 (HTTP/S) | Proxy (Envoy/GFE) | External | Premium |
| Regional External Application LB | Regional | L7 | Proxy (Envoy) | External | Premium / Standard |
| Cross-region Internal Application LB | Cross-region | L7 | Proxy (Envoy) | Internal | Premium |
| Regional Internal Application LB | Regional | L7 | Proxy | Internal | Premium |
| External Proxy Network LB (TCP/SSL) | Global / Regional | L4 | Proxy | External | Premium / Standard |
| Internal Proxy Network LB | Regional / Cross-region | L4 | Proxy | Internal | Premium |
| External Passthrough Network LB | Regional | L4 (DSR) | Passthrough (Maglev) | External | Premium / Standard |
| Internal Passthrough Network LB | Regional | L4 (DSR) | Passthrough | Internal | Premium のみ |
「Passthrough Network LB leverages Maglev and Andromeda for direct server return (DSR) ... Global external Application LBs use Envoy-based Google Front-End (GFE).」 — Cloud Load Balancing overview
5.3 選定マトリクス（決定ツリー）
Q1: トラフィックは HTTP/HTTPS か TCP/UDP か？
HTTP/S → Q2 へ (Application LB)
TCP/UDP/ESP → Q4 へ (Network LB)
▼
Q2: グローバル展開か？
YES → Global External Application LB（Premium Tier 必須）
NO → Q3 へ
▼
Q3: 外部公開か内部利用か？
External → Regional External Application LB
Internal → Regional Internal / Cross-region Internal Application LB
▼
Q4: クライアント IP 保持と低レイテンシが必要か？
YES → Passthrough Network LB（DSR で IP 保持）
NO → Proxy Network LB（TLS 終端、グローバル可）
5.4 Global vs Regional の決定要素
| 観点 | Global External Application LB | Regional External Application LB |
|---|---|---|
| IP 種別 | Anycast Global（単一 IP で全世界） | Regional IP |
| Network Tier | Premium のみ | Premium / Standard 両方 |
| クライアント到達 | Google エッジに即着地（80+ PoP） | 該当リージョンに直接 |
| マルチリージョン Backend | ✅ 自動フェイルオーバー | ❌ 単一リージョン |
| Cloud CDN | ✅ 統合 | ⚠️ 一部対応 |
| SSL 証明書数 | 多数（Google 管理証明書も可） | 同等 |
| コスト | 転送+処理（Premium 帯域料金） | 転送+処理（Standard で安価） |
💡 ベストプラクティス
グローバルにユーザーがいるサービスでは、迷ったら Global External Application LB + Cloud CDN + Cloud Armor の三点セット。Premium Tier 料金でも、Google エッジから自社リージョンまでの「最後の N ホップ」を Google ネットワークで運ばせる効果が大きい。
5.5 Backend Type と組み合わせ
| Backend 種別 | 対応 LB | 用途 |
|---|---|---|
| Managed Instance Group (MIG) | 全 Application / Network LB | VM フリート |
| NEG (Zonal) | Application LB | GKE Pod / IP-based |
| NEG (Internet) | Global External Application LB | 外部 origin（CDN） |
| NEG (Serverless) | Application LB | Cloud Run / Cloud Functions / App Engine |
| NEG (Private Service Connect) | Application LB | PSC Backend モード |
| Hybrid NEG | Application LB | オンプレ / 他クラウド |
| Cloud Storage Bucket | Global External Application LB | 静的サイトホスティング |
⚠️ よくある失敗 — Passthrough と Proxy の取り違え
Passthrough NLB は クライアント IP を保持するためアプリケーション層で IP ベース監査が可能ですが、TLS 終端は backend で実施する必要があります。Proxy NLB は LB で TLS 終端できますが、backend から見えるのは LB IP。「クライアント IP を要件にする規制系」では Passthrough を選びましょう。
5.6 試験での出題パターン（Chapter 5）
🎯 頻出問題のパターン
- 「グローバル展開 + マルチリージョン Active-Active」→ Global External Application LB + Spanner
- 「GKE 内部マイクロサービス」→ Internal Application LB（または Service Mesh）
- 「ゲームサーバー UDP」→ External Passthrough Network LB（UDP/ESP/GRE 対応）
- 「Cloud Run をプライベート公開」→ Regional Internal Application LB + Serverless NEG
- 「クライアント IP 保持 + L4」→ Passthrough Network LB（Proxy は LB IP が source）
6ハイブリッド接続 完全比較
オンプレ・他クラウドとの接続は試験の決定的領域。調達期間 / 帯域 / SLA / コストの 4 軸で 5 つの選択肢から選びます。
6.1 5 選択肢の本質比較
| 方式 | 帯域 | SLA | 調達期間 | 初期コスト | 適合シナリオ |
|---|---|---|---|---|---|
| Dedicated Interconnect | 10 Gbps / 100 Gbps | 99.9% / 99.99% | 数週間〜数ヶ月 | 高（コロケーション） | 大規模・自前ファシリティ・Google PoP 近接 |
| Partner Interconnect | 50 Mbps 〜 50 Gbps | 99.9% / 99.99% | 数日〜数週間 | 中（パートナー経由） | 中規模・Google PoP に直結できない |
| HA VPN | 各トンネル 3 Gbps（最大 10 Gbps） | 99.99% | 数十分〜数時間 | 低（インターネット越し） | クイックスタート・バックアップ経路・小〜中規模 |
| Classic VPN | 3 Gbps | 99.9% | 数十分 | 最低 | 非推奨（静的ルーティング、HA なし） |
| Cross-Cloud Interconnect | 10 / 100 / (400) Gbps | 99.9% / 99.99% | 1〜4 週間 | 高 | マルチクラウド（AWS/Azure/OCI/Alibaba） |
「Each Cloud VPN tunnel supports up to 250,000 packets per second. Depending on packet size, this translates to between 1 Gbps and 3 Gbps of bandwidth per tunnel.」 — HA VPN docs
6.2 Dedicated vs Partner の決定ツリー
Q1: 必要帯域は 10 Gbps を超えるか？
YES → Dedicated Interconnect（10G/100G）
NO → Q2 へ
▼
Q2: Google Interconnect PoP に直結できるロケーションか？
YES → Dedicated（コスト効率良い）
NO → Partner（パートナー経由）
▼
Q3: 緊急度が高い（数日以内に開通）か？
YES → Partner（数日）または HA VPN（数時間）でブートストラップ
NO → Dedicated でも可
6.3 99.99% SLA を取るための冗長構成
図 6-1：99.99% SLAを取るには、2 メトロ × 各メトロ 2 EAD = 合計 4 接続。99.9% なら 1 メトロ 2 EAD で OK。Cross-Cloud Interconnect も同じ冗長要件。
6.4 HA VPN の構造
📋 公式制限
Classic VPN は 非推奨です（公式は HA VPN を「recommended method」と明記）。新規構築は迷わず HA VPN を選択し、既存 Classic VPN は移行計画を立てる必要があります。
6.5 Cross-Cloud Interconnect
| 対象クラウド | 帯域 | SLA 構成 |
|---|---|---|
| AWS / OCI | 10 / 100 / 400 Gbps | 99.9%：1 メトロ 2 EAD ／ 99.99%：2 メトロ 各 2 EAD |
| Azure / Alibaba Cloud | 10 / 100 Gbps | 同上 |
「Google supports the connection all the way to the OCI demarcation; support does not extend to the remote cloud provider's infrastructure.」 — CCI docs
💡 ベストプラクティス — 段階的接続
ハイブリッド計画では「即時 HA VPN（数時間で開通）→ 並行して Partner/Dedicated Interconnect を発注（数週間）→ Interconnect 開通後に VPN をフェイルオーバー経路に格下げ」の 2 段階展開がデファクト。VPN を捨てずに常時バックアップとして残す構成（hybrid backup）が試験で頻出。
6.6 試験での出題パターン（Chapter 6）
🎯 頻出問題のパターン
- 「3 ヶ月待てない、明日繋ぎたい」→ HA VPN（数時間で開通）
- 「99.99% SLA 必須」→ Dedicated/Partner で 2 メトロ × 2 EAD = 4 接続、または HA VPN を 2 経路
- 「20 Gbps の帯域が必要」→ Dedicated 100G（または Partner 50G）。HA VPN だけでは厳しい
- 「AWS の DB と GCP の Web を統合」→ Cross-Cloud Interconnect（Megaport などのパートナー経由も可）
7Network Connectivity Center (NCC)
NCC は「ネットワークの統合ハブ」。複数 VPC・Interconnect VLAN・HA VPN・サードパーティ NVA を 1 つの Hub にスポークとして登録し、推移的通信を実現するマネージドサービスです。VPC Peering の 25 個制限や非推移性を超えたい場合の決定打。
7.1 NCC の構造
図 7-1：NCC Hub に異なる種類のスポーク（VPC、VLAN、VPN、NVA）を登録すると、Hub を経由したスポーク間通信が可能に。事実上のマネージド SD-WAN。
7.2 サポートされるスポークタイプ
| スポーク種別 | 用途 | 備考 |
|---|---|---|
| VPC Spoke | Google Cloud 内の VPC を統合 | VPC Peering の代替。非推移性を超える |
| VLAN Attachment | Dedicated/Partner Interconnect | オンプレ → NCC 経由で全 VPC へ |
| HA VPN | VPN 経由のサイト | BGP ルーティング必須 |
| Router Appliance | SD-WAN / 第三者 NVA | Cisco、Palo Alto などの仮想アプライアンス |
7.3 NCC vs Shared VPC vs VPC Peering
| 観点 | NCC | Shared VPC | VPC Peering |
|---|---|---|---|
| 推移性 | ✅ Hub 経由で全 Spoke 推移 | ✅ 同 VPC 内 | ❌ 非推移 |
| 異種接続混在 | ✅ VPC + VLAN + VPN + NVA | ❌ VPC のみ | ❌ VPC のみ |
| Organization 越え | ✅ 可能 | ❌ 不可 | ✅ 可能 |
| サードパーティ NVA | ✅ ファースト級サポート | ❌ | ❌ |
| コスト | 高（Spoke 料金） | VPC コストのみ | 無料（データ転送のみ） |
| 推奨ケース | 大規模統合・SD-WAN | 同組織内集中統制 | 2-3 VPC 限定接続 |
7.4 試験での出題パターン（Chapter 7）
🎯 頻出問題のパターン
- 「50 拠点（オンプレ + GCP 複数 VPC + AWS）を統合管理」→ NCC Hub-and-Spoke
- 「Cisco SD-WAN を Google Cloud に持ち込みたい」→ NCC + Router Appliance Spoke
- 「VPC Peering の 25 個制限に達した」→ NCC に移行（VPC Spoke として再登録）
- 「Site-to-Site Data Transfer」→ NCC で複数オンプレ拠点間データ転送を Google Backbone で実現
8Cloud Armor & Cloud CDN
外部公開アプリの「守り」と「速さ」を司る 2 サービス。両方とも Global External Application LB と密結合します。
8.1 Cloud Armor の機能階層
無料 / Standard
Always-On DDoS Protection
外部 Application/Network LB に対する L3/L4 ボリュメトリック攻撃を自動緩和。追加料金なし、レイテンシ影響なし。
- SYN フラッド、UDP フラッド対策
- Google エッジで即時インラインミティゲーション
- Premium 自動付帯（全 Global External LB）
有料 / Enterprise
WAF + L7 DDoS + Adaptive Protection
HTTP Flood、SQLi、XSS、OWASP Top 10 への対応。ML ベースの異常検知。
- Preconfigured WAF Rules（OWASP CRS 4.22 ベース）
- Adaptive Protection（ML 検知 + WAF ルール提案）
- Threat Intelligence（IP レピュテーション）
- Bot Management、Rate Limiting
「Cloud Armor uses OWASP Core Rule Set 4.22 as its foundation, offering protection aligned with OWASP Top 10 vulnerability categories.」 — Cloud Armor docs
8.2 Cloud Armor のルールタイプ
| ポリシー種別 | 適用先 | 用途 |
|---|---|---|
| Backend Security Policy | Backend Service | WAF、L7 ルール |
| Edge Security Policy | Backend Service / Bucket（CDN 前段） | キャッシュ前のフィルタリング |
| Network Edge Security Policy | Network LB / Protocol Forwarding | L3/L4 高度フィルタ |
| Hierarchical Security Policy | 組織・フォルダ・プロジェクト | 組織横断 WAF 統制（プレビュー） |
📖 Cloud Armor の Adaptive Protection 動作（クリックで展開）
- Backend Service のトラフィックを 24/7 で観測（ML モデル）
- 異常検知（HTTP Flood、Layer 7 ボリュメトリック）でアラート生成
- 攻撃シグネチャから 提案 WAF ルールを自動生成
- 管理者が承認 → ルールを Backend Security Policy に追加
- 正常化後にルールを削除・閾値調整
L3/L4 の Advanced Network DDoS は Network LB に対しても提供されます。
8.3 Cloud CDN の動作モデル
図 8-1：Cloud CDN は Google エッジ（GFE）で動作し、Cache Hit ならオリジンに到達せず終了。Cache Miss のみ LB → Backend へ。Cloud Armor は Edge と Backend の 2 段階で適用可。
8.4 Cloud CDN の Cache Mode
| Cache Mode | 動作 | 典型ユース |
|---|---|---|
USE_ORIGIN_HEADERS | Origin の Cache-Control ヘッダに従う | 細かい TTL 制御を Origin で済ませている場合 |
CACHE_ALL_STATIC | 静的拡張子（jpg, css, js…）を自動キャッシュ | 静的サイト / 通常のメディア配信 |
FORCE_CACHE_ALL | 全レスポンスをキャッシュ（プライベートも） | ⚠️ ログイン後 HTML をキャッシュする事故注意 |
⚠️ よくある失敗 — FORCE_CACHE_ALL の事故
FORCE_CACHE_ALL はログイン後のレスポンス（Cookie 含むセッション）まで誤キャッシュし、他ユーザーに個人情報が表示される事故を起こします。動的コンテンツに使ってはいけません。動的部分は private Cache-Control / signed URL で守るのが正解。
8.5 Cloud CDN の機能ハイライト
- Signed URLs / Signed Cookies：時限的なアクセス制御。動画配信、ダウンロードコンテンツに有効
- Custom Origins (Internet NEG)：GCP 外（他クラウド・オンプレ）も Origin にできる
- Cache Invalidation：URL/パターン単位でキャッシュ破棄。1 リクエストで多数のオブジェクトをパージ可
- Service Extensions：エッジでカスタムロジック実行（WASM ベース）
- Negative Caching：404 など失敗レスポンスもキャッシュしてオリジン負荷削減
- Dynamic Compression：Brotli/Gzip 圧縮をエッジで自動付与
8.6 試験での出題パターン（Chapter 8）
🎯 頻出問題のパターン
- 「OWASP Top 10 対策」→ Cloud Armor Enterprise + Preconfigured WAF Rules
- 「グローバル配信 + DDoS」→ Global External Application LB + Cloud Armor + Cloud CDN 三点セット
- 「動画コンテンツ配信 + 有料会員のみ」→ Cloud CDN + Signed URL
- 「ML で攻撃を自動検知」→ Cloud Armor Adaptive Protection
9Cloud NAT
外部 IP を持たない VM・GKE Pod・Cloud Run（VPC Egress 経由）からインターネットへ egress onlyで出るためのマネージド NAT。アーキテクチャは プロキシレス・Andromeda 分散実装で、追加 VM が不要なのが特徴です。
「Cloud NAT is a distributed, software-defined managed service that configures the Andromeda software powering your VPC network without requiring proxy VMs or appliances.」 — Cloud NAT docs
9.1 Public NAT vs Private NAT
Public NAT
VM → インターネット
外部 IP を持たない VM/GKE/Cloud Run が、共有された外部 IP プール経由でインターネットへ egress。
- 静的 / 自動割当の外部 IP を選択可
- 逆方向（インターネット → VM）は不可
Private NAT
VPC ↔ VPC / オンプレ
VPC 間や VPC ↔ オンプレで CIDR が重複しているときに、NAT で IP を変換して通信。
- VPC Peering、NCC スポーク、HA VPN/Interconnect 経由
- マージ・買収後のネットワーク統合で活用
9.2 ポート割当てとポート枯渇
Cloud NAT の最大の落とし穴は ポート枯渇。1 つの外部 IP は 65,536 ポートしか持たないため、多数の VM × 多数のコネクションを 1 IP で捌こうとすると詰まります。
| 項目 | デフォルト | 調整可能範囲 |
|---|---|---|
| 1 VM 最小ポート | 64 | 2 〜 65,536（2 の累乗） |
| 1 VM 最大ポート（dynamic） | 65,536（dynamic 有効時） | Dynamic Port Allocation で自動拡張 |
| NAT IP プール | 自動 1 〜 任意数 | 必要 IP 数 = (同時コネクション数 × VM 数) / 64,512 |
| TCP TIME_WAIT (idle) | 2 分 | カスタマイズ可 |
| UDP TIME_WAIT (idle) | 30 秒 | カスタマイズ可 |
⚠️ よくある失敗 — ポート枯渇
Cloud SQL や外部 API への接続が多い VM では、デフォルト 64 ポートでは 瞬時に枯渇します。症状：「
connection timed out」「address already in use」が断続的に発生。対策：(1) Dynamic Port Allocation 有効化、(2) 1 VM 最小ポートを 1024 / 2048 に増加、(3) 外部 IP プールを増設、(4) Endpoint Independent Mapping を必要なケースだけに限定。
9.3 Endpoint Independent Mapping (EIM)
EIM を有効にすると、同じ VM・同じ送信元ポートが 常に同じ外部 IP:外部ポートにマップされます。SIP/VoIP や P2P など、対称的な NAT を必要とするプロトコルで重要。ただし EIM 有効時はポート効率が悪化し、枯渇しやすくなるトレードオフがあります。
9.4 ベストプラクティス
✅ DO
推奨設定
- Dynamic Port Allocation を有効化
- NAT Logging を有効化（IP/Port 監査）
- 外部 API はできるだけ PSC for Google APIs で迂回（NAT 不要に）
- サブネット単位で NAT 適用範囲を限定
- Egress Filter を併用
❌ DON'T
避けるべきパターン
- 全 VPC を 1 つの NAT で賄う（IP プール圧迫）
- 1 IP で数百 VM を捌こうとする
- EIM をデフォルトで有効化
- NAT ログを無効のまま放置（監査不能）
9.5 試験での出題パターン（Chapter 9）
🎯 頻出問題のパターン
- 「外部 IP を持たない VM がインターネットへ patch を取りに行く」→ Cloud NAT（Public）
- 「ポート枯渇でエラー多発」→ Dynamic Port Allocation 有効化 + 最小ポート増加
- 「Google API（GCS など）アクセス専用」→ NAT は不要、PGA または PSC for Google APIs
- 「VPC Peering で CIDR が重複している」→ Private NAT で IP 変換
10試験頻出パターン（ケース別）
本番試験は単発のサービス知識ではなく、シナリオ全体を読んで最適構成を選ぶ形式。代表 6 ケースの「定番解」を頭に焼き付けます。
10.1 ケース別ネットワーク構成
| シナリオ | 推奨構成 |
|---|---|
| グローバル EC サイト（Cymbal Retail 型） | Global External Application LB + Cloud CDN + Cloud Armor Enterprise + Spanner Multi-region + VPC SC + Cross-region Internal Application LB（マイクロサービス間） |
| ヘルスケア HIPAA（EHR Healthcare 型） | Dedicated Interconnect（99.99%、4 接続）+ HA VPN バックアップ + Shared VPC + Hierarchical Firewall + VPC SC + Audit Logs + Private NAT |
| コネクテッドカー IoT（KnightMotives 型） | Regional Passthrough NLB（UDP）+ Pub/Sub + Cross-Cloud Interconnect（既存 AWS）+ NCC + Edge TPU + Data Residency 配慮で Multi-region 設計 |
| メディア配信（Altostrat Media 型） | Global External Application LB + Cloud CDN（Signed URL）+ Cloud Armor + Cloud Storage Multi-region + Vertex AI Online Endpoint（PSC で接続） |
| マイクロサービス SaaS | GKE + Internal Application LB + PSC for Published Services + Cloud Service Mesh + Cloud Armor + Private Google Access |
| レガシー移行 (Lift & Shift) | HA VPN（即時）→ Partner Interconnect（数週間）+ Migration Center + Shared VPC + Database Migration Service |
10.2 「キーワード → サービス」翻訳早見表
| 問題文のキーワード | 即答サービス |
|---|---|
| 「Single anycast IP」「グローバル展開」 | Global External Application LB |
| 「クライアント IP を保持」 | External Passthrough NLB |
| 「UDP / ゲーム / VoIP」 | Passthrough NLB |
| 「外部 IP なしで GCS アクセス」 | PSC for Google APIs または PGA |
| 「マネージド DB をプライベートに」 | PSC for Managed Services（PSA は旧式） |
| 「自社サービスを別組織に公開」 | PSC for Published Services |
| 「99.99% オンプレ接続」 | Dedicated/Partner Interconnect 2 メトロ × 2 EAD |
| 「明日繋ぎたい」 | HA VPN |
| 「マルチクラウド」 | Cross-Cloud Interconnect または NCC + Partner |
| 「50 拠点を統合管理」 | Network Connectivity Center |
| 「OWASP / WAF」 | Cloud Armor Enterprise |
| 「ML ベース DDoS 自動緩和」 | Cloud Armor Adaptive Protection |
| 「静的コンテンツ高速化」 | Cloud CDN |
| 「ポート枯渇でエラー」 | Cloud NAT + Dynamic Port Allocation |
| 「VPC Peering 25 個制限」 | NCC に移行 |
| 「同組織内でネットワーク統制を一元化」 | Shared VPC |
| 「データ主権 / リージョン縛り」 | Subnet Region 制御 + VPC SC + リージョン制限 |
11アンチパターン と 注意点
試験では「誤った設計を選ばないこと」も問われます。Google 公式が明示的に non-recommended としているパターンを整理します。
11.1 ネットワーク アンチパターン Top 10
❌ 1
Default Network のまま本番
0.0.0.0/0 から 22/3389 が空いている、CIDR が固定で衝突しやすい。組織ポリシー compute.skipDefaultNetworkCreation でブロック推奨。
✅ 推奨
Custom Mode VPC を最初から
CIDR、サブネット、ファイアウォール全てを宣言的に IaC（Terraform）で管理。
❌ 2
本番と開発を VPC Peering
不要な攻撃面が増加。本番 ↔ 開発の誤接続事故。
✅ 推奨
環境別 VPC + PSC for Managed Services
共有したいのは マネージドサービスのみのはず。VPC 平面接続は最終手段。
❌ 3
20 VPC を全部 Peering
非推移性で n(n-1)/2 = 190 接続必要、クォータ 25 を超える。
✅ 推奨
NCC Hub-and-Spoke
1 Hub に全 VPC を Spoke 登録。推移性 + 統合管理。
❌ 4
Classic VPN を新規構築
静的ルーティング、HA なし、99.9% SLA、IPv6 非対応。
✅ 推奨
HA VPN（99.99%、BGP、IPv6）
Google 公式が「recommended method」と明記。
❌ 5
Cloud NAT を全 VPC 共通 1 つで賄う
外部 IP プール圧迫 → ポート枯渇 → 断続的タイムアウト。
✅ 推奨
サブネット別 NAT + Dynamic Port Allocation
1 リージョン 1 NAT、ログ有効、外部 API は PSC で迂回。
❌ 6
Cloud CDN FORCE_CACHE_ALL を全パスに
ログイン後 HTML までキャッシュ → 個人情報露呈事故。
✅ 推奨
USE_ORIGIN_HEADERS + Cache-Control 設計
動的は private, no-store、静的のみ public TTL。
❌ 7
Dynamic Routing Mode = Regional のまま放置
マルチリージョン化したらオンプレ通信がリージョン跨ぎで途絶。
✅ 推奨
本番 VPC は最初から Global
後から変更も可能だが、初期から Global にして全リージョンで Interconnect 共有。
❌ 8
Network Tag だけでファイアウォール
Peering 越え非伝播、誤付与で予期せぬ穴。
✅ 推奨
Service Account ベース + Hierarchical Policy
SA ベースは IAM と紐付き、Hierarchical で組織ガード。
❌ 9
Premium Tier のまま「テスト用 VM 多数」
Egress 料金が嵩む。Premium は LB 用 / 本番のみ。
✅ 推奨
環境別 Network Tier 制御
開発は Standard Tier、本番 LB のみ Premium。組織ポリシーで強制可。
❌ 10
Cloud Armor を Standard のままで OWASP 対策
Standard はボリュメトリック DDoS のみ。L7 攻撃は素通し。
✅ 推奨
Cloud Armor Enterprise + Preconfigured WAF
OWASP CRS 4.22、Adaptive Protection、Bot Mgmt 統合利用。
11.2 セキュリティ的注意点
⚠️ Firewall は VPC 単位、しかし Peering 越え非伝播
Tag・SA はソースとして Peering 越しに参照できないため、Peer 先からの通信を許可するには IP 範囲ベースで書く必要があります。これを忘れると「Peering したのに通信不可」のトラブルが起きます。
⚠️ VPC SC との混同注意
VPC Service Controls は サービス境界（GCS、BigQuery 等）の制御であり、VPC 自体のネットワーク境界ではありません。VPC SC を有効化しても、VM 間 IP 通信は VPC Firewall で別途制御する必要があります。
⚠️ Shared VPC + Service Account の権限拡散
Service Project のサービスアカウントが Host Project の Subnet を使うには Network User 権限が必要。これを Host Project レベルに付けると、全 Subnet にアクセス可能になります。Subnet 単位で付けるのが最小権限の原則。
12クォータと制限の早見表
試験前最終確認用。太字は出題頻度が特に高い数値です。引上げリクエスト可能なものとそうでないもの（ハード制限）が混在します。
12.1 VPC / Subnet 関連
| 項目 | デフォルト値 | 備考 |
|---|---|---|
| 1 プロジェクトあたり VPC ネットワーク数 | 5 | 引上げ可 |
| 1 VPC あたり Subnet 数 | 275（リージョンあたり） | 増加可 |
| Subnet primary range の予約 IP | 4 / subnet | 変更不可（network/gateway/2nd reserved/broadcast） |
| 1 VPC あたり VM 数 | 15,000 | 引上げ可 |
| Static Routes | 250 / VPC | 増加可 |
| Dynamic Routes | 100 / Cloud Router | 増加可 |
| MTU | 1460 (default), 最大 8896 (Jumbo) | VPC 単位で設定 |
12.2 Peering / Shared VPC / PSC
| 項目 | デフォルト値 | 備考 |
|---|---|---|
| 1 VPC あたり VPC Peering 数 | 25 | 引上げ可（要相談） |
| 1 Service Project あたり Host Project | 1 | ハード制限 |
| 1 Host Project あたり Service Project 数 | 制限あり（増加要相談） | — |
| 1 PSC Service Attachment あたり Consumer | 50（要確認） | 増加可 |
| 1 VPC あたり PSC Endpoint 数 | 制限あり | クォータページ参照 |
12.3 ファイアウォール
| 項目 | デフォルト値 | 備考 |
|---|---|---|
| 1 VPC あたり Firewall Rule 数 | 500（VPC FW Policy なら多い） | 増加可 |
| Priority レンジ | 0 〜 65,535 | 低いほど優先 |
| Priority デフォルト | 1000 | — |
| Implied Deny Ingress | — | 暗黙ルール（変更不可） |
| Implied Allow Egress | — | 暗黙ルール（変更不可） |
| Connection Tracking 最小タイムアウト | 10 分 | idle 10 分でステート破棄 |
| Hierarchical Policy 適用範囲 | Org / Folder | VPC FW より優先 |
12.4 Load Balancing
| 項目 | 値 |
|---|---|
| Global External Application LB | 単一 Anycast IP / Premium のみ / 80+ PoP |
| Backend Service あたり Backend 数 | 多数（数千レベル、Backend 種別による） |
| SSL 証明書 / LB | 多数（Google 管理証明書も使用可） |
| URL Map ルール | VPC 単位上限あり、増加可 |
| Health Check 間隔 | 1 秒〜（デフォルト 5 秒） |
12.5 Interconnect / VPN
| 方式 | 帯域 | SLA | 備考 |
|---|---|---|---|
| Dedicated Interconnect | 10G / 100G | 99.9% (1 メトロ 2 EAD) / 99.99% (2 メトロ × 2 EAD) | 調達 数週〜数月 |
| Partner Interconnect | 50 Mbps 〜 50 Gbps | 同上 | 調達 数日〜数週 |
| HA VPN 1 トンネル | 1〜3 Gbps (250k pps) | 99.99% | BGP 必須 |
| HA VPN ゲートウェイ最大 | 10 Gbps（複数トンネル束ね） | 99.99% | — |
| Classic VPN | 3 Gbps | 99.9% | 非推奨 |
| Cross-Cloud Interconnect | 10 / 100 / (400) Gbps | 99.9% / 99.99% | AWS/Azure/OCI/Alibaba |
12.6 Cloud NAT / Cloud Armor / Cloud CDN
| 項目 | 値 |
|---|---|
| Cloud NAT 1 VM 最小ポート | デフォルト 64、最大 65,536 |
| Cloud NAT 1 外部 IP のポート総数 | 65,536 |
| Cloud NAT TCP Idle Timeout | 120 秒（カスタマイズ可） |
| Cloud Armor WAF Rules ベース | OWASP CRS 4.22 |
| Cloud Armor Rate Limit ルール | 多数設定可 |
| Cloud CDN Cache Invalidation | 1 リクエストでパターン指定可、月次上限あり |
| Cloud CDN Signed URL 期限 | 最大 1 週間（標準） |
12.7 ネットワーク性能（公式指標）
| 指標 | 値 |
|---|---|
| Intra-zone レイテンシ | P50 < 55 μs, P99 < 80 μs |
| Compact Placement レイテンシ | P50 < 45 μs, P99 < 60 μs |
| クロスリージョン パケットロス | < 0.01%（グローバル平均） |
| HA VPN 1 トンネル PPS | 250,000 pps |
「Cross-region packet loss target: less than 0.01% global average.」 — VPC overview
✅ 試験直前 最終チェックリスト
Deep Dive Networking 達成度0 / 0
※ チェック状態はこのブラウザに保存されます。
🧭 次のステップ
SECTION 1
アーキ設計と計画
本ページの内容を「設計判断の翻訳力」と統合学習。出題比 25%。
SECTION 2インフラ管理とプロビジョニング
VPC・LB・GKE・Vertex AI・Gemini Enterprise の実装目線。
QUIZ問題演習
ネットワーク領域を含む 30 問で実戦演習。70% 以上を目指す。
🎯 試験での勝ち筋（ネットワーク領域）
ネットワーク問題は 「キーワード → 即答サービス」のマッピングで 7-8 割は取れます。残りは 「数値（SLA / クォータ / 帯域）」と 「アンチパターン回避」。本ページの早見表（§10.2、§12）を最低 2 周してから受験してください。