Google Cloud 完全攻略 Ep.7: VPCネットワーク設計入門｜SESエンジニア向け実践ガイド

⚡ 3秒でわかる！この記事のポイント

VPCはGoogle Cloudのネットワーク基盤であり、すべてのコンピューティングリソースが接続される仮想ネットワーク
サブネット設計・ファイアウォールルール・Cloud NATなど、本番環境で必須のネットワーク知識を体系的に解説
共有VPCやVPN/Interconnectによるハイブリッド接続まで、SES案件で即活用できるレベルでカバー

📚 この記事は「Google Cloud 完全攻略」シリーズの一部です

SES案件でクラウドインフラの設計・構築に関わると、必ず最初に求められるのがネットワーク設計です。「サブネットをどう切るか」「ファイアウォールはどう設定するか」「オンプレミスとどう接続するか」——こうした問いに明確に答えられるかどうかが、インフラエンジニアとしての評価を大きく左右します。

Google CloudのVPC（Virtual Private Cloud）は、AWSのVPCやAzureのVNetに相当する仮想ネットワークサービスです。しかしGoogle Cloud独自のグローバルVPCモデルや階層型ファイアウォールポリシーなど、他クラウドとは異なる設計思想があります。

本記事では、VPCの基本概念からサブネット設計、ファイアウォール、Cloud NAT、ハイブリッド接続、共有VPCまで、SES現場で即使える実践的な知識を体系的に解説します。

VPCの基本概念——グローバルネットワークを理解する

VPCとは何か

VPCは、Google Cloud上に作成する論理的に分離されたプライベートネットワークです。Compute EngineのVM、Cloud SQLインスタンス、GKEクラスタなど、ほぼすべてのコンピューティングリソースがVPCに接続されます。

Google CloudのVPCには、他クラウドにはない特徴があります。

特徴	Google Cloud	AWS
VPCのスコープ	グローバル（全リージョンに自動展開）	リージョン単位
サブネット	リージョン単位	アベイラビリティゾーン単位
ファイアウォール	VPC単位（グローバル適用）	セキュリティグループ（インスタンス単位）

グローバルVPCとは、1つのVPCが世界中のすべてのリージョンにまたがるということです。東京リージョンのVMとアメリカリージョンのVMが、同じVPC内でプライベートIP通信できます。

デフォルトVPC vs カスタムVPC

# デフォルトVPCの確認
gcloud compute networks list

# ❌ デフォルトVPCは本番環境に不適切
# - 全リージョンに自動でサブネットが作成される
# - ファイアウォールルールが緩い（SSH/RDP/ICMPが全開放）

# ✅ カスタムVPCの作成（本番推奨）
gcloud compute networks create prod-vpc \
    --subnet-mode=custom \
    --bgp-routing-mode=regional \
    --description="本番環境用VPC"

新規プロジェクトにはデフォルトVPCが自動作成されますが、本番環境では必ずカスタムVPCを使用してください。Ep.1でプロジェクトを作成した直後の最初のタスクが、デフォルトVPCの削除とカスタムVPCの構築です。

# デフォルトVPCの削除（本番プロジェクト推奨）
gcloud compute networks delete default --quiet

サブネット設計——CIDRの設計パターン

サブネットの基本

Google Cloudのサブネットはリージョン単位で作成します。同一リージョン内の全ゾーンにまたがるため、AWSのようにゾーンごとにサブネットを作る必要がありません。

# 東京リージョンにサブネットを作成
gcloud compute networks subnets create prod-tokyo-subnet \
    --network=prod-vpc \
    --region=asia-northeast1 \
    --range=10.1.0.0/20 \
    --enable-private-ip-google-access \
    --description="東京リージョン本番サブネット"

# 大阪リージョンにサブネットを作成（DR用）
gcloud compute networks subnets create prod-osaka-subnet \
    --network=prod-vpc \
    --region=asia-northeast2 \
    --range=10.2.0.0/20 \
    --enable-private-ip-google-access \
    --description="大阪リージョンDRサブネット"

CIDR設計のベストプラクティス

SES案件でよく使うCIDR設計パターンを紹介します。

本番VPC: 10.0.0.0/8 から割り当て

環境別の割り当て:
├── 本番（prod）:     10.1.0.0/16
│   ├── 東京:         10.1.0.0/20  (4,094 IPs)
│   ├── 大阪:         10.1.16.0/20 (4,094 IPs)
│   └── GKE Pod用:    10.1.32.0/19 (8,190 IPs)
├── ステージング（stg）: 10.2.0.0/16
│   └── 東京:         10.2.0.0/20
└── 開発（dev）:      10.3.0.0/16
    └── 東京:         10.3.0.0/20

