- オンプレミス接続の 3 方式（Cloud VPN / Cloud Interconnect / Cross-Cloud Interconnect）を帯域・SLA・暗号化の軸で選べる
- HA VPN が 99.99% SLA を満たすトポロジと、Cloud Router による BGP 動的ルーティングの仕組みを説明できる
- 共有 VPC のホスト / サービスプロジェクト構造と IAM による職務分離を設計できる
- VPC ピアリングの非推移性・IP 重複禁止という制約を理解し、Private Service Connect・Network Connectivity Center と使い分けられる
- 2 つの VPC をピアリングと HA VPN のそれぞれで実際に接続し、経路がどう交換されるかを確かめる
試験ガイド対応: セクション 2.1（ネットワーク トポロジの構成）、1.3（ネットワーク、ストレージ、コンピューティング リソースの設計）、1.4（移行計画の作成）
第 3 章では 1 つの VPC の内側を設計しました。この章では VPC の「外」との接続を設計します。外には 2 種類あります。ひとつはオンプレミスや他クラウドといった Google Cloud の外側、もうひとつは同じ組織内の別プロジェクト・別 VPC です。前者はハイブリッド接続（VPN / Interconnect）、後者は VPC 設計パターン（共有 VPC / ピアリング / PSC / NCC）の話で、PCA 試験ではどちらも「要件からどの方式を選ぶか」という形で問われます。
オンプレミス接続の選択肢 — Cloud VPN と Cloud Interconnect
Cloud VPN — インターネット経由の IPsec。新規は HA VPN 一択
Cloud VPN は、インターネット経由の IPsec トンネルでオンプレミスネットワークと VPC を接続するリージョンリソースです。現行世代の HA VPN と旧世代の Classic VPN があり、新規構築は HA VPN を選びます。違いは明確です。
- HA VPN — ゲートウェイが 2 つのインターフェイス（それぞれ外部 IP を自動割り当て）を持ち、経路交換は BGP による動的ルーティングが必須（Cloud Router を使う）。両インターフェイスにトンネルを張る構成でほとんどのトポロジが 99.99% SLA の対象になります
- Classic VPN — 単一インターフェイス・静的ルーティングのみで SLA は 99.9%。高可用性が必要な用途には HA VPN が推奨で、移行ガイドも提供されています
1 本のトンネルが処理できるのは送受信合計で最大 250,000 パケット/秒、平均パケットサイズに応じておよそ 1〜3 Gbps の帯域に相当します（2026-08 時点）。それ以上の帯域はトンネルを追加して分散するか、後述の Cloud Interconnect を検討します。IKE は v1 / v2 に対応し（認証は事前共有鍵のみ）、IPv6 を使う場合は IKEv2 が必須です。
Cloud Interconnect — 専用線で 10 Gbps 級をつなぐ
インターネットを経由しない専用の物理接続が Cloud Interconnect です。2 つの形態があります。
- Dedicated Interconnect — コロケーション施設に自社のルーターを設置し、Google のネットワークへ物理的に直結します。回線は 1 本あたり 10 / 100 / 400 Gbps で、それぞれ最大 8 本まで束ねられます（2026-08 時点）
- Partner Interconnect — サービスプロバイダ経由で接続します。コロケーション施設に機器を置けなくても使え、容量は VLAN アタッチメント単位で 50 Mbps〜50 Gbps から選べます（2026-08 時点）
VPC 側との論理的な接点が VLAN アタッチメント（物理接続上のレイヤー 3 インターフェイス）で、経路交換はここでも Cloud Router の BGP が担います。SLA は冗長構成の取り方で決まり、クリティカルな本番向けトポロジで 99.99%、非クリティカルな本番向けトポロジで 99.9% です。注意すべきはCloud Interconnect は既定ではトラフィックを暗号化しないことです。暗号化が要件なら、対応ロケーションでの MACsec か、Interconnect 上に VPN を重ねる HA VPN over Cloud Interconnect を使います。
Cross-Cloud Interconnect と「VPC につながない」接続
マルチクラウド構成で AWS・Azure・OCI・Alibaba Cloud のネットワークと直結したい場合は Cross-Cloud Interconnect を使います。他クラウドとの間にプライマリ + 冗長の 2 本の専用物理接続を用意する方式で、インターネットを経由しません。
一方、Direct Peering / Carrier Peering は Google のエッジネットワークと直接（またはプロバイダ経由で）ピアリングする方式ですが、VPC 内のリソースには届かず SLA もありません。Google Workspace や Google API へのアクセス経路を最適化する用途に限られ、VPC への接続には Interconnect か VPN を選ぶのが公式の推奨です。試験の選択肢に紛れ込む定番のひっかけなので、位置づけだけ覚えておきましょう。
| 観点 | HA VPN | Dedicated Interconnect | Partner Interconnect | Cross-Cloud Interconnect |
|---|---|---|---|---|
| 経路 | インターネット（IPsec） | コロケーション施設で物理直結 | プロバイダ網経由 | 他クラウドと物理直結 |
| 帯域 | トンネルあたり 1〜3 Gbps 相当（追加で拡張） | 10 / 100 / 400 Gbps（束ね可） | 50 Mbps〜50 Gbps | 専用線 2 本（プライマリ + 冗長） |
| SLA | 99.99%（対応トポロジ） | 構成により 99.9% / 99.99% | 構成により 99.9% / 99.99%（Google–プロバイダ間） | 構成により 99.9% / 99.99% |
| 暗号化 | IPsec で常時暗号化 | 既定はなし（MACsec / HA VPN over Interconnect） | 既定はなし（同左） | 既定はなし（同左） |
| 前提・準備 | 即日。ピア側は BGP 対応装置 | コロケーション + 自社ルーター | 対応プロバイダとの契約 | 対応クラウド（AWS / Azure / OCI / Alibaba） |
| 向く場面 | スモールスタート、バックアップ回線、暗号化必須 | 大帯域・安定レイテンシの本番 | コロケーション不可の中帯域 | マルチクラウド間の基幹接続 |
Cloud Router — ハイブリッド接続の頭脳
ここまで何度も登場した Cloud Router は、BGP で経路を交換するマネージドの分散サービスです。自分でルーター VM を運用する必要はありません。HA VPN・Dedicated / Partner / Cross-Cloud Interconnect のすべてで必須の構成要素で（Classic VPN のみ任意）、リージョンごとに VPC ネットワークへ作成します。
- 広告（advertised routes） — VPC のサブネット範囲をピアへ通知します。カスタム広告で通知する範囲を絞ったり追加したりできます
- 学習（learned routes） — ピアから受け取った経路を VPC の動的ルートとして取り込みます。BFD による高速障害検知や BGP セッションの MD5 認証にも対応します
- ASN — Cloud Router とピアにはそれぞれ AS 番号を割り当てます（ハンズオンではプライベート ASN の 65001 / 65002 を使います）
設計上の急所が、VPC ネットワークごとに設定する動的ルーティングモードです。既定の REGIONAL では、Cloud Router が学習した経路はその Cloud Router と同じリージョンのサブネットにしか伝わりません。マルチリージョン VPC でオンプレミスから全リージョンに到達させたい場合は GLOBAL に切り替えます。
gcloud compute networks update NETWORK_NAME --bgp-routing-mode=GLOBAL逆方向（全リージョンのサブネットをオンプレへ広告する）も同様にこのモードが制御します。「東京の VPN 経由で大阪リージョンのサブネットに届かない」というトラブルの典型的な原因なので、つまずきポイントで再度取り上げます。
組織内の VPC 設計 — 共有 VPC・ピアリング・PSC・NCC
次はプロジェクトが増えたときのネットワーク設計です。第 2 章で見たとおり、Google Cloud では環境やチームごとにプロジェクトを分けるのが定石ですが、そのままではプロジェクトごとに VPC が分断されます。つなぎ方は 4 つあり、それぞれ「何を共有し、何を分離するか」が違います。
共有 VPC — ネットワークを 1 か所で管理し、利用だけを配る
共有 VPC は、ホストプロジェクトが持つ VPC ネットワークを、同じ組織内のサービスプロジェクトに使わせる仕組みです。ネットワーク・サブネット・ファイアウォール・ルートの管理はホスト側に集中させたまま、各チームは自分のサービスプロジェクトで VM や GKE クラスタを共有サブネット上に作成できます。組織リソースが前提（同一組織内のみ）で、1 つのサービスプロジェクトがアタッチできるホストプロジェクトは 1 つだけです。
権限設計は IAM ロールの分担で実現します。組織（またはフォルダ）レベルで付与された Shared VPC 管理者（compute.xpnAdmin）がホストの有効化とサービスプロジェクトのアタッチを行い、各チームには compute.networkUser を付与します。このロールをサブネット単位で付与すれば、「開発チームは subnet-dev だけ使える」という最小権限の割り当てになります。組織ポリシーの restrictSharedVpcSubnetworks 制約でも同様の制限を強制できます。
VPC ネットワークピアリング — 対等な 2 つの VPC を内部 IP でつなぐ
VPC ネットワークピアリングは 2 つの VPC を内部 IP で直結します。プロジェクトが違っても、組織が違っても使えます。パフォーマンスは同一 VPC 内の通信と同じレイテンシ・スループットで、追加のゲートウェイもありません。ただし制約が 3 つあり、これが設計と試験の急所です。
- 非推移性 — A–B、B–C をピアリングしても A–C は通信できません。ピアリングは張った 2 者間だけで完結します
- IP 範囲の重複禁止 — 双方のサブネット範囲が重複しているとピアリングを確立できません（作成時に自動チェックされます）
- ファイアウォールは共有されない — 交換されるのは経路（サブネットルートは常時、カスタムルートは import / export フラグで選択）だけで、ファイアウォールルールは各 VPC が独立して管理します
また、ピアリングは両方のネットワークから 1 つずつ設定を作って初めて ACTIVE になります。片側だけでは INACTIVE のまま — これはハンズオン 12-1 で実際に確かめます。
Private Service Connect — ネットワークではなく「サービス」を公開する
ピアリングも共有 VPC も「ネットワーク同士」をつなぐ発想ですが、実際に必要なのは「あの VPC で動いている API を呼びたい」だけ、という場面が多くあります。Private Service Connect（PSC）は、プロデューサー（サービス提供側）が公開した service attachment に対して、コンシューマー（利用側）が自分の VPC 内の内部 IP（エンドポイント）を割り当ててアクセスする仕組みです。
- コンシューマーに見えるのはサービスの入口 1 点だけで、プロデューサー側のネットワーク全体は見えません（ネットワーク単位ではなくサービス単位の公開）
- 接続は NAT で仲介されるため、双方の IP 範囲が重複していても構いません。ピアリングとの最大の違いです
- エンドポイント（転送ルール + 内部 IP で直結）と、第 5 章のロードバランサを前段に挟むバックエンドの 2 形態があります。Google API 自体への非公開アクセスにも使えます
なお Cloud SQL（第 9 章）などの一部マネージドサービスが使う従来方式の Private Service Access は、ピアリングベースで IP 範囲の割り当て調整が必要な旧来パターンです。第 3 章の Private Google Access（Google API への共有経路）も含め、「どれも非公開アクセスだが層が違う」と整理してください。
Network Connectivity Center — ハブ & スポークでメッシュを作る
VPC の数が増えるとピアリングの本数は組み合わせ爆発します（非推移なので全対全に張る必要がある）。Network Connectivity Center（NCC）は、グローバルリソースのハブに VPC やハイブリッド接続をスポークとして登録し、スポーク間の到達性をハブ経由でまとめて提供します。
- VPC スポーク — 登録した VPC 同士がサブネットルートを交換し、ハブ経由で相互に到達できます（ピアリングと違い推移的）。プロジェクトや組織を跨いでも登録できます
- ハイブリッドスポーク — HA VPN トンネル、Interconnect の VLAN アタッチメント、ルーターアプライアンス VM を登録し、オンプレミスや他クラウドをハブに参加させます
- サイト間データ転送 — 拠点間のトラフィックを Google のネットワークを WAN として中継する使い方もできます
| 方式 | つなぐ単位 | 推移性 | IP 重複 | 主な用途 |
|---|---|---|---|---|
| 共有 VPC | プロジェクト（同一組織のみ） | —（1 つの VPC を共用） | —（同一ネットワーク） | 組織内の集中ネットワーク管理 |
| VPC ピアリング | VPC × VPC（組織跨ぎ可） | なし（非推移） | 不可 | 少数 VPC の対等な直結 |
| Private Service Connect | サービス単位 | —（サービスの入口のみ公開） | 可（NAT 仲介） | マネージドサービス・組織間のサービス公開 |
| Network Connectivity Center | ハブ × スポーク（VPC / ハイブリッド） | あり（ハブ経由） | —（全スポークでサブネットルートを交換） | 多数 VPC のメッシュ + オンプレ合流 |
ハンズオン
Interconnect 系は物理回線の契約が必要なので、手を動かすのは無料でできるピアリングと、数十円で本物の BGP 経路交換を体験できる HA VPN です。2 つの VPC の片方を「疑似オンプレミス」に見立てます。HA VPN で 2 つの VPC ネットワークを接続する構成は公式にサポートされたトポロジで、両ゲートウェイが同一リージョンなら 99.99%、別リージョンなら 99.9% の SLA になります。ハンズオン 12-1 で作る VPC とサブネットを 12-2 でも使うので、続けて実施してください。
2 つの custom モード VPC を作ってピアリングで直結します。所要 10 分。費用: 0 円（VPC・サブネット・ピアリングの構成自体は無料で、課金対象のリソースは作りません）。
- IP 範囲が重複しない 2 つの VPC とサブネットを作ります（重複するとピアリングできません）。
gcloud compute networks create vpc-alpha --subnet-mode=custom
gcloud compute networks create vpc-beta --subnet-mode=custom
gcloud compute networks subnets create alpha-tokyo \
--network=vpc-alpha --region=asia-northeast1 --range=10.10.0.0/24
gcloud compute networks subnets create beta-tokyo \
--network=vpc-beta --region=asia-northeast1 --range=10.20.0.0/24- まず alpha 側からだけピアリングを作り、状態を見ます。
gcloud compute networks peerings create alpha-to-beta \
--network=vpc-alpha --peer-network=vpc-beta
gcloud compute networks peerings list --network=vpc-alphaこの時点では STATE が INACTIVE です。ピアリングは両方のネットワークが合意して初めて成立します。
- beta 側からも作成し、ACTIVE になることを確認します（反映まで 1 分ほどかかることがあります）。
gcloud compute networks peerings create beta-to-alpha \
--network=vpc-beta --peer-network=vpc-alpha
gcloud compute networks peerings list --network=vpc-alphaSTATE が ACTIVE になれば、双方のサブネットルート（10.10.0.0/24 ⇔ 10.20.0.0/24）が交換されています。もし 3 つ目の VPC を vpc-beta とだけピアリングしても、vpc-alpha からは到達できません — それが非推移性です。
後片付け: ピアリングだけ削除します。VPC とサブネットは 12-2 で使うため残します（12-2 に進まない場合は 12-2 末尾の後片付けの最後 2 コマンドも実行してください）。
gcloud compute networks peerings delete alpha-to-beta --network=vpc-alpha
gcloud compute networks peerings delete beta-to-alpha --network=vpc-betavpc-beta を疑似オンプレミスに見立て、HA VPN ゲートウェイ 2 台・トンネル 4 本・BGP セッション 4 本で接続し、VM 間の ping で経路交換を確かめます。所要 40 分。費用: VPN トンネル 4 本 × $0.0654/時（asia-northeast1、2026-08 時点）= 約 $0.26/時（40 円前後）+ e2-micro 2 台で数円。1 時間以内に後片付けまで終えれば合計 50 円以内です。
- 各 VPC に HA VPN ゲートウェイと Cloud Router を作ります。ゲートウェイには外部 IP が 2 つ（インターフェイス 0 / 1）自動で割り当てられます。
gcloud compute vpn-gateways create alpha-gw \
--network=vpc-alpha --region=asia-northeast1
gcloud compute vpn-gateways create beta-gw \
--network=vpc-beta --region=asia-northeast1
gcloud compute routers create alpha-router \
--network=vpc-alpha --region=asia-northeast1 --asn=65001
gcloud compute routers create beta-router \
--network=vpc-beta --region=asia-northeast1 --asn=65002
gcloud compute vpn-gateways describe alpha-gw --region=asia-northeast1- トンネルを 4 本作ります（各ゲートウェイのインターフェイス 0 / 1 から 1 本ずつ。0 は相手の 0 へ、1 は相手の 1 へ）。相手も Google Cloud のゲートウェイなので
--peer-gcp-gatewayを使い、事前共有鍵は乱数で生成します。
SHARED_SECRET=$(openssl rand -base64 24)
for IF in 0 1; do
gcloud compute vpn-tunnels create alpha-tunnel$IF \
--vpn-gateway=alpha-gw --peer-gcp-gateway=beta-gw \
--region=asia-northeast1 --interface=$IF \
--ike-version=2 --shared-secret=$SHARED_SECRET \
--router=alpha-router
gcloud compute vpn-tunnels create beta-tunnel$IF \
--vpn-gateway=beta-gw --peer-gcp-gateway=alpha-gw \
--region=asia-northeast1 --interface=$IF \
--ike-version=2 --shared-secret=$SHARED_SECRET \
--router=beta-router
done- alpha-router にトンネルごとの BGP インターフェイスとピアを追加します。BGP 用のリンクローカルアドレス（169.254.0.0/16 内の /30）はトンネルごとにペアで割り当てます。
gcloud compute routers add-interface alpha-router \
--interface-name=if-tunnel0 --vpn-tunnel=alpha-tunnel0 \
--ip-address=169.254.0.1 --mask-length=30 \
--region=asia-northeast1
gcloud compute routers add-bgp-peer alpha-router \
--peer-name=peer-tunnel0 --interface=if-tunnel0 \
--peer-ip-address=169.254.0.2 --peer-asn=65002 \
--region=asia-northeast1
gcloud compute routers add-interface alpha-router \
--interface-name=if-tunnel1 --vpn-tunnel=alpha-tunnel1 \
--ip-address=169.254.1.1 --mask-length=30 \
--region=asia-northeast1
gcloud compute routers add-bgp-peer alpha-router \
--peer-name=peer-tunnel1 --interface=if-tunnel1 \
--peer-ip-address=169.254.1.2 --peer-asn=65002 \
--region=asia-northeast1- beta-router 側は IP を対にして同じ構成にします（.1 と .2、ASN を入れ替え）。
gcloud compute routers add-interface beta-router \
--interface-name=if-tunnel0 --vpn-tunnel=beta-tunnel0 \
--ip-address=169.254.0.2 --mask-length=30 \
--region=asia-northeast1
gcloud compute routers add-bgp-peer beta-router \
--peer-name=peer-tunnel0 --interface=if-tunnel0 \
--peer-ip-address=169.254.0.1 --peer-asn=65001 \
--region=asia-northeast1
gcloud compute routers add-interface beta-router \
--interface-name=if-tunnel1 --vpn-tunnel=beta-tunnel1 \
--ip-address=169.254.1.2 --mask-length=30 \
--region=asia-northeast1
gcloud compute routers add-bgp-peer beta-router \
--peer-name=peer-tunnel1 --interface=if-tunnel1 \
--peer-ip-address=169.254.1.1 --peer-asn=65001 \
--region=asia-northeast1- トンネルと BGP セッションの状態を確認します。
gcloud compute vpn-tunnels describe alpha-tunnel0 \
--region=asia-northeast1 --format='get(status,detailedStatus)'
gcloud compute routers get-status alpha-router \
--region=asia-northeast1期待される出力: トンネルの detailedStatus が Tunnel is up and running になり、get-status の出力で BGP セッションの確立と、学習ルートとしての 10.20.0.0/24 を確認できます（確立まで 1〜2 分待つことがあります）。
- 外部 IP なしの VM を両側に作り、VPN 越しの疎通を確かめます。ファイアウォールは内部からの ICMP と、IAP 経由 SSH（第 3 章参照）だけを許可します。
gcloud compute firewall-rules create alpha-allow-vpn-test \
--network=vpc-alpha --allow=icmp,tcp:22 \
--source-ranges=10.0.0.0/8,35.235.240.0/20
gcloud compute firewall-rules create beta-allow-vpn-test \
--network=vpc-beta --allow=icmp,tcp:22 \
--source-ranges=10.0.0.0/8,35.235.240.0/20
gcloud compute instances create alpha-vm \
--zone=asia-northeast1-b --machine-type=e2-micro \
--subnet=alpha-tokyo --no-address
gcloud compute instances create beta-vm \
--zone=asia-northeast1-b --machine-type=e2-micro \
--subnet=beta-tokyo --no-address- beta-vm の内部 IP を調べ、alpha-vm から ping します。
gcloud compute instances describe beta-vm --zone=asia-northeast1-b \
--format='get(networkInterfaces[0].networkIP)'
gcloud compute ssh alpha-vm --zone=asia-northeast1-b --tunnel-through-iap
# alpha-vm の中で（IP は上で調べた値に置き換え）
ping -c 3 10.20.0.2応答が返れば、パケットは「vpc-alpha → IPsec トンネル → vpc-beta」を通っています。ピアリング（12-1）と違い経路は BGP が運んだ動的ルートです。exit で VM を抜けてください。
後片付け: 依存関係の順（VM → トンネル → ルーター → ゲートウェイ → ファイアウォール → サブネット → VPC）にすべて削除し、最後に何も残っていないことを確認します。
gcloud compute instances delete alpha-vm beta-vm \
--zone=asia-northeast1-b --quiet
gcloud compute vpn-tunnels delete alpha-tunnel0 alpha-tunnel1 \
beta-tunnel0 beta-tunnel1 --region=asia-northeast1 --quiet
gcloud compute routers delete alpha-router beta-router \
--region=asia-northeast1 --quiet
gcloud compute vpn-gateways delete alpha-gw beta-gw \
--region=asia-northeast1 --quiet
gcloud compute firewall-rules delete alpha-allow-vpn-test \
beta-allow-vpn-test --quiet
gcloud compute networks subnets delete alpha-tokyo beta-tokyo \
--region=asia-northeast1 --quiet
gcloud compute networks delete vpc-alpha vpc-beta --quiet
gcloud compute vpn-tunnels list --regions=asia-northeast1つまずきポイント
REGIONAL のままです。--bgp-routing-mode=GLOBAL に更新すると、学習ルートが全リージョンへ伝わり、全サブネットが広告されるようになります。理解度チェック
Q1. HA VPN で 99.99% SLA の対象になるための最低限のトポロジ条件は？
HA VPN ゲートウェイの 2 つのインターフェイス（0 と 1）の両方からトンネルを張り、対応するインターフェイス同士（0↔0、1↔1）を接続することです。片方のインターフェイスにしかトンネルがない構成は SLA の対象外です。経路交換は BGP（Cloud Router）が必須で、静的ルートでは構成できません。
Q2. VPC A–B、B–C をそれぞれピアリングした。A の VM から C の VM へ内部 IP で通信できるか？
できません。VPC ネットワークピアリングは非推移で、経路が交換されるのは直接ピアリングした 2 ネットワーク間だけです。A–C 間にも直接ピアリングを張るか、3 つの VPC を Network Connectivity Center の VPC スポークとして登録してハブ経由の到達性を作ります。
Q3. 共有 VPC で「開発チームには開発用サブネットだけを使わせたい」。付与するロールと付与先は？
compute.networkUser ロールを、ホストプロジェクト全体ではなく対象サブネット単位で開発チームに付与します。プロジェクトレベルで付与すると共有されている全サブネットが使えてしまいます。組織ポリシー制約 restrictSharedVpcSubnetworks で使えるサブネットを強制することもできます。
Q4.（試験形式）金融企業がオンプレのデータセンターと Google Cloud を接続したい。要件は帯域 20 Gbps・最高水準の可用性 SLA・レイテンシの安定。コロケーション施設には自社ルーターを設置できる。選ぶべき接続は？
A. HA VPN のトンネルを 8 本束ねる B. Dedicated Interconnect を冗長構成で 2 回線以上 C. Partner Interconnect 50 Gbps D. Carrier Peering
B。10 Gbps 級以上の帯域 + コロケーション設置可なら Dedicated Interconnect が本命で、99.99% SLA には冗長トポロジが必要です。A はインターネット経由なのでレイテンシの安定を満たせません。C は自社設置ができない場合の代替であり、この要件では遠回りです。D は VPC に接続できず SLA もありません。
Q5.（試験形式）SaaS 事業者が、自社 VPC で動くサービスを多数の顧客の VPC へ非公開で提供したい。顧客側の IP 範囲は制御できず、自社ネットワークの内部構成も見せたくない。適切な方式は？
A. 各顧客と VPC ピアリング B. 顧客を自社ホストの共有 VPC に参加させる C. Private Service Connect で service attachment を公開 D. 各顧客と HA VPN
C。PSC は NAT 仲介なので顧客側と IP 範囲が重複しても動き、公開されるのはサービスの入口だけでネットワーク構成は見えません。A は IP 重複で確立できない顧客が出るうえ、ネットワーク全体が相互に見えます。B は共有 VPC が同一組織内限定なので不可能です。D は IP 重複の問題が残り、顧客ごとのトンネル運用も現実的ではありません。
まとめと次章へ
- オンプレミス接続は HA VPN（IPsec・即日・トンネルあたり 1〜3 Gbps 相当）と Cloud Interconnect（Dedicated 10 / 100 / 400 Gbps・Partner 50 Mbps〜50 Gbps）から、帯域・SLA・暗号化・設備の条件で選ぶ。他クラウドとは Cross-Cloud Interconnect
- 経路交換は Cloud Router の BGP が担う。マルチリージョン VPC では動的ルーティングモードを
GLOBALにするかを必ず設計判断に含める - 組織内は「集中管理 → 共有 VPC」「対等な直結 → ピアリング（非推移・IP 重複不可）」「サービスだけ公開 → PSC（IP 重複可）」「多数 VPC のメッシュ + ハイブリッド合流 → NCC」で使い分ける
- ピアリングは両側の設定が揃って初めて ACTIVE。HA VPN は 2 インターフェイス両方へのトンネルで初めて 99.99% SLA
ネットワークの経路がつながったら、次はその上を流れるデータと境界の防御です。第 13 章では、暗号鍵（Cloud KMS / CMEK）、VPC Service Controls によるデータ境界、IAP によるゼロトラストアクセスなど、セキュリティをアーキテクチャに織り込む道具を扱います。本章の共有 VPC・PSC は、そこで登場する境界設計の土台になります。
参考リンク（公式ドキュメント）: