GCP VPCネットワーク設計入門｜サブネット・ファイアウォール・Cloud NATの実践

クラウド環境でシステムを運用する際、ネットワーク設計は最も重要な基盤のひとつです。適切に設計されたネットワークは、セキュリティを確保しながらシステムの拡張性と可用性を高めます。

Google Cloud Platform（GCP）では、VPC（Virtual Private Cloud）がネットワークの中核を担います。この記事では、GCP VPCの基本概念からサブネット設計、ファイアウォールルールの設定、Cloud NATの導入まで、実務で使えるネットワーク構築の手順を詳しく解説します。

GCP VPCとは？クラウドネットワークの基本を理解する

VPC（Virtual Private Cloud）は、GCP上に構築する仮想的なプライベートネットワークです。オンプレミス環境でいう社内ネットワークに相当し、Compute EngineのVM、Cloud SQLのデータベース、Cloud Runのコンテナなど、あらゆるGCPリソースが配置される場所です。

VPCの基本構造

GCPのVPCは、他のクラウドプロバイダーとは異なる特徴を持っています。

グローバルリソース
GCPのVPCはグローバルリソースとして作成されます。つまり、1つのVPCが世界中のすべてのリージョンにまたがります。AWSではリージョンごとにVPCを作成する必要がありますが、GCPでは1つのVPCでマルチリージョン構成が可能です。

サブネットはリージョン単位
VPCの中にサブネットを作成しますが、サブネットはリージョン単位で配置されます。同じリージョン内のゾーン間では自動的に通信が可能です。

デフォルトVPCの存在
GCPプロジェクトを作成すると、デフォルトVPCが自動生成されます。開発やテスト用途ではそのまま利用できますが、本番環境ではカスタムVPCの作成を強く推奨します。

デフォルトVPCとカスタムVPCの違い

デフォルトVPCにはいくつかの問題点があります。

すべてのリージョンにサブネットが作成される：不要なサブネットが存在し、管理が複雑になる
緩いファイアウォールルール：ICMPやSSH（22番ポート）、RDP（3389番ポート）がデフォルトで許可されている
IPアドレス範囲が固定：CIDR範囲をカスタマイズできない

本番環境では、必要なリージョンだけにサブネットを作成し、最小権限のファイアウォールルールを設定したカスタムVPCを使用しましょう。

カスタムVPCの作成手順

ここからは、実際にカスタムVPCを作成する手順を解説します。gcloudコマンドを使用して進めます。

VPCネットワークの作成

まず、カスタムモードでVPCを作成します。

# カスタムモードでVPCを作成
gcloud compute networks create my-production-vpc \
  --subnet-mode=custom \
  --bgp-routing-mode=regional \
  --description="本番環境用VPC"

--subnet-mode=customを指定することで、サブネットが自動作成されず、必要なリージョンだけに手動でサブネットを追加できます。

コンソールからの作成

Cloud Consoleから作成する場合は、以下の手順です。

「VPCネットワーク」→「VPCネットワークの作成」をクリック
名前を入力（例：my-production-vpc）
「サブネット作成モード」で「カスタム」を選択
必要なサブネットを追加
「作成」をクリック

なお、VPCやサブネットの構成をTerraformでコード管理すると、環境の再現性が高まり、変更履歴の追跡も容易になります。

サブネット設計のベストプラクティス

サブネット設計は、ネットワーク全体のスケーラビリティとセキュリティに直結します。適切なIPアドレス範囲の選定と、環境ごとの分離が重要です。

IPアドレス範囲（CIDR）の設計

サブネットに割り当てるCIDR範囲は、RFC 1918のプライベートアドレスから選択します。

# 東京リージョンにWebサーバー用サブネットを作成
gcloud compute networks subnets create web-subnet-tokyo \
  --network=my-production-vpc \
  --region=asia-northeast1 \
  --range=10.1.0.0/24 \
  --description="Webサーバー用サブネット"

