皆さん、こんにちは！SRE兼クラウドアーキテクトの〇〇です。
今日のテーマは、GCPのネットワーク、特に「VPCネットワークピアリング」について、皆さんの「なるほど！」を引き出すべく、現場の知見をたっぷり詰め込んでお話ししていきたいと思います。
クラウドインフラに触れ始めたばかりのエンジニアさんや、ネットワークの概念をこれから深掘りしていきたい初学者さんにとって、VPCピアリングってちょっと難しそうに見えるかもしれません。でも大丈夫！パケットがネットワークを駆け巡るリアルな挙動を、身近な例え話でじっくり紐解いていきますから、安心してくださいね。
GCPのVPCピアリングで「遠くのあのVPC」と手をつなぐ！双方向ルート交換の魔法と注意点
GCPでシステムを構築していると、複数のVPC（Virtual Private Cloud）を使う場面に必ず出会います。例えば、本番環境と開発環境を分けたり、セキュリティ要件の異なる部署ごとにVPCを分けたり、はたまた、複数のプロジェクト間でサービス連携が必要になったり、と色々ですよね。
VPCは、あなた専用のプライベートなネットワーク空間。自分だけのIPアドレス範囲を持ち、他のVPCからは基本的に直接アクセスできない、いわば「独立したオフィスビル」のようなものです。
「でも、独立したオフィスビル同士で、内線電話（プライベートIP）で直接話せたら便利なのに…」
そう思われたこと、ありませんか？インターネットを経由するのではなく、もっとセキュアに、もっと高速に、まるで同じVPC内にいるかのように通信できたら、システム連携が格段にスムーズになりますよね。
そこで登場するのが、GCPの強力なネットワーク機能の一つ「VPCネットワークピアリング（VPC Network Peering）」なんです！
VPCピアリングって何？ – 異なるVPC間の専用回線
VPCピアリングは、その名の通り、異なるVPC同士を「ピア（peer：対等な相手）」として直接つなぐ機能です。想像してみてください。隣り合う会社（異なるVPC）同士が、社外のインターネットに出ることなく、オフィス内に秘密の専用回線（プライベートネットワークパス）を引いて、お互いの内線電話番号（プライベートIPアドレス）で直接連絡を取り合えるようにするイメージです。
この専用回線を使うメリットはたくさんあります。
- セキュリティの向上: インターネットを経由しないため、外部からの攻撃リスクが低減します。
- パフォーマンスの向上: ネットワークの経路が短縮され、レイテンシ（通信遅延）が減少し、データ転送速度が向上します。
- コスト効率の改善: インターネットへのEgress（送信）トラフィックは通常課金されますが、VPCピアリング経由の通信はプライベートネットワーク内のため、データ転送費用が削減される場合があります。
まさに、クラウドにおける「内線電話」のような役割を担ってくれる、とても便利な機能なんですよ。
双方向ルート交換の魔法 – 郵便配達員さんの連携プレー
VPCピアリングの面白いところは、ただつなぐだけでなく、その裏で「双方向ルート交換」という魔法が働いている点です。
皆さんのVPCには、郵便局の配達員さん（ルーティングテーブル）がいます。この配達員さんは、「自分のVPCの中にある、どのIPアドレスがどこにあるか」という住所録（ルート情報）をしっかり持っています。
通常、違うVPCにあるIPアドレスの場所は、自分のVPCの配達員さんは知りません。だから、直接手紙（パケット）を届けられないわけです。
しかし、VPCピアリングを設定すると、どうなるでしょう？
1. VPC AとVPC Bが「ピアリング」という契約を交わします。
2. VPC Aの配達員さんとVPC Bの配達員さんが、お互いの住所録を交換し合います。
- 「私のVPC Aには、
10.10.0.0/16の範囲に、たくさんのサーバーがありますよ！」 - 「なるほど！私のVPC Bには、
10.20.0.0/16の範囲にありますよ！」
3. すると、VPC Aの配達員さんも、VPC Bの10.20.0.0/16の場所を知り、VPC Bの配達員さんも、VPC Aの10.10.0.0/16の場所を知るようになります。
この「お互いの住所録を交換し合う」というのが、まさに双方向ルート交換なんです！これによって、VPC AからVPC Bのサーバーへ、またはVPC BからVPC Aのサーバーへ、まるで同じVPC内にいるかのように、プライベートIPアドレスを使って直接通信できるようになるんですね。GCPがこの裏側のルーティング設定を自動でやってくれるので、私たちは難しい設定に頭を悩ませる必要はありません。すごいですよね！
ここが重要！推移的ルーティングは非サポート – 「友達の友達は友達じゃない」ルール
さて、とても便利なVPCピアリングですが、一つだけ、いえ、いくつか注意すべき「現場あるあるの落とし穴」があります。その中でも特に重要なのが「推移的ルーティング（Transitive Routing）はサポートされない」という仕様です。
これはどういうことかというと、先ほどの友達の例で考えてみましょう。
- VPC AさんはVPC Bさんと友達です。（A ↔ B でピアリング済み）
- VPC BさんはVPC Cさんと友達です。（B ↔ C でピアリング済み）
このとき、VPC AさんとVPC Cさんは直接友達ではありません。つまり、VPC AからVPC Cへは、直接通信できないんです！
まるで、「AさんはBさんの家を知っている。BさんはCさんの家を知っている。でも、AさんはCさんの家は知らないから、Cさんの家に直接は行けない」というルールと一緒です。AさんがCさんの家に行くには、一度Bさんの家を経由して、BさんにCさんの家まで連れて行ってもらう必要があります。
VPCピアリングでは、この「友達の友達は友達」という推移的な関係は自動的には成立しません。AさんとCさんを通信させたいなら、AさんとCさんの間にも別途ピアリングを設定するか、VPC Bを中継点としてトラフィックをルーティングする（この場合、VPC BがNATゲートウェイやプロキシとして機能する必要があります）などの工夫が必要になります。
この「推移的ルーティングの非サポート」は、VPCピアリングを使ったネットワーク設計で最も引っかかりやすいポイントの一つです。複雑なネットワークを設計する際には、このルールを常に意識して、どこからどこへ直接通信できるのかを明確にしておくことが大切になります。
IPアドレス重複にご用心！ – 同じ住所の家が２つあったら？
もう一つ、VPCピアリングでトラブルになりやすいのが、IPアドレス範囲の重複です。
想像してみてください。VPC Aには「192.168.1.10」という住所の家があり、VPC Bにもたまたま「192.168.1.10」という住所の家があったとします。
この状態でVPC AとVPC Bをピアリングで接続したら、どうなるでしょう？
VPC Aの配達員さんが「192.168.1.10」に手紙を届けようとしたとき、自分のVPC内の家なのか、それともピアリング先のVPC Bの家なのか、判断に困ってしまいますよね！まるで、同じ番地の家が自分の町と隣の町、両方に存在しているようなものです。
GCPのVPCピアリングでは、IPアドレス範囲（CIDRブロック）が重複しているVPC同士は、基本的にピアリングを確立できません。 もし重複がある場合は、ピアリングを作成しようとしたときにエラーや警告が表示されることがほとんどです。
これは意図しないルーティングの混乱やセキュリティリスクを防ぐための、GCPの賢い設計なんです。
最も良い解決策は、VPCを設計する段階で、IPアドレス範囲が重複しないようにしっかりと計画を立てることです。 各VPCに割り当てるIPアドレス範囲を、ユニークで管理しやすい形で設計することが、長期的に安定したクラウドインフラを運用する上で非常に重要になります。
もし、どうしても既存のVPCでIPアドレスが重複してしまっている場合は、VPCピアリングは使わず、Cloud VPNやCloud Interconnectといった別の接続方法を検討したり、NAT（Network Address Translation）ゲートウェイを介してIPアドレスを変換してから通信させるなどの高度なテクニックが必要になります。しかし、これは複雑になりがちなので、可能な限りIPアドレスの重複は避けるようにしましょう。
実際にVPCピアリングを設定してみよう！ – gcloudコマンドで簡単接続
それでは、実際にGCPのgcloudコマンドを使って、VPCピアリングを設定してみましょう。今回は、2つのVPCを作成し、それぞれにVMインスタンスを配置して、お互いにプライベートIPで通信できることを確認する手順です。
# プロジェクトIDを設定（ご自身のプロジェクトIDに置き換えてください）
export GCP_PROJECT_ID="your-gcp-project-id"
gcloud config set project ${GCP_PROJECT_ID}
# --- VPC 1 の作成 ---
echo "VPC 1 (network-a) を作成します..."
gcloud compute networks create network-a \
--subnet-mode=auto \
--description="VPC A for Peering Demo"
echo "VPC 1 (network-a) にサブネットが作成されるまで少し待ちます..."
# auto-create-subnetworks モードの場合、サブネットの作成に少し時間がかかることがあります
sleep 30
echo "VPC 1 (network-a) のサブネット情報を確認します。"
gcloud compute networks subnets list --network=network-a
echo "VPC 1 (network-a) にVMインスタンスを作成します..."
gcloud compute instances create instance-a \
--zone=asia-northeast1-b \
--network=network-a \
--machine-type=e2-micro \
--image-family=debian-11 \
--image-project=debian-cloud \
--no-address # 外部IPアドレスなしで作成し、プライベート通信を確認
# --- VPC 2 の作成 ---
echo "VPC 2 (network-b) を作成します..."
gcloud compute networks create network-b \
--subnet-mode=auto \
--description="VPC B for Peering Demo"
echo "VPC 2 (network-b) にサブネットが作成されるまで少し待ちます..."
sleep 30
echo "VPC 2 (network-b) のサブネット情報を確認します。"
gcloud compute networks subnets list --network=network-b
echo "VPC 2 (network-b) にVMインスタンスを作成します..."
gcloud compute instances create instance-b \
--zone=asia-northeast1-c \
--network=network-b \
--machine-type=e2-micro \
--image-family=debian-11 \
--image-project=debian-cloud \
--no-address # 外部IPアドレスなしで作成し、プライベート通信を確認
# --- VPC ピアリングの設定 ---
echo "VPC A (network-a) から VPC B (network-b) へのピアリング接続を作成します..."
gcloud compute networks peerings create peering-ab \
--network=network-a \
--peer-project=${GCP_PROJECT_ID} \
--peer-network=network-b
echo "VPC B (network-b) から VPC A (network-a) へのピアリング接続を作成します..."
# 注意: ピアリングは片方から作成すると、もう片方では自動的に「受諾待ち」状態になります。
# どちらか一方で `gcloud compute networks peerings create` を実行し、
# もう片方で `gcloud compute networks peerings update` でアクティブにするか、
# もしくは、両方から create を実行すると自動的にEstablishedになります。
# 今回は両方から create を実行するパターンで進めます。
gcloud compute networks peerings create peering-ba \
--network=network-b \
--peer-project=${GCP_PROJECT_ID} \
--peer-network=network-a
echo "ピアリング接続が確立されるまで少し待ちます..."
sleep 20
# --- ピアリングの状態確認 ---
echo "VPC ピアリングの状態を確認します..."
gcloud compute networks peerings list
# --- VMのプライベートIPアドレスを取得 ---
echo "VMインスタンスのプライベートIPアドレスを取得します..."
INSTANCE_A_IP=$(gcloud compute instances describe instance-a --zone=asia-northeast1-b --format='value(networkInterfaces[0].networkIp)')
INSTANCE_B_IP=$(gcloud compute instances describe instance-b --zone=asia-northeast1-c --format='value(networkInterfaces[0].networkIp)')
echo "instance-a のプライベートIP: ${INSTANCE_A_IP}"
echo "instance-b のプライベートIP: ${INSTANCE_B_IP}"
# --- 疎通確認（instance-a から instance-b へ） ---
echo "instance-a から instance-b への疎通確認を行います..."
# instance-a のシェルにSSHで接続し、pingコマンドを実行します
gcloud compute ssh instance-a --zone=asia-northeast1-b --command="ping -c 3 ${INSTANCE_B_IP}"
# --- 疎通確認（instance-b から instance-a へ） ---
echo "instance-b から instance-a への疎通確認を行います..."
# instance-b のシェルにSSHで接続し、pingコマンドを実行します
gcloud compute ssh instance-b --zone=asia-northeast1-c --command="ping -c 3 ${INSTANCE_A_IP}"
echo "デモ完了！不要になったリソースをクリーンアップする場合は、以下のコマンドを実行してください。"
echo "gcloud compute instances delete instance-a --zone=asia-northeast1-b -q"
echo "gcloud compute instances delete instance-b --zone=asia-northeast1-c -q"
echo "gcloud compute networks peerings delete peering-ab --network=network-a -q"
echo "gcloud compute networks peerings delete peering-ba --network=network-b -q"
echo "gcloud compute networks delete network-a -q"
echo "gcloud compute networks delete network-b -q"上記のコマンドを実行すると、instance-aからinstance-bへ、そしてinstance-bからinstance-aへ、それぞれプライベートIPアドレスを使ってpingが成功するはずです。
もしpingが通らない場合は、以下の点を確認してみてください。
- ピアリングの状態:
gcloud compute networks peerings listでSTATEがACTIVEになっているか。 - ファイアウォールルール: 各VPCのファイアウォールルールで、ICMP（pingに使われるプロトコル）が許可されているか。デフォルトでは同じネットワーク内のVM間の通信は許可されますが、ピアリング経由の場合は明示的に許可が必要な場合があります。
まとめ
VPCネットワークピアリングは、異なるVPC間のプライベート接続を実現する、非常に強力で便利な機能です。
- まるで「秘密の専用通路」のように、セキュアで高速な通信を可能にします。
- GCPが自動で「双方向ルート交換」を行ってくれるため、手動でのルーティング設定は不要です。
- ただし、「友達の友達は友達じゃない」という推移的ルーティングの非サポートには要注意！複雑なネットワーク設計では、このルールを常に頭に入れておきましょう。
- そして、IPアドレス範囲の重複は厳禁です。設計段階でしっかり計画を立てて、重複を避けることが最も重要です。
これらのポイントを押さえれば、VPCピアリングを最大限に活用し、より柔軟で堅牢なクラウドインフラを構築できるようになりますよ。
最初は少し難しく感じるかもしれませんが、実際に手を動かして試してみることで、パケットがネットワークを駆け巡る感覚が掴めてくるはずです。一歩ずつ、着実に理解を深めていきましょう！
それでは、また次回の記事でお会いしましょう！
コメント