WEB問題集
大手金融グループの基盤刷新で、本番／開発／監査の三系統を単一の Google Cloud 組織配下に集約する計画が進行中です。本番ワークロードは複数チームが同居しますが、ネットワーク管理はネットワーク中央部門が一元管理し、利用部門にはサブネット単位での起動権限のみ与える要件があります。各サービスプロジェクトでは独自の課金分離と IAM 境界を維持しつつ、共通の VPC ルーティングテーブルとファイアウォール基盤を共有する必要があります。最小の運用コストで要件を満たすには、どのネットワーク設計を採用すべきですか。
正解：B
【正解: B】の理由
ネットワーク資産は中央部門が一元管理し、利用部門にはサブネット単位の起動権限だけを渡すという要件は、Shared VPC のホストプロジェクトとサービスプロジェクトの分離モデルにそのまま対応します。ホストプロジェクトが VPC ネットワーク・サブネット・ルート・ファイアウォールを保持し、Shared VPC 管理者がサービスプロジェクトをアタッチします。権限委譲は compute.networkUser ロールで行い、これをホストプロジェクト全体ではなく選んだサブネットに限定して付与すれば、利用部門は指定サブネットにのみインスタンスを起動できます。課金は VPC を保持するホストではなくリソースが存在するサービスプロジェクトへ計上されるため、事業ごとの課金分離と IAM 境界も維持されます。単一の VPC を共有するのでルーティングテーブルとファイアウォール基盤は自動的に共通化され、運用コストは最小で済みます。
【サービス比較】
| 方式 | ネットワーク集中管理 | 課金分離 | サブネット粒度の委譲 |
|---|---|---|---|
| Shared VPC | ホストに集約 | 維持できる | できる |
| VPC Peering | 各 VPC に分散 | 維持できる | できない |
| Network Connectivity Center | ハブで到達性のみ | 維持できる | できない |
| 単一プロジェクト集約 | 集約できる | できない | できない |
【他の選択肢が不適切な理由】
- A: すべてのプロジェクトへ所有者権限を配る運用は最小権限に反し、ピアリングは推移ルーティングを提供しないため対地の数だけ接続管理が増えます。
- C: ハブとスポークで到達性を束ねる設計はサブネット単位の起動権限委譲を提供せず、ネットワーク資産の管理は各プロジェクトに分散したままです。
- D: 単一プロジェクトに集約するとリソースの課金先が一本化され、要件である事業ごとの課金分離と IAM 境界を維持できません。
【参考】
製造業のグローバル展開で、北米／欧州／アジアの三リージョンに同一サービスを配置する計画があります。事業要件として、リージョンを跨いだ内部通信は Google のバックボーン経由で完結させ、各拠点のサブネットアドレスを将来の M&A に備えて 10 年単位で重複なく拡張できるようにしたいと考えています。さらに、Google が自動付与する既定サブネットは監査ポリシー違反になります。最初に採用すべき VPC 設計はどれですか。
正解：B
【正解: B】の理由
VPC ネットワークはグローバルなリソースで、リージョンに属するのはサブネットだけです。したがって単一の Custom Mode VPC を作り、北米・欧州・アジアの各リージョンにサブネットを定義すれば、リージョンを跨いだ内部通信は追加の接続を作らずに Google のバックボーン上で完結します。Custom Mode ではサブネットが自動作成されないため、アドレス範囲を自社の計画どおりに明示でき、将来の M&A で持ち込まれる既存レンジとの重複も設計段階で避けられます。一方 Auto Mode は各リージョンに 10.128.0.0/9 の中の既定範囲を自動作成し、Google が新リージョンを追加すると勝手にサブネットが増えるため、既定サブネットを許さない監査ポリシーには適合しません。拡張はサブネット追加やレンジ拡張で吸収します。
【サービス比較】
| 設計案 | 既定サブネットの排除 | アドレス計画の自由度 | リージョン間の内部通信 |
|---|---|---|---|
| 単一の Custom Mode VPC に各リージョンのサブネットを定義 | できる | 計画どおりに設計できる | 同一 VPC 内でバックボーン経由（本問の解） |
| Auto Mode をリージョンごとに作り後から再構成 | できない | 既定範囲に縛られる | ネットワークが分かれ追加接続が必要 |
| Auto Mode を VPC Peering で相互接続 | できない | 自動範囲のまま | 対地の数だけピアリングが増える |
| Default VPC を残し追加 VPC を Cloud VPN で接続 | できない | 既定のまま残る | インターネット経由の IPsec |
| 項目 | Auto Mode VPC | Custom Mode VPC |
|---|---|---|
| サブネット自動作成 | あり（10.128.0.0/9 内） | なし |
| 新リージョン追加時 | 自動で増える | 計画して追加する |
| アドレス計画の自由度 | 低い | 高い |
| IPv6 範囲を持つサブネット | 作成できない | 作成できる |
【他の選択肢が不適切な理由】
- A: 自動作成される範囲は既定の CIDR 内に固定され、後追いで組み替えても既定サブネットを生成する仕組み自体が残るため監査要件を満たせません。
- C: リージョンごとにネットワークを分けるとピアリングの管理が対地の数だけ増え、単一のグローバル VPC で足りる要件に対して構成が過剰になります。
- D: 既定のネットワークを残す時点で監査要件に反し、トンネルはインターネット経由のためバックボーンで完結させたい要件とも整合しません。
【参考】
SaaS スタートアップが、開発者数が 6 か月で 3 倍に増加する見込みで、東京リージョンの一つのサブネットに Compute Engine と GKE Pod／Service の三層構成を配置しようとしています。Pod CIDR と Service CIDR は将来の拡張に備えて余裕を持ち、ノード側のホスト用範囲とは衝突しないように設計したい状況です。どの設計が最も適切ですか。
正解：A
【正解: A】の理由
GKE の VPC ネイティブ クラスタは alias IP を使い、サブネットのプライマリ範囲をノードに、セカンダリ範囲を Pod と Service にそれぞれ割り当てます。Pod のアドレスはエイリアスとして VPC のサブネットから払い出されるため、クラスタ内だけでなく同じ VPC やそこへ接続されたネットワークからも直接ルーティングでき、経路をノードごとに増やす必要がありません。開発者が半年で三倍に増える想定でも、想定最大ノード数とノードあたりの Pod 数から逆算して Pod 用セカンダリ範囲を大きめに確保しておけば、ノード用のプライマリ範囲と衝突させずに拡張できます。VPC ネイティブは現在すべての新規クラスタで既定のネットワークモードであり、同一サブネットに同居する Compute Engine とまとめてアドレス設計を管理できます。
【サービス比較】
| 設計 | アドレスの割り当て | 拡張性と衝突回避 |
|---|---|---|
| VPC ネイティブ (alias IP) | プライマリ範囲をノードと VM、セカンダリ 2 本を Pod と Service へ | 最大ノード数×ノードあたり Pod 数で逆算して確保でき、プライマリと衝突しない |
| 経路ベース + Cloud NAT で共有 | Pod は VPC の範囲を持たず、NAT は外向き専用 | Pod への直接到達性も範囲の分離も得られない |
| 層ごとに VPC を分けてピアリング | 3 つの VPC を個別に設計 | 単一サブネットで足りる要件に対し経路とピアリングの管理が増える |
| Auto Mode VPC の自動範囲を流用 | 既定で割り当てられた範囲をそのまま使う | セカンダリ範囲を計画的に確保できず拡張余地が残らない |
【他の選択肢が不適切な理由】
- B: 送信元アドレスを変換する仕組みは外向き通信のためのもので、Pod への直接到達性もアドレス範囲の分離も提供しません。
- C: 層ごとにネットワークを分けるとピアリングの管理と経路設計が増え、単一サブネットで完結する要件に対して不要な負債になります。
- D: 自動作成される範囲は計画的なセカンダリ範囲の確保に向かず、将来の Pod 数の増加に合わせた拡張余地を残せません。
【参考】
金融子会社のセキュリティ部門から、本番 VPC と DMZ VPC を完全に分離した上で、双方向に推移ルートを発生させず、共通の Network Virtual Appliance 経由で全トラフィックを検査したいという要望が出されました。VPC は同一組織配下に複数存在し、将来的にも増減します。設計として最も適切なのはどれですか。
正解：B
【正解: B】の理由
Network Connectivity Center はハブに複数の VPC をスポークとして登録し、スポーク間の到達性をハブ側のルートテーブルで決める仕組みです。プリセットのスター トポロジではスポークをセンター グループとエッジ グループに分け、エッジ グループのルートテーブルにはエッジ同士を結ぶ経路が作られません。本番と DMZ のネットワークをエッジに置き、Network Virtual Appliance を持つ検査用ネットワークをセンターに置けば、両者が直接到達することはなく、通信は必ず検査側を経由します。ピアリングのように対地ごとの関係を張り直す必要がなく、対象が増減しても同じハブへスポークを登録または削除するだけで済むため、将来の増設にも耐えます。
【サービス比較】
| 方式 | ネットワーク間の到達制御 | 検査の集約 | 対象が増減したときの作業 |
|---|---|---|---|
| NCC スター トポロジ | エッジ同士は不通・センター経由 | 容易 | スポークの登録と削除のみ |
| VPC Peering | 1 対 1・推移ルーティングなし | 困難 | 対地の数だけ増える |
| Shared VPC へ統合 | 同一ネットワーク内 | 分離できない | 統合の再設計が必要 |
| Cloud VPN と静的経路 | トンネル単位 | 硬直的 | トンネルと経路を都度追加 |
【他の選択肢が不適切な理由】
- A: ピアリングは推移ルーティングを提供しないため、総当たりで張っても他ネットワーク宛の経路が伝播せず、検査点を強制することもできません。
- C: 単一のネットワークへ統合する案は、本番と DMZ を完全に分離するという前提そのものを崩してしまいます。
- D: トンネルと静的経路の組み合わせは対象が増減するたびに設定作業が増え、集中検査の統制も経路の数だけ脆くなります。
【参考】
大学病院の研究系システムを Google Cloud に移行する計画で、患者情報を扱う閉域系と、論文公開用のインターネット系を同一組織内で運用します。閉域系のサブネットからは外部 IP を持たない VM が Google API へ到達できる必要があり、また将来的に IPv6 にも対応する余地を残したいと考えています。どの設計が最適ですか。
正解：A
【正解: A】の理由
プライベート Google アクセスはサブネット単位で有効化する設定で、内部 IP アドレスしか持たない VM が Google API とサービスの外部 IP 宛へ到達できるようにします。通信は Google のネットワーク内を通るため、患者情報を扱う閉域系のサブネットでも外部 IP を一切付与せずに Cloud Storage などのサービスを利用でき、閉域の前提を崩しません。将来の IPv6 については、IPv6 アドレス範囲を持つサブネットは Custom Mode の VPC でのみサポートされ、Auto Mode やレガシー ネットワークでは作成できないという制約があります。最初から Custom Mode で構築しておけば、後日デュアルスタックや内部 IPv6 へ広げるときにネットワークを作り直さずに済み、閉域系と公開系はサブネットと IAM で分けたまま運用できます。
【サービス比較】
| 手段 | 外部 IP の要否 | 経路 | 閉域と IPv6 の要件との整合 |
|---|---|---|---|
| プライベート Google アクセス | 不要 | Google のネットワーク内 | 閉域のまま Google API へ到達。IPv6 範囲は Custom Mode VPC でのみ作成可 |
| Cloud NAT | 不要 (送信元を変換) | 既定インターネット ゲートウェイ向けの経路が前提 | 外向きの経路を要するため閉域要件と噛み合わない |
| 外部 IP の直付け | 必要 | インターネット | 一時的な付与でも閉域要件を満たさない |
| Direct Peering | 不要 | VPC の外・Google の公開サービス向け | VPC に経路を作らず VM からの到達手段にならない |
【他の選択肢が不適切な理由】
- B: 一時的にでも外部 IP を付与する運用は閉域の要件を満たさず、付け外しの手作業そのものが監査上の穴になります。
- C: 送信元アドレスを変換して外向きに出す方式はインターネット ゲートウェイ向けの経路を前提とし、閉域で完結させたい要件と噛み合いません。
- D: ピアリングは自社網と Google の公開サービスを結ぶ手段で、VPC にカスタム経路を作らないため VM からの Google API 到達手段にはなりません。