設計のポイント:

将来の拡張を見越して余裕を持つ: /20（4,094 IP）以上を推奨。後から拡張は可能だが縮小はできない
オンプレミスと重複させない: VPN/Interconnectで接続する場合、既存ネットワークのCIDRと被らないように設計
GKEのPod/Service用CIDRを別途確保: GKEを使う場合、Pod用に大きなCIDRが必要（/19以上推奨）

Private Google Access——内部IPでGCPサービスにアクセス

# Private Google Accessの有効化
gcloud compute networks subnets update prod-tokyo-subnet \
    --region=asia-northeast1 \
    --enable-private-ip-google-access

Private Google Accessを有効にすると、外部IPを持たないVMやコンテナから内部IP経由でCloud StorageやBigQueryなどのGCPサービスにアクセスできます。Cloud Storage（Ep.5）やBigQuery（Ep.3）へのデータ転送を安全に行うための必須設定です。

VPCネットワーク設計の全体像

ファイアウォールルール——トラフィック制御の設計

VPCファイアウォールの仕組み

Google CloudのVPCファイアウォールは、ステートフルでVPC単位に適用されます。個々のインスタンスではなく、ネットワークタグやサービスアカウントでターゲットを指定するのが特徴です。

# Webサーバーへの HTTP/HTTPS アクセスを許可
gcloud compute firewall-rules create allow-http-https \
    --network=prod-vpc \
    --allow=tcp:80,tcp:443 \
    --source-ranges=0.0.0.0/0 \
    --target-tags=web-server \
    --description="外部からWebサーバーへのHTTP/HTTPSを許可"

# 内部通信のみ許可（アプリ→DB）
gcloud compute firewall-rules create allow-app-to-db \
    --network=prod-vpc \
    --allow=tcp:5432 \
    --source-tags=app-server \
    --target-tags=db-server \
    --description="アプリサーバーからDBへのPostgreSQL接続を許可"

# SSH接続をIAPトンネル経由に限定
gcloud compute firewall-rules create allow-iap-ssh \
    --network=prod-vpc \
    --allow=tcp:22 \
    --source-ranges=35.235.240.0/20 \
    --target-tags=allow-ssh \
    --description="IAP経由のSSH接続のみ許可"

ネットワークタグ vs サービスアカウント

ファイアウォールのターゲット指定には2つの方式があります。

方式	メリット	デメリット
ネットワークタグ	設定が簡単、直感的	タグの付け替えが誰でも可能
サービスアカウント	IAMで管理され、より安全	設定がやや複雑

# ✅ サービスアカウントベースのファイアウォール（推奨）
gcloud compute firewall-rules create allow-internal-sa \
    --network=prod-vpc \
    --allow=tcp:8080 \
    --source-service-accounts=frontend@my-project.iam.gserviceaccount.com \
    --target-service-accounts=backend@my-project.iam.gserviceaccount.com

Ep.6のIAM設計で学んだサービスアカウント設計と組み合わせることで、ネットワークレベルでもアクセス制御を強化できます。

階層型ファイアウォールポリシー

組織・フォルダレベルで一括適用できるファイアウォールポリシーです。

# 組織レベルのファイアウォールポリシー作成
gcloud compute firewall-policies create \
    --organization=ORGANIZATION_ID \
    --short-name=org-security-policy \
    --description="組織全体のセキュリティポリシー"

# 既知の悪意あるIPレンジをブロック
gcloud compute firewall-policies rules create 1000 \
    --firewall-policy=org-security-policy \
    --organization=ORGANIZATION_ID \
    --action=deny \
    --direction=INGRESS \
    --src-ip-ranges=192.0.2.0/24 \
    --description="ブロックリスト"

組織ポリシーと同様に、上位で設定したルールが全プロジェクトに適用されるため、セキュリティのベースラインを組織全体で統一できます。

Cloud NAT——外部アクセスの管理

なぜCloud NATが必要か

セキュリティのベストプラクティスとして、VMに外部IPを付与しないことが推奨されます。しかし、パッケージの更新や外部APIの呼び出しなど、外向きのインターネットアクセスは必要です。Cloud NATがこの課題を解決します。

# Cloud Routerの作成（Cloud NATの前提）
gcloud compute routers create prod-router \
    --network=prod-vpc \
    --region=asia-northeast1

# Cloud NATの構成
gcloud compute routers nats create prod-nat \
    --router=prod-router \
    --region=asia-northeast1 \
    --auto-allocate-nat-external-ips \
    --nat-all-subnet-ip-ranges \
    --enable-logging