# 東京リージョンにアプリケーションサーバー用サブネットを作成
gcloud compute networks subnets create app-subnet-tokyo \
  --network=my-production-vpc \
  --region=asia-northeast1 \
  --range=10.2.0.0/24 \
  --description="アプリケーションサーバー用サブネット"

# 東京リージョンにデータベース用サブネットを作成
gcloud compute networks subnets create db-subnet-tokyo \
  --network=my-production-vpc \
  --region=asia-northeast1 \
  --range=10.3.0.0/24 \
  --description="データベース用サブネット"

推奨するサブネット分割パターン

一般的なWebシステムの場合、以下のように役割ごとにサブネットを分離します。

3層アーキテクチャの例

Webサブネット（10.1.0.0/24）：ロードバランサーやWebサーバーを配置。外部アクセスを受け付ける
Appサブネット（10.2.0.0/24）：アプリケーションサーバーを配置。Webサブネットからのみアクセス可能
DBサブネット（10.3.0.0/24）：Cloud SQLなどのデータベースを配置。Appサブネットからのみアクセス可能

CIDR設計時の注意点

CIDR範囲を決定する際は、以下の点に注意してください。

将来の拡張を見据える：/24（254アドレス）で足りるなら/24を使用し、拡張が必要になったらセカンダリレンジを追加する
他VPCやオンプレミスとの重複を避ける：VPCピアリングやVPN接続時にCIDRが重複するとルーティングが破綻する
GKE用のセカンダリレンジ：GKEを利用する場合、Pod用とService用のセカンダリレンジを追加で設定する

# GKE用のセカンダリレンジを含むサブネット作成
gcloud compute networks subnets create gke-subnet-tokyo \
  --network=my-production-vpc \
  --region=asia-northeast1 \
  --range=10.4.0.0/24 \
  --secondary-range pod-range=10.100.0.0/16,service-range=10.200.0.0/20

ファイアウォールルールの設定と管理

ファイアウォールルールは、VPC内のトラフィックを制御する最も重要なセキュリティ機能です。GCPのファイアウォールはステートフルで、許可した通信の戻りトラフィックは自動的に許可されます。

ファイアウォールルールの基本概念

GCPのファイアウォールルールには以下の要素があります。

方向：ingress（受信）またはegress（送信）
優先度：0〜65535の数値で、値が小さいほど優先度が高い
アクション：allow（許可）またはdeny（拒否）
ターゲット：ルールが適用されるインスタンス（ネットワークタグまたはサービスアカウントで指定）
フィルタ：送信元・宛先のIP範囲、プロトコル、ポート

最小権限の原則に基づくルール設計

セキュリティの基本はデフォルトで全て拒否し、必要な通信のみ許可することです。IAMによるアクセス制御と併せて、多層的なセキュリティを構築しましょう。

# まず全ての受信を拒否するルールを作成（低優先度）
gcloud compute firewall-rules create deny-all-ingress \
  --network=my-production-vpc \
  --direction=INGRESS \
  --priority=65534 \
  --action=DENY \
  --rules=all \
  --source-ranges=0.0.0.0/0 \
  --description="デフォルトで全受信を拒否"

# ロードバランサーからのHTTP/HTTPS通信を許可
gcloud compute firewall-rules create allow-lb-to-web \
  --network=my-production-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=130.211.0.0/22,35.191.0.0/16 \
  --target-tags=web-server \
  --description="ロードバランサーからWebサーバーへのアクセスを許可"

# WebサーバーからAppサーバーへの通信を許可
gcloud compute firewall-rules create allow-web-to-app \
  --network=my-production-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:8080 \
  --source-tags=web-server \
  --target-tags=app-server \
  --description="WebサーバーからAppサーバーへのアクセスを許可"

# AppサーバーからDBへの通信を許可
gcloud compute firewall-rules create allow-app-to-db \
  --network=my-production-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-tags=app-server \
  --target-tags=db-server \
  --description="AppサーバーからDBへのアクセスを許可"

