クラウドインフラの現場で、私たちは日々数え切れないほどのネットワーク設計に向き合っています。AWSのVPC、AzureのVNet、そしてGCPのVPC。どれもクラウド時代のインフラストラクチャを支える大動脈ですが、GCPのVPCには他のクラウドにはない、少しユニークな特徴があります。
それは、「VPC自体はグローバルなリソースでありながら、サブネットはリージョナルなリソースである」という点です。AWSに慣れ親しんだエンジニアほど、この「グローバルVPC」という概念の罠にハマりがちです。
今回は、そのGCPネットワークの第一歩であり、本番環境の設計において絶対に避けて通れない「自動モードVPC」と「カスタムモードVPC」の挙動の違いについて、パケットの裏側の動きや実務での設計アンチパターンを交えながら、シニアエンジニアの視点で徹底的に解説していきます。
—
1. 自動モード vs カスタムモード：その決定的な違いとは
GCPで新しいVPCネットワークを作成する際、必ずといっていいほど手が止まるのが「自動モード（Auto mode）」と「カスタムモード（Custom mode）」の選択です。
- 自動モードVPC: プロジェクト作成時にデフォルトで用意されている
defaultネットワークもこれに該当します。新しいリージョンがGCPに追加されるたびに、Googleが事前に定義した決まったCIDRブロック（基本的には/20）のサブネットが自動的に作成されます。 - カスタムモードVPC: サブネットの作成も、CIDRブロックの割り当ても、すべてあなた（エンジニア）の裁量で行うモードです。本番環境やステージング環境など、実務で使うシステムは原則としてすべてこのカスタムモードで構築します。
一見すると、自動モードは「面倒なIPアドレス計算をしなくていいから楽そう」に見えます。しかし、実務の現場では、この「自動」という言葉が時に恐ろしい地雷に化けるのです。
自動モードで割り当てられるデフォルトCIDRの正体
自動モードVPCを選択すると、GCPはすべての既存および将来のリージョンに対して、10.128.0.0/9 のプレフィックスから切り出された /20 のCIDRブロックを自動的に割り当てます。例えば、us-central1 には 10.128.0.0/20、asia-east1 には 10.140.0.0/20 といった具合です。
手元ですぐに検証したい場合や、お遊びのプロトタイプ環境を作るには非常に便利ですが、実務でこれを採用してはいけない致命的な理由があります。
—
2. なぜ実務で「自動モード」が敬遠されるのか？（設計上の注意点）
現場で「自動モードVPCを本番にそのまま使おう」と言い出す後輩がいたら、私は全力で止めに入ります。理由は主に3つあります。
① IPアドレスの枯渇と拡張性の欠如
各リージョンに割り当てられる /20 は、1つのサブネットあたり 4,096 個のIPアドレスを提供します。小規模なシステムなら十分に見えるかもしれません。しかし、Kubernetesクラスタ（GKE）をデプロイし、PodのIPマスカレードやエイリアスIPレンジを考慮し始めると、この /20 というサイズはあっという間に枯渇します。自動モードでは、後からこのサブネットのCIDR範囲を拡張（リサイズ）することが制限されるケースが多く、スケールアウトの限界を早める原因になります。
② オンプレミスや他クラウド（AWS/Azure）とのIP重複（CIDRパズル）
これが最も深刻です。自動モードが勝手に割り当てる 10.128.0.0/9 などのレンジは、企業内の既存のオンプレミスネットワークや、将来的にVPN/Interconnectで接続する予定の別ネットワーク（AWSのVPCなど）がすでに使用しているプライベートIPレンジと盛大に被る可能性が非常に高いのです。
ネットワークが重複した瞬間、ルーティングはルーティングループや通信不能という致命的な障害を引き起こします。
③ マルチクラウド・ハイブリッドクラウド時代の可観測性の悪化
「どのリージョンのどのサブネットがどのIPレンジを使っているか」を完全にコントロールできない状態は、トラブルシューティング時の悪夢です。パケットキャプチャやVPCフローログを解析する際、予測可能なIP設計になっていないと、障害箇所の特定に余計な時間を取られることになります。
—
3. 実践：Terraformで構築する「カスタムモードVPC」のベストプラクティス
口うるさい講釈はこの辺にして、実際に実務で即座に使える、洗練されたカスタムモードVPCのコードを見てみましょう。ここではインフラストラクチャのコード化のデファクトスタンダードであるTerraformを用います。
以下の設定ファイルでは、自動モードを完全に無効化（auto_create_subnetworks = false）し、厳密に設計されたCIDRブロックを持つサブネットをマルチリージョン（東京と米国）に展開しています。
# main.tf - 実務向けセキュア・カスタムモードVPCの構築例
# 1. グローバルVPCネットワークの定義（自動モードは必ずfalseにする）
resource "google_compute_network "custom_vpc" {
name = "prod-core-vpc"
auto_create_subnetworks = false # 【重要】自動サブネット作成を完全に無効化
routing_mode = "GLOBAL" # グローバルルーティングを有効化し、リージョン間をシームレスに接続
description = "Production core network designed by SRE team"
delete_default_routes_on_create = false
}
# 2. 東京リージョン（asia-northeast1）用サブネットの定義
resource "google_compute_subnetwork "tokyo_subnet" {
name = "prod-tokyo-app-subnet"
ip_cidr_range = "10.100.10.0/24" # 256個のIP。アプリケーション層に十分なサイズを確保
region = "asia-northeast1"
network = google_compute_network.custom_vpc.id
# フローログを有効化し、BigQueryやCloud Loggingでパケットの振る舞いを監査可能にする
log_config {
aggregation_interval = "INTERVAL_5_SEC"
flow_sampling = 0.5
metadata = "INCLUDE_ALL_METADATA"
}
# プライベートGoogleアクセスを有効化し、外部IPを持たずにGCPのAPIへ安全にアクセス
private_ip_google_access = true
}
# 3. アイオワリージョン（us-central1）用サブネットの定義
resource "google_compute_subnetwork "us_subnet" {
name = "prod-us-app-subnet"
ip_cidr_range = "10.100.20.0/24" # リージョン間で綺麗にCIDRを分割・管理
region = "us-central1"
network = google_compute_network.custom_vpc.id
log_config {
aggregation_interval = "INTERVAL_5_SEC"
flow_sampling = 0.5
metadata = "INCLUDE_ALL_METADATA"
}
private_ip_google_access = true
}このTerraformコードのポイントは、auto_create_subnetworks = false を明示的に指定している点と、ip_cidr_range をシステム要件に合わせて細かくスライスしている点です。さらに private_ip_google_access = true を有効にすることで、インターネットゲートウェイを通さずにGCPのマネージドサービス（Cloud StorageやBigQueryなど）へセキュアにアクセスできる、SREが好む堅牢なネットワークトポロジーを実現しています。
—
4. デバッグとトラブルシューティングの現場から
もし「自動モードからカスタムモードへの移行期」や「複数チームが勝手にリソースを作った環境」で、IPアドレスの競合やルーティング異常が発生した場合、現場のSREはどのように原因を特定するでしょうか。
実務で使えるGCPのCLI（gcloud）コマンドを使った素早い調査手法をいくつか共有します。
現在のVPCとサブネットの割り当て状況を俯瞰する
まずは、どのリージョンにどんなCIDRが割り当てられているかを一覧化します。
# カスタムモードか自動モードかの確認も含めて、VPC内のサブネット情報を一発で取得
gcloud compute networks subnets list \
--network="prod-core-vpc" \
--format="table(name, region, ipCidrRange, network)"パケットがどこでドロップしているかの確認（Connectivity Tests）
GCPには、ネットワークの疎通性を論理的に検証してくれる「Connectivity Tests」という強力な機能があります。特定のPodやVMから外部APIへの疎通がおかしいと感じたら、CLIから即座にテストを流せます。
# 東京リージョンのインスタンスから外部へのルーティングテストを実行
gcloud network-management connectivity-tests create test-outbound-to-api \
--source-instance="projects/my-project/zones/asia-northeast1-a/instances/app-server-01" \
--destination-ip-address="8.8.8.8" \
--destination-port=443 \
--protocol="TCP"ネットワークのトラブルシューティングにおいて最も重要なのは、「思い込みを捨てて、事実（ルーティングテーブルとファイアウォールルール、そしてVPCフローログ）を見る」ことです。自動モードの便利さに頼り切っていると、こうした低レイヤーの挙動が見えなくなり、いざという時の復旧が遅れる原因になります。
—
5. まとめ
今回はGCPの自動モードVPCとカスタムモードVPCの挙動の違いについて、実務的な設計思想を交えて解説しました。
- 自動モードVPCは、手軽な検証やチュートリアルには最適ですが、CIDRの固定化やIP枯渇、オンプレミスとの競合リスクがあるため、本番環境での使用は御法度です。
- カスタムモードVPCを基本とし、組織のIPアドレス管理計画（IPAM）に沿った美しく拡張性のあるCIDR設計を行うことが、信頼性の高いクラウドインフラストラクチャ構築の第一歩となります。
クラウドのネットワークは、一度構築してしまうと後からの変更（特にCIDRの変更やVPCの作り直し）に莫大なコストとダウンタイムを伴います。だからこそ、最初の設計段階でしっかりと手を動かし、コントロールを握っておくことが、シニアエンジニアとしての腕の見せ所です。
あなたのインフラが、今日も安定してパケットを送り届けられますように。それでは、また次の現場でお会いしましょう。
コメント