Cloud NATを設定すると、外部IPを持たないVMからインターネットへのアウトバウンド接続が可能になります。インバウンド接続は引き続きブロックされるため、セキュリティを維持しつつ外部通信を実現できます。

Cloud NATのログ分析

# NATログの確認
gcloud logging read 'resource.type="nat_gateway" AND logName="projects/my-project/logs/compute.googleapis.com%2Fnat_flows"' \
    --freshness=1h \
    --format=json

NATログをBigQuery（Ep.3）にエクスポートして分析すれば、不審な外部通信パターンの検出にも活用できます。

ハイブリッド接続——オンプレミスとの統合

SES案件では、オンプレミス環境とGoogle Cloudを接続するハイブリッドクラウド構成が頻繁に求められます。

接続方式の比較

方式	帯域幅	レイテンシ	コスト	ユースケース
Cloud VPN	最大3 Gbps/トンネル	中	低	開発/検証、小規模拠点
Dedicated Interconnect	10/100 Gbps	低	高	大規模本番、大容量データ転送
Partner Interconnect	50 Mbps〜50 Gbps	低〜中	中	中規模本番

Cloud VPNの構築

# VPNゲートウェイの作成（HA VPN推奨）
gcloud compute vpn-gateways create prod-vpn-gw \
    --network=prod-vpc \
    --region=asia-northeast1

# 外部VPNゲートウェイ（オンプレ側）の登録
gcloud compute external-vpn-gateways create onprem-vpn-gw \
    --interfaces=0=203.0.113.1

# VPNトンネルの作成
gcloud compute vpn-tunnels create prod-tunnel-0 \
    --vpn-gateway=prod-vpn-gw \
    --peer-external-gateway=onprem-vpn-gw \
    --peer-external-gateway-interface=0 \
    --ike-version=2 \
    --shared-secret=YOUR_SHARED_SECRET \
    --router=prod-router \
    --vpn-gateway-interface=0 \
    --region=asia-northeast1

# BGPセッションの構成
gcloud compute routers add-bgp-peer prod-router \
    --peer-name=onprem-bgp \
    --peer-asn=65001 \
    --interface=prod-tunnel-0-interface \
    --peer-ip-address=169.254.1.1 \
    --region=asia-northeast1

HA VPN（高可用性VPN）は、99.99%のSLAを提供する推奨構成です。2つのトンネルを使用してアクティブ-アクティブで冗長化します。

共有VPC——マルチプロジェクトのネットワーク管理

共有VPCとは

**共有VPC（Shared VPC）**は、ネットワークを一つのホストプロジェクトで集中管理し、複数のサービスプロジェクトで共有する仕組みです。

ホストプロジェクト（ネットワーク管理）
├── prod-vpc
│   ├── prod-tokyo-subnet → サービスPJ-A（Webアプリ）
│   ├── prod-osaka-subnet → サービスPJ-B（バッチ処理）
│   └── prod-gke-subnet   → サービスPJ-C（GKEクラスタ）

# ホストプロジェクトの有効化
gcloud compute shared-vpc enable host-project-id

# サービスプロジェクトの関連付け
gcloud compute shared-vpc associated-projects add service-project-a \
    --host-project=host-project-id

# サービスプロジェクトのサービスアカウントにサブネット利用権限を付与
gcloud projects add-iam-policy-binding host-project-id \
    --member="serviceAccount:[email protected]" \
    --role="roles/compute.networkUser"

共有VPCのメリット

ネットワーク管理の一元化: IPアドレスの重複やファイアウォールルールの散逸を防止
セキュリティの強化: ネットワーク管理者とアプリケーション開発者の権限を分離
コスト最適化: VPN/Interconnectの接続を共有し、コストを削減

SES案件で数十のプロジェクトを横断するインフラ設計に携わる場合、共有VPCの理解は必須スキルです。Ep.6のIAM設計で解説した組織ポリシーと組み合わせることで、大規模環境のガバナンスを実現できます。

VPCフローログ——ネットワーク可視化と監視

フローログの有効化

# サブネットのフローログを有効化
gcloud compute networks subnets update prod-tokyo-subnet \
    --region=asia-northeast1 \
    --enable-flow-logs \
    --logging-aggregation-interval=INTERVAL_5_SEC \
    --logging-flow-sampling=0.5 \
    --logging-metadata=INCLUDE_ALL

VPCフローログは、ネットワークインターフェースとの間で送受信されるIPトラフィックのサンプルを記録します。

フローログの分析ユースケース