ネットワークタグの活用

上記のルールではネットワークタグを使って対象インスタンスを指定しています。タグを活用することで、IPアドレスに依存しない柔軟なルール管理が可能です。

# VMインスタンス作成時にタグを指定
gcloud compute instances create web-server-01 \
  --zone=asia-northeast1-b \
  --subnet=web-subnet-tokyo \
  --tags=web-server \
  --machine-type=e2-medium

タグを統一的に命名し、ドキュメントで管理することで、ルールの可読性が大幅に向上します。

Cloud NATの設定｜プライベートインスタンスの外部通信

本番環境では、セキュリティを高めるためにインスタンスから外部IPアドレスを外し、プライベートIPのみで運用するのが一般的です。しかし、ソフトウェアのアップデートや外部APIへのアクセスなど、外部通信が必要な場面は多くあります。

Cloud NATは、外部IPアドレスを持たないインスタンスがインターネットへの送信通信を行うためのマネージドNATサービスです。

Cloud NATの構成要素

Cloud NATを設定するには、まずCloud Routerが必要です。

# Cloud Routerの作成
gcloud compute routers create my-nat-router \
  --network=my-production-vpc \
  --region=asia-northeast1

# Cloud NATの作成
gcloud compute routers nats create my-cloud-nat \
  --router=my-nat-router \
  --region=asia-northeast1 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Cloud NATの設定オプション

本番環境では、以下のオプションを検討してください。

NATするサブネットの限定

# 特定のサブネットのみNATを適用
gcloud compute routers nats create my-cloud-nat \
  --router=my-nat-router \
  --region=asia-northeast1 \
  --auto-allocate-nat-external-ips \
  --nat-custom-subnet-ip-ranges=app-subnet-tokyo,db-subnet-tokyo

静的IPアドレスの割り当て
外部サービスのIP許可リストに登録する場合は、静的IPを使用します。

# 静的IPアドレスの予約
gcloud compute addresses create nat-external-ip \
  --region=asia-northeast1

# 静的IPでCloud NATを作成
gcloud compute routers nats create my-cloud-nat \
  --router=my-nat-router \
  --region=asia-northeast1 \
  --nat-external-ip-pool=nat-external-ip \
  --nat-all-subnet-ip-ranges

ログの有効化
トラブルシューティング用にログ出力を有効化しておくと安心です。

# ログを有効化
gcloud compute routers nats update my-cloud-nat \
  --router=my-nat-router \
  --region=asia-northeast1 \
  --enable-logging \
  --log-filter=ALL

VPCピアリング・Shared VPC・プライベートアクセスの活用

複数のプロジェクトやVPCを運用する場合、ネットワーク間の接続方法やGCPサービスへのプライベート通信経路を理解しておく必要があります。

VPCピアリング

VPCピアリングは、異なるVPC間でプライベート通信を行う機能です。異なるプロジェクト間でも設定でき、トラフィックはGoogleのネットワーク内を通るため、低レイテンシかつ高セキュリティです。

# VPC-AからVPC-Bへのピアリングを作成
gcloud compute networks peerings create peer-a-to-b \
  --network=vpc-a \
  --peer-project=project-b \
  --peer-network=vpc-b

# VPC-BからVPC-Aへのピアリングも作成（双方で設定が必要）
gcloud compute networks peerings create peer-b-to-a \
  --network=vpc-b \
  --peer-project=project-a \
  --peer-network=vpc-a

ピアリングの注意点として、推移的ルーティングは不可です。VPC-AとVPC-B、VPC-BとVPC-Cがピアリングされていても、VPC-AからVPC-Cへは直接通信できません。

Shared VPC

Shared VPCは、ホストプロジェクトのVPCを複数のサービスプロジェクトで共有する仕組みです。組織内で統一されたネットワークポリシーを適用しつつ、プロジェクトごとにリソースを分離できます。

