はじめに
「VPCを2つ作ったけど、お互いに通信させたい」「別アカウントの開発チームのVPCに、本番VPCから繋ぎたい」── AWSを触り始めると、こんな場面によく遭遇しますよね。
そんなときに登場するのが VPCピアリング です。名前は聞いたことがあっても、「実際何をしてるサービスなんだろう？」と曖昧なまま使っている人も多いのではないでしょうか。
この記事では、図解を多めに使いながら、VPCピアリングの仕組み・ユースケース・落とし穴をゼロから解説します。
この記事は2026年4月時点の情報をもとに執筆しています。料金や仕様の最新情報は必ず公式ドキュメントもご確認ください。
対象読者
- AWSを学び始めて、VPCやEC2は触ったことがある人
- VPCピアリングという言葉は聞いたけど、仕組みまでは理解できていない人
- AWS認定資格（CLF・SAA）の勉強中で、ネットワーク領域を整理したい人
前提知識
- VPC・サブネット・EC2の概念をなんとなく知っている
- ルートテーブルが「どこ宛ての通信をどこに流すか」の設定だと知っている
参考リンク
本記事で参照している公式ドキュメントです。手元に開きながら読むと理解が深まります。
VPCピアリングとは何か？ ─ ざっくりイメージで掴む
例え話：2つのオフィスを「専用の渡り廊下」でつなぐ
VPCピアリングを一言で表すと、「2つのVPC間に専用の渡り廊下を架ける機能」 です。
通常、VPCは互いに完全に隔離されています。VPC AのEC2からVPC BのEC2へ通信したいときは、本来ならインターネットを経由しないといけません。これは「外に一度出てから隣のオフィスに行く」ようなもので、遠回りで危険です。
VPCピアリングは、この2つのVPCの間に AWS内部だけで完結する「渡り廊下」 を作る仕組みです。
公式ドキュメントの定義
公式ドキュメントでは、VPCピアリング接続を「2つのVPC間でプライベートIPアドレスを使ったトラフィックのルーティングを可能にするネットワーク接続」と定義しています。
ポイントは次の3つです。
- プライベートIPで通信できる：パブリックIPやインターネットゲートウェイは不要
- 同じネットワークにいるかのように扱える：別のVPCなのに、まるで1つのVPCのように通信可能
- ゲートウェイやVPN機器は不要：AWS既存のインフラを使うため、追加ハードウェアなし
つまり、最小の手間で・安全に・高速に2つのVPCを接続できる、というのがVPCピアリングの売りです。
なぜVPCピアリングが必要なのか？
前提：VPCはデフォルトで完全に隔離されている
AWSの大原則として、VPCは互いに論理的に分離されたプライベートネットワーク です。
同じAWSアカウントで作った2つのVPCであっても、何もしなければお互いに通信できません。これはセキュリティ上のメリットですが、複数VPCで連携が必要なシステムを組むときには制約にもなります。
「インターネット経由」では遠回りで危険
「じゃあパブリックIPを振って、インターネット経由で通信すればいいのでは？」と思うかもしれません。確かに技術的には可能ですが、
- パブリックIPを露出するためセキュリティリスクが上がる
- インターネット経由なのでレイテンシが増える
- データ転送コストも増える
といったデメリットがあります。VPCピアリングは、これらをまとめて解決してくれる選択肢です。
VPCピアリングの仕組みを図で理解する
リクエスタとアクセプタ：申請する側／承認する側
VPCピアリング接続は、リクエスタ（要求側）とアクセプタ（承認側） という2つの役割で成立します。
異なるアカウント間でピアリングを作る場合は、相手アカウントの管理者が承認操作をすることで初めて接続が成立します。同一アカウント内なら自分で承認できます。
接続のライフサイクル
ピアリング接続にはいくつかの状態（ステータス）があります。
通常は Pending-acceptance → Provisioning → Active と遷移し、Activeになって初めて通信できる状態になります。
ステータスや削除後の表示期間など細かいルールは公式ドキュメントの「VPC ピアリング接続の仕組み」ページにまとまっています。実運用前に一度目を通しておくと安心です。
トラフィックはAWSバックボーンを流れる
VPCピアリングを通る通信は、AWSのグローバルバックボーンネットワーク内に閉じる のが大きな特徴です。インターネット・VPN接続・Direct Connectのいずれも経由しません。
特にリージョン間ピアリングの場合、AWS施設を出る前に トラフィックは自動的に暗号化 されます。設定不要で安全な経路が確保される、というのは大きなメリットですね。
VPCピアリングの3つのユースケース
① 同一アカウント・同一リージョンの2つのVPCを繋ぐ
最もシンプルな構成です。たとえば「Web層用VPC」と「DB層用VPC」を分けて運用していて、Web層からDB層へ通信させたいケース。
② 別アカウントのVPCと繋ぐ（クロスアカウントピアリング）
AWS Organizationsで複数アカウントを管理しているチームでは、「共通サービス用アカウント」と「個別ワークロード用アカウント」 をピアリングで繋ぐパターンが定番です。
③ 別リージョンのVPCと繋ぐ（インターリージョンピアリング）
東京リージョンと大阪リージョン、あるいは東京とバージニア（us-east-1）など、地理的に離れたVPCも接続できます。DR（災害対策）構成やグローバル展開 で活用されます。
リージョン間ピアリングは2017〜2019年にかけて段階的に対応リージョンが拡大し、現在は主要リージョン間で利用可能です。
ここだけは押さえる「3大ルール」
VPCピアリングを使う上で、必ず覚えておきたい3つの制約があります。
ルール1：CIDRブロックが重複してはいけない
これが 最も重要なルール です。
VPC Aが 10.0.0.0/16、VPC Bも 10.0.0.0/16 の場合、そもそもピアリング接続を作成できません。完全一致でなくても、一部でも重複（例：10.0.0.0/16 と 10.0.0.0/24）するとNGです。
新規でVPCを設計するときは、将来のピアリングを見越してCIDRブロックを重複させない計画を立てましょう。一度運用が始まったVPCのCIDR変更は非常に手間がかかります。
ルール2：推移的ピアリングはサポートされない
これも初学者がハマりやすいポイントです。
VPC AとVPC B、VPC BとVPC Cがそれぞれピアリングされていても、VPC AからVPC Bを経由してVPC Cに通信することはできません。これを「推移的ピアリング（transitive peering）はサポートされない」と言います。
3つのVPC全てを相互接続したいなら、A↔B、B↔C、A↔Cの3つすべて をそれぞれピアリングする必要があります。
ルール3：ルートテーブルの設定を忘れない
ピアリング接続を作って承認しただけでは、まだ通信できません。両方のVPCのルートテーブルに、相手VPC宛てのルートを追加 する必要があります。
| ルートテーブル | 送信先 | ターゲット |
|---|---|---|
| VPC A のルートテーブル |
172.16.0.0/16（VPC BのCIDR） |
pcx-xxxxx（ピアリング接続ID） |
| VPC B のルートテーブル |
10.0.0.0/16（VPC AのCIDR） |
pcx-xxxxx（ピアリング接続ID） |
「ピアリング接続は作ったのに通信できない！」というトラブルは、だいたいこのルートテーブル設定漏れが原因 です。覚えておくと将来の自分が救われます。
加えて、EC2のセキュリティグループでも相手VPCからの通信を許可しておく必要があります。
VPCピアリングで「できないこと」
VPCピアリングは便利ですが、いくつか 「できないこと」 があります。
- ピア越しのIGW・NAT Gateway共用は不可：VPC AにNAT Gatewayがあっても、VPC Bからそれを使ってインターネットに出ることはできません
- ピア越しのVPN・Direct Connect共用も不可：VPC AにDirect Connect接続があっても、VPC Bからオンプレミス環境にアクセスするのに使うことはできません
- リージョン間ではセキュリティグループの相互参照ができない：同一リージョン内のピアリングなら、相手VPCのセキュリティグループIDを指定したルールが書けますが、リージョンが異なるとIP/CIDR指定でしかアクセス制御できません
「VPC AのDirect ConnectをVPC Bからも使いたい」のような 共有用途 には、後述するTransit Gatewayの方が適しています。
料金の考え方
執筆時点（2026年4月）の料金体系は次の通りです。
- ピアリング接続そのものの作成・維持は無料
-
データ転送には料金が発生する
- 同一AZ内：原則無料
- 異なるAZ間：AZ間データ転送料金が発生
- 異なるリージョン間：リージョン間データ転送料金が発生（より高額）
「ピアリング自体はタダだから安心」と思いがちですが、インターリージョンピアリングで大量のデータを流す構成は要注意 です。最新の料金は必ず公式の料金ページで確認しましょう。
VPCが3つ以上になったら？ ─ Transit Gatewayという選択肢
フルメッシュ問題：接続数が爆発する
VPCピアリングは1対1の接続なので、3つ以上のVPCを相互接続したいときには 接続数が一気に増えます。
接続数を計算する公式は N(N-1)/2 です。
| VPC数 | 必要な接続数 |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |
これは管理コストが膨大になりますし、VPCあたりのピアリング接続数の上限（デフォルト50、上限緩和申請で最大125） にもいずれ引っかかります。
ハブ&スポーク構成のTransit Gateway
そこで登場するのが AWS Transit Gateway です。中央にゲートウェイを置き、各VPCをそこに接続する ハブ&スポーク型 のアーキテクチャを実現できます。
VPC数が増えても接続はTransit Gatewayにアタッチするだけ。ルーティングも一元管理できます。
使い分けの目安
| VPCピアリング | Transit Gateway | |
|---|---|---|
| 接続トポロジ | 1対1 | ハブ&スポーク |
| 適した規模 | 数個程度の少数VPC | 多数VPC・大規模環境 |
| 料金 | 接続自体は無料・データ転送のみ | アタッチメントの時間料金＋データ転送 |
| ルーティング | 各VPCのルートテーブルで個別管理 | TGWルートテーブルで一元管理 |
| オンプレ接続の集約 | 不可 | 可能（VPN/Direct Connect統合） |
| レイテンシ | 直接接続のため最小 | TGWを1ホップ経由 |
公式ホワイトペーパーでも、少数VPCの単純な接続にはVPCピアリング、複雑・大規模な構成にはTransit Gateway という使い分けが推奨されています。
小規模スタート時はVPCピアリングで始めて、VPCが増えてきたらTransit Gatewayに移行する、という進め方も一般的です。AWS公式ブログにも移行ガイドが公開されています。
まとめ
ここまでの内容を振り返りましょう。
- VPCピアリングは2つのVPCを「専用の渡り廊下」で繋ぐ機能：プライベートIPで安全・高速に通信できる
- 3つのユースケース：同一アカウント・クロスアカウント・インターリージョン
- 3大ルール：CIDR重複NG、推移的ピアリング不可、ルートテーブル設定必須
- できないこと：IGW・NAT Gateway・VPN・Direct Connectのピア越し共用、リージョン間SG相互参照
- 料金：接続自体は無料、データ転送は有料（特にリージョン間は要注意）
- 大規模環境ではTransit Gateway が現実解になる