# 直近1時間のフローログを確認
gcloud logging read 'resource.type="gce_subnetwork" AND logName="projects/my-project/logs/compute.googleapis.com%2Fvpc_flows"' \
    --freshness=1h \
    --limit=50

# 異常なポートへのアクセスを検出（BigQueryで分析）
# フローログをBigQueryにエクスポートして以下のクエリを実行

SELECT
  jsonPayload.connection.dest_ip,
  jsonPayload.connection.dest_port,
  COUNT(*) AS request_count
FROM `my-project.vpc_flows.compute_googleapis_com_vpc_flows_*`
WHERE jsonPayload.connection.dest_port NOT IN (80, 443, 8080)
GROUP BY 1, 2
ORDER BY request_count DESC
LIMIT 20;

フローログをBigQueryにエクスポートすれば、Ep.3で学んだSQLを使って高度なネットワーク分析が可能です。

SES案件で使えるVPC設計テンプレート

小〜中規模案件（プロジェクト1〜3個）

prod-vpc (カスタムVPC)
├── web-subnet:     10.1.0.0/24  (Webサーバー)
├── app-subnet:     10.1.1.0/24  (アプリケーション)
├── db-subnet:      10.1.2.0/24  (Cloud SQL)
└── Cloud NAT有効

ファイアウォール:
├── allow-http-https (0.0.0.0/0 → web-server tag, tcp:80,443)
├── allow-app-internal (app-server → db-server, tcp:5432)
├── allow-iap-ssh (35.235.240.0/20 → allow-ssh tag, tcp:22)
└── deny-all-ingress (暗黙のdeny)

大規模案件（共有VPC + マルチプロジェクト）

host-project (共有VPC)
├── prod-vpc
│   ├── prod-web-subnet:  10.1.0.0/20
│   ├── prod-app-subnet:  10.1.16.0/20
│   ├── prod-db-subnet:   10.1.32.0/20
│   └── prod-gke-subnet:  10.1.48.0/20 (Pod: 10.4.0.0/14)
├── Cloud NAT
├── HA VPN → オンプレミス (10.200.0.0/16)
└── 階層型ファイアウォールポリシー

service-project-web  → prod-web-subnet を利用
service-project-api  → prod-app-subnet を利用
service-project-data → prod-db-subnet を利用

ネットワークのトラブルシューティング

よくある問題と対処法

問題	原因	対処
VM間で通信できない	ファイアウォールルールが未設定	`gcloud compute firewall-rules list`で確認
外部APIに接続できない	外部IPなし＋Cloud NAT未設定	Cloud NATを構成
Cloud SQLに接続できない	Private Google Access未有効	サブネット設定を更新
VPN接続が不安定	BGPセッションの問題	`gcloud compute routers get-status`で確認

接続テストツール

# Connectivity Testsで経路を診断
gcloud network-management connectivity-tests create my-test \
    --source-instance=projects/my-project/zones/asia-northeast1-a/instances/vm-1 \
    --destination-instance=projects/my-project/zones/asia-northeast1-a/instances/vm-2 \
    --protocol=TCP \
    --destination-port=8080

# テスト結果の確認
gcloud network-management connectivity-tests describe my-test

Connectivity Testsは、2つのエンドポイント間の到達性をパケットを実際に送らずに検証できるツールです。ファイアウォールルールやルーティングの設定ミスを迅速に発見できます。

まとめ——ネットワーク設計はクラウドアーキテクチャの土台

VPCネットワーク設計は、すべてのクラウドサービスが動作する基盤です。本記事で解説した内容を振り返ります。

カスタムVPCを作成し、デフォルトVPCは本番で使わない
サブネット設計では将来の拡張を見越したCIDR割り当てと、Private Google Accessの有効化が必須
ファイアウォールルールはネットワークタグよりサービスアカウントベースが安全
Cloud NATで外部IPを付与せずにインターネットアクセスを実現
HA VPN/Interconnectでオンプレミスとのハイブリッド接続を構築
共有VPCで大規模環境のネットワークを集中管理
VPCフローログでネットワークの可視化と異常検知を実現

まずはEp.1でプロジェクトを作成し、デフォルトVPCを削除してカスタムVPCを構築するところから始めましょう。Cloud Run（Ep.2）のサーバーレスVPCアクセスコネクタや、Ep.6のIAM設計で学んだVPC Service Controlsも、VPCの理解があってこそ正しく設計できます。

ネットワーク設計の経験は、SESエンジニアとしての市場価値を確実に高めます。特にVPC設計・ファイアウォール・ハイブリッド接続の知識は、エンタープライズ案件で必ず求められるスキルです。

次回のGoogle Cloud 完全攻略もお楽しみに！

出典・参考資料

関連記事