概要
システムを運用していると、複数の VPC を使い分ける場面が出てきます。本番環境と開発環境を別の VPC に分けたり、部門ごとに VPC を用意したりするケースです。それぞれの VPC はデフォルトでは独立しており、互いに通信できません。しかし、別々の VPC に置いたリソース同士で通信させたいというニーズは少なくありません。
VPC ピアリングは、2 つの VPC の間にネットワーク接続を確立し、プライベート IP アドレスを使ってリソース同士が相互に通信できるようにするしくみです。同じネットワーク内に存在しているかのように通信でき、トラフィックはパブリックインターネットを経由しません。
本記事では、VPC ピアリングの基本概念と制約を理解し、2 つの VPC をピアリング接続して相互にプライベート IP で疎通できる状態を構築するところまで体験します。
この記事のメリット
- VPC ピアリング接続のしくみと、リクエスタ／アクセプタの役割を理解できる
- 同一アカウント・別アカウント・別リージョン間でも接続できることを把握できる
- ピアリング接続後にルートテーブルへルートを追加する必要性と手順を習得できる
- 推移的ピアリング不可・CIDR 重複不可といった重要な制約を学べる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
クラウドおさるとひさん、VPC って 1 つだけじゃなくて、いくつも作ることがあるんですか？
土肥あるよ。本番環境と開発環境を分けたり、部門ごとに VPC を用意したりするのはよくあるパターンなんだ。ただ、VPC は基本的にそれぞれ独立した別々のネットワークだから、何もしないと VPC をまたいだ通信はできないんだよ。
クラウドおさるえっ、別の VPC にあるサーバー同士は話せないんですね。でも、本番の VPC と監視用の VPC でやり取りしたい、みたいなことはありそうですけど…。
土肥そこで登場するのが VPC ピアリングだよ。VPC ピアリングは、2 つの VPC の間にネットワーク接続を確立して、プライベート IPv4 アドレスを使ってお互いのリソースが通信できるようにするしくみなんだ。
クラウドおさる2 つの VPC をつなぐ橋みたいなものですね！
土肥いいたとえだね。しかも特別なゲートウェイや VPN 接続を用意するわけじゃないんだ。物理的なハードウェアにも依存しないから、単一障害点や帯域幅のボトルネックが発生しないっていう特徴があるよ。ピアリング接続でつながった VPC のインスタンス同士は、まるで同じネットワークの中にいるかのように通信できるんだ。
リクエスタとアクセプタ
クラウドおさるVPC ピアリングはどうやって作るんですか？片方の VPC でポチッと設定したら終わり、ですか？
土肥実は 2 段階の手続きが必要なんだ。ピアリング接続を「お願いする側」と「受け入れる側」に分かれていて、それぞれリクエスタ、アクセプタって呼ぶよ。
| 役割 | 説明 |
|---|---|
| リクエスタ | ピアリング接続を作成し、接続をリクエストする側の VPC |
| アクセプタ | リクエストを受け取り、接続を承認する側の VPC |
土肥まずリクエスタ側でピアリング接続を作成すると、接続は「承認待ち（pending-acceptance）」の状態になるんだ。そのあとアクセプタ側がそのリクエストを承認してはじめて、接続が「アクティブ（active）」になって使えるようになるんだよ。
クラウドおさる友達申請みたいですね。申請して、相手が承認してはじめてつながる、っていう。
土肥まさにそのイメージ！この承認のステップがあるおかげで、知らないうちに勝手に自分の VPC につながれる、ということが起きないんだ。今回は同じアカウント内で作るから、リクエストも承認も自分で操作することになるよ。
クラウドおさる同じアカウント内…ってことは、別のアカウントの VPC ともつなげるんですか？
土肥つなげるよ。VPC ピアリングが対応している接続パターンはこの 3 つなんだ。
| 接続パターン | 説明 |
|---|---|
| 同一アカウント・同一リージョン | 同じ AWS アカウント・同じリージョン内の VPC 同士 |
| 別アカウント間 | 異なる AWS アカウントが所有する VPC 同士 |
| 別リージョン間 | 異なるリージョンにある VPC 同士（リージョン間 VPC ピアリング） |
土肥別アカウント間の場合は、相手のアカウントの人が承認する必要がある。別リージョン間でも接続できて、その場合トラフィックはすべてプライベート IP アドレス空間に留まり、リージョン間の通信は AWS によって暗号化されるんだ。
ルートテーブルとセキュリティグループ
クラウドおさるピアリング接続を承認してアクティブになったら、それでもう通信できるんですか？
土肥実はもう一手間あるんだ。ピアリング接続を作っただけでは、トラフィックがどこに向かえばいいかわからない状態なんだよ。だから、両方の VPC のルートテーブルに「相手の VPC 宛てのトラフィックはこのピアリング接続に流す」というルートを追加する必要があるんだ。
クラウドおさる両方の…ってことは、片方だけじゃダメなんですか？
土肥ダメなんだ。通信は行きと帰りの両方が成立してはじめて成り立つからね。VPC A から VPC B に向かうルートと、VPC B から VPC A に戻るルート、両方が必要なんだ。具体的にはこんな設定になるよ。
| ルートテーブル | 送信先 | ターゲット |
|---|---|---|
| VPC A のルートテーブル | VPC A の CIDR | local |
| VPC B の CIDR | ピアリング接続（pcx-xxxx） | |
| VPC B のルートテーブル | VPC B の CIDR | local |
| VPC A の CIDR | ピアリング接続（pcx-xxxx） |
クラウドおさる送信先が相手の VPC の CIDR で、ターゲットがピアリング接続なんですね！前に習ったインターネットゲートウェイへのルートと考え方は同じですね。
土肥そうそう、よく覚えてたね。ターゲットがピアリング接続になっているだけで、ルートテーブルの考え方はまったく同じだよ。ちなみに、接続が承認待ちのうちにルートを追加すると、そのルートは blackhole 状態になって、接続がアクティブになるまで有効にならないんだ。
クラウドおさるルートを追加したら通信できる…と思いきや、セキュリティグループとかも関係しそうですけど大丈夫ですか？
土肥いいところに気づいたね。ルートテーブルはあくまで「道」を作るだけで、最終的に通信を許可するかはセキュリティグループ次第なんだ。ピア先からの通信を受け入れる側のセキュリティグループで、相手 VPC の CIDR からのインバウンドを許可しておく必要があるよ。
土肥ちょっと便利な話をすると、同じリージョン内のピアリング接続なら、セキュリティグループのルールで相手 VPC のセキュリティグループ ID を直接参照することもできるんだ。CIDR を書く代わりに「あのセキュリティグループからの通信を許可」と指定できるから、IP レンジを意識せずに済むんだよ。
クラウドおさるルートテーブルで道を作って、セキュリティグループで通行許可を出す、っていう役割分担なんですね。
VPC ピアリングの制約
クラウドおさるVPC ピアリングって万能そうに見えますけど、気をつけることはありますか？
土肥いくつか重要な制約があるんだ。試験でもよく問われるところだから、表で整理しておこう。
| 制約 | 内容 |
|---|---|
| CIDR の重複不可 | リクエスタ VPC とアクセプタ VPC の CIDR ブロックが一致・重複しているとピアリング接続を作成できない |
| 推移的ピアリング不可 | VPC A-B、VPC A-C を接続しても、VPC B と VPC C は通信できない |
| エッジ間ルーティング不可 | ピア先 VPC のインターネットゲートウェイ・NAT デバイス・VPN 接続・Direct Connect・ゲートウェイエンドポイントを経由した通信はできない |
| 1 対 1 の関係 | 同じ 2 つの VPC 間に複数のピアリング接続を同時に持つことはできない |
クラウドおさるCIDR が重複しているとダメなんですね。10.0.0.0/16 の VPC 同士はつなげない…？
土肥そのとおり。だから複数の VPC をピアリングでつなぐ前提なら、最初から CIDR が重ならないように設計しておくことが大切なんだ。今回のハンズオンでも、VPC A は 10.0.0.0/16、VPC B は 10.1.0.0/16 というふうに、わざと別の範囲にしているよ。
クラウドおさる推移的ピアリング不可、っていうのがちょっと難しいです…。
土肥簡単に言うとね、A と B、A と C をそれぞれピアリングしても、B と C は通信できないってことなんだ。ピアリングはあくまで「直接つないだ 2 者」だけの関係で、間の VPC を経由して別の VPC へ通り抜けることはできないんだよ。B と C を通信させたいなら、B と C の間に直接もう 1 本ピアリング接続を作る必要があるんだ。
クラウドおさるなるほど！つなぎたい組み合わせの数だけピアリング接続が要るんですね。VPC が増えてくると本数が大変そう…。
土肥いいところに気づいたね。VPC が 4 つ、5 つと増えると、全部を相互につなぐにはピアリング接続が爆発的に増えてしまう。そういうときは AWS Transit Gateway という、複数の VPC を中央のハブでまとめて接続できるサービスを検討するのが定番なんだ。VPC ピアリングは「数個の VPC をシンプルにつなぐ」のに向いている、と覚えておこう。
実践
2 つの VPC をピアリング接続し、それぞれの VPC に配置した EC2 インスタンス同士がプライベート IP で疎通できる状態を構築します。ピアリング接続の作成・承認、両側のルートテーブルへのルート追加、AWS Systems Manager Session Manager を使った疎通確認までを行います。
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
- VPC A（CIDR
10.0.0.0/16）と、その中のサブネット・EC2 インスタンス 1 台 - VPC B（CIDR
10.1.0.0/16）と、その中のサブネット・EC2 インスタンス 1 台 - 各 EC2 インスタンスには
AmazonSSMManagedInstanceCoreを含む IAM インスタンスプロファイルが付与されており、Session Manager で接続できる状態であること - IAM ユーザーまたはロールに VPC・EC2・Systems Manager の操作権限があること
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPC ピアリング接続 | peer-vpc-a-to-b | VPC A と VPC B を接続 |
| ルート（VPC A 側） | peer-rt-a に追加 | 10.1.0.0/16 宛てをピアリング接続へ転送 |
| ルート（VPC B 側） | peer-rt-b に追加 | 10.0.0.0/16 宛てをピアリング接続へ転送 |
前提として用意されている主なリソースは次のとおりです。
| リソース種別 | リソース名 | CIDR / 配置 |
|---|---|---|
| VPC | peer-vpc-a | 10.0.0.0/16 |
| サブネット | peer-subnet-a | 10.0.1.0/24（ap-northeast-1a） |
| ルートテーブル | peer-rt-a | peer-subnet-a に関連付け |
| EC2 インスタンス | peer-server-a | peer-subnet-a 内 |
| VPC | peer-vpc-b | 10.1.0.0/16 |
| サブネット | peer-subnet-b | 10.1.1.0/24（ap-northeast-1a） |
| ルートテーブル | peer-rt-b | peer-subnet-b に関連付け |
| EC2 インスタンス | peer-server-b | peer-subnet-b 内 |
ステップ1: VPC ピアリング接続を作成する
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
VPCと入力し、表示された「VPC」を選択します - 左側ナビゲーションの「ピアリング接続」を選択し、「ピアリング接続を作成」をクリックします
- 以下の内容を入力します
- 名前:
peer-vpc-a-to-b - VPC ID（リクエスタ）:
peer-vpc-aを選択 - アカウント:
自分のアカウントを選択 - リージョン:
このリージョンを選択 - VPC ID（アクセプタ）:
peer-vpc-bを選択
- 「ピアリング接続を作成」をクリックします
- 作成された
peer-vpc-a-to-bの状態が保留中の承諾（pending-acceptance）であることを確認します
ステップ2: ピアリング接続を承認する
リクエスタ側で作成したピアリング接続を、アクセプタ側で承認します。今回は同一アカウント内のため、同じ画面から操作できます。
- ピアリング接続の一覧で
peer-vpc-a-to-bを選択します - 「アクション」→「リクエストを承諾」を選択します
- 確認ダイアログで「リクエストを承諾」をクリックします
- 状態が
アクティブ（active）に変わったことを確認します
ステップ3: VPC A のルートテーブルにルートを追加する
VPC A 側の peer-server-a から VPC B 宛てのトラフィックがピアリング接続に流れるよう、ルートを追加します。
- 左側ナビゲーションの「ルートテーブル」を選択します
- ルートテーブルの一覧から
peer-rt-aを選択します - 「ルート」タブを選択し、「ルートを編集」をクリックします
- 「ルートを追加」をクリックし、以下を入力します
- 送信先:
10.1.0.0/16（VPC B の CIDR） - ターゲット:
ピアリング接続を選択し、peer-vpc-a-to-b（pcx-xxxx）を選択
- 「変更を保存」をクリックします
ステップ4: VPC B のルートテーブルにルートを追加する
VPC B 側の peer-server-b から VPC A 宛てのトラフィックがピアリング接続に流れるよう、戻り側のルートを追加します。
- ルートテーブルの一覧から
peer-rt-bを選択します - 「ルート」タブを選択し、「ルートを編集」をクリックします
- 「ルートを追加」をクリックし、以下を入力します
- 送信先:
10.0.0.0/16（VPC A の CIDR） - ターゲット:
ピアリング接続を選択し、peer-vpc-a-to-b（pcx-xxxx）を選択 - 「変更を保存」をクリックします
peer-rt-bの「ルート」タブで、追加したルートの状態がアクティブになっていることを確認します
ステップ5: 相手 VPC の EC2 のプライベート IP を確認する
疎通確認の前に、接続先となる peer-server-b のプライベート IP アドレスを確認します。
- 上部の検索バーに
EC2と入力し、表示された「EC2」を選択します - 左側ナビゲーションの「インスタンス」を選択します
peer-server-bを選択し、詳細画面の「プライベート IPv4 アドレス」をメモします（例:10.1.1.x）
ステップ6: Session Manager で接続して疎通を確認する
peer-server-a に Session Manager で接続し、peer-server-b のプライベート IP に対して ping を実行します。
- EC2 のインスタンス一覧で
peer-server-aを選択し、「接続」をクリックします - 「セッションマネージャー」タブを選択し、「接続」をクリックします
- ブラウザ上にターミナルが開いたら、以下のコマンドで
peer-server-bのプライベート IP に ping を実行します ping -c 4 <peer-server-b のプライベート IP>- 応答が返り、パケットロスがないことを確認します
VPC A の peer-server-a から VPC B の peer-server-b へ、プライベート IP アドレスを使った通信が成立していることが確認できます。ピアリング接続・両側のルート・セキュリティグループの 3 つが揃ってはじめて VPC をまたいだ通信が可能になります。
まとめ
- VPC ピアリングは、2 つの VPC をプライベート IP アドレスで相互通信させるネットワーク接続である
- 接続はリクエスタが作成し、アクセプタが承認することでアクティブになる
- 同一アカウント・別アカウント・別リージョン間のいずれの VPC でも接続できる
- ピアリング接続を作成しただけでは通信できず、両側のルートテーブルにピア先 CIDR 宛てのルートを追加する必要がある
- セキュリティグループでピア先 VPC からのインバウンドを許可する（同一リージョンならピア先のセキュリティグループ ID を参照することも可能）
- CIDR の重複不可・推移的ピアリング不可・エッジ間ルーティング不可といった制約があり、多数の VPC を相互接続する場合は AWS Transit Gateway を検討する