Shared VPCの利用が適しているケースは以下の通りです。

ネットワーク管理を一元化したい場合
複数チームがそれぞれのプロジェクトで作業するが、同じネットワークを共有する場合
ファイアウォールルールやサブネットの管理を中央で行いたい場合

プライベートGoogleアクセス

外部IPを持たないVMからCloud StorageやBigQueryなどのGoogle APIにアクセスできるようにする機能です。

# サブネットでプライベートGoogleアクセスを有効化
gcloud compute networks subnets update app-subnet-tokyo \
  --region=asia-northeast1 \
  --enable-private-google-access

この設定により、外部IPのないVMからでもCloud StorageへのデータアップロードやBigQueryへのクエリ実行が可能になります。Cloud NATと併せて設定することで、インターネット向けと Google サービス向けの通信を適切に分離できます。

Private Service Connect

Private Service Connectは、Google APIやサードパーティサービスに対してVPC内部のプライベートエンドポイントを作成する機能です。より厳密なネットワーク制御が必要な場合に有効です。

# Private Service Connectエンドポイントの作成
gcloud compute addresses create psc-endpoint-ip \
  --region=asia-northeast1 \
  --subnet=app-subnet-tokyo \
  --addresses=10.2.0.100

gcloud compute forwarding-rules create psc-google-apis \
  --region=asia-northeast1 \
  --network=my-production-vpc \
  --address=psc-endpoint-ip \
  --target-google-apis-bundle=all-apis

本番環境のネットワーク設計チェックリスト

ここまでの内容を踏まえて、本番環境のVPCネットワークを構築する際のチェックリストを紹介します。

設計フェーズのチェック項目

カスタムVPCを作成しているか：デフォルトVPCは使用しない
CIDR範囲が適切か：将来の拡張と他ネットワークとの重複を考慮する
サブネットが役割ごとに分離されているか：Web、App、DBの3層分離を基本とする
ファイアウォールルールが最小権限か：デフォルト拒否＋必要な通信のみ許可
プライベートGoogleアクセスが有効か：GCPサービスへのアクセス経路を確保する

運用フェーズのチェック項目

Cloud NATが正しく設定されているか：外部通信が必要なサブネットにNATを適用する
VPC Flow Logsが有効か：ネットワークトラフィックの監視と分析に必要
ファイアウォールルールのログが有効か：不正アクセスの検出に活用する
不要なファイアウォールルールが残っていないか：定期的に棚卸しする

# VPC Flow Logsを有効化
gcloud compute networks subnets update web-subnet-tokyo \
  --region=asia-northeast1 \
  --enable-flow-logs \
  --logging-aggregation-interval=interval-5-sec \
  --logging-flow-sampling=0.5

ネットワークの監視設定も忘れずに行いましょう。VPC Flow LogsのデータをCloud Monitoringと連携させることで、異常なトラフィックパターンを早期に検知できます。

まとめ：安全で拡張性の高いVPCネットワークを構築しよう

GCP VPCネットワークの設計は、クラウドインフラの安全性と効率性を左右する重要な工程です。この記事で解説したポイントを振り返ります。

カスタムVPCを使用し、必要なリージョンにのみサブネットを作成する
サブネットは役割ごとに分離し、将来の拡張を見据えたCIDR設計を行う
ファイアウォールルールはデフォルト拒否で最小権限を徹底する
Cloud NATでプライベートインスタンスの外部通信を安全に実現する
プライベートGoogleアクセスでGCPサービスへの通信をプライベートに保つ

まずは開発環境でカスタムVPCを作成し、サブネット分離とファイアウォールルールの設定を試してみてください。ネットワーク設計の知見は、Cloud RunやCloud FunctionsなどのサービスをVPC接続する際にも役立ちます。インフラ構成の管理にはTerraformによるコード化も検討することをお勧めします。