はじめる前に
- 必須AWS アカウントを持ち、マネジメントコンソールにサインインできること
- 必須VPC・サブネット・ルートテーブル・インターネットゲートウェイの基本を、自分で組み立てられること
- 必須EC2 を起動し、キーペアで SSH ログインした経験があること
- 必須セキュリティグループで通信を許可した経験があること
- あると良い「CIDR ブロック」が IP アドレスの範囲を表す、ということをなんとなく知っている
※ コンソール操作に加えて、お使いのパソコンのターミナルから 1 回 SSH を使用します。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
システムの規模が大きくなると、役割や環境ごとに VPC を分けて使う場面が増えます。たとえば「アプリ用の VPC」と「データ用の VPC」を別々に用意すると、IP アドレス範囲の衝突を避けやすく、片方の変更がもう片方に影響しにくくなります。一方で、VPC は何もしなければ互いに孤立したネットワークであり、アプリ側からデータ側のサーバーに直接アクセスする道がありません。
この 2 つを安全につなぐ仕組みが VPC ピアリングです。指定した CIDR の範囲だけ、2 つの VPC のプライベート IP アドレスが直接通信できるようになります。今回は別々の CIDR を持つ 2 つの VPC を作り、ピアリング接続を経由して片方から他方のサーバーへ到達できることを確かめます。
VPC を分けずに、最初から 1 つの VPC にまとめればいいのでは？
まとめてしまうと身軽な反面、誤った変更の影響範囲が全体に及びやすくなります。役割ごとに VPC を分けておくと影響範囲を切り離せますが、その代わり必要な通信だけを後から安全につなぐ手段が必要になります。VPC ピアリングはその代表的な手段の 1 つです。
ピアリングすると、2 つの VPC は 1 つになるの？
いいえ、VPC 自体はあくまで別々のままです。変わるのは「指定した CIDR 同士が、ルートテーブルとセキュリティグループで許可した範囲だけ、直接通信できる経路を持つ」という点だけです。許可していない通信は今までどおり通りません。
CIDR が重ならない 2 つの VPC を用意し、VPC ピアリング接続を作成・受諾する。両方のルートテーブルに相手 VPC 宛のルートを追加し、片方の VPC の EC2 から、もう片方の VPC の EC2 のプライベート IP アドレスへ HTTP で到達できることを確認する。
つくる構成
CIDR の異なる 2 つの VPC を、1 本の VPC ピアリング接続でつなぎます。それぞれにインターネットゲートウェイも付け、SSH 確認用にパブリック IP を使えるようにします。CIDR の数値は一例です。
※ 数値は一例です。2 つの VPC の CIDR は重ならないように自由に決めます。
要件
以下の要件を満たす構成を作り、ピアリング経由でのプライベート通信を確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | CIDR が重ならない 2 つの VPC を作成する（例：vpc-app＝10.0.0.0/16、vpc-data＝10.1.0.0/16）。それぞれにパブリックサブネットを 1 つ作る。 |
| 3 | 両方の VPC にインターネットゲートウェイをアタッチし、各パブリックサブネットがインターネットへ出られるようにする（SSH 確認用）。 |
| 4 | VPC ピアリング接続を作成する（リクエスター：vpc-app、アクセプター：vpc-data、同一アカウント・同一リージョン）。作成したリクエストを受諾し、状態を「Active」にする。 |
| 5 | 両方の VPC のルートテーブルに、相手 VPC の CIDR 宛のルートをピアリング接続に向けて追加する。 |
| 6 | セキュリティグループを設定する。vpc-data 側の EC2 は HTTP（80）を vpc-app の CIDR からのみ許可、vpc-app 側の EC2 は SSH（22）を「マイ IP」のみ許可する。各 VPC に EC2 を 1 台ずつ起動する（vpc-data 側はユーザーデータで Apache と目印ページを用意する）。 |
| 7 | vpc-app 側の EC2 に SSH 接続し、vpc-data 側の EC2 のプライベート IP アドレスに対する HTTP アクセスが成功することを確認する。 |
構築の進め方
「2 つの VPC を整える → ピアリング接続を作って受諾する → 両側のルートを書く → 通信を確認する」の順に進めます。
-
マネジメントコンソールにサインインし、リージョンを合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
2 つの VPC とパブリックサブネットを用意する
VPC を 2 つ作成します。CIDR が重ならないようにします（例：
vpc-app＝10.0.0.0/16、vpc-data＝10.1.0.0/16）。それぞれの VPC の中にパブリックサブネットを 1 つ作ります（例：10.0.1.0/24、10.1.1.0/24）。CIDR の重複は厳禁2 つの VPC の CIDR が重なっていると、ピアリングをしても一部のアドレスにしか正しく到達できなくなります。最初に範囲が重ならないことを確認しておきましょう。
-
両方の VPC をインターネットにつなげる
各 VPC にインターネットゲートウェイを作成・アタッチし、それぞれのパブリックサブネット用ルートテーブルに
0.0.0.0/0→ インターネットゲートウェイのルートを追加・関連付けます。両方のサブネットで「パブリック IPv4 自動割り当て」も有効にします。これは確認用の準備この手順自体は VPC ピアリングと直接関係しませんが、あとで
vpc-app側の EC2 に SSH するために必要です。 -
VPC ピアリング接続を作成する
VPC コンソール左メニュー「ピアリング接続」→「ピアリング接続を作成」を開きます。名前（例：
app-to-data）を付け、次のように指定します。VPC（リクエスター） vpc-appアカウント 自分の AWS アカウント リージョン このリージョン（東京） VPC（アクセプター） vpc-dataVPC（アクセプター）
vpc-data（10.1.0.0/16）接続したい、もう一方の VPCvpc-app（10.0.0.0/16）リクエスター自身の VPC。自分自身とはピアリングできない↳つなぎたい相手は vpc-data なので、こちらを選びます
作成直後は「pending-acceptance」作成しただけではまだ接続は使えません。同一アカウント内であっても、次のステップで受諾（Accept）する操作が必要です。
-
ピアリング接続のリクエストを受諾する
「ピアリング接続」一覧で、状態が
pending-acceptanceになっているapp-to-dataを選び、「アクション」→「リクエストを受諾」を実行します。状態が 「Active」に変われば接続そのものは完成です。 -
両方のルートテーブルに、相手 VPC 宛のルートを追加する
ピアリング接続を作っただけでは、まだ通信は通りません。両方の VPC のルートテーブルに、相手の CIDR 宛のルートを追加します。
vpc-app側のルートテーブル送信先 10.1.0.0/16→ ターゲット「Peering Connection」のapp-to-datavpc-data側のルートテーブル送信先 10.0.0.0/16→ ターゲット「Peering Connection」のapp-to-data片方だけでは不十分通信を行き来させるには、双方のルートテーブルにそれぞれ相手宛のルートが必要です。片方にしか追加しないと、行きか帰りの一方しか経路がない状態になり、思ったように通信できません。
-
セキュリティグループを設定し、EC2 を 1 台ずつ起動する
セキュリティグループを 2 つ用意します。
vpc-app側（例：app-sg）インバウンドで SSH（22）を「マイ IP」から許可 vpc-data側（例：data-sg）インバウンドで HTTP（80）を、ソース＝ vpc-appの CIDR（10.0.0.0/16）から許可各 VPC のパブリックサブネットに EC2 を 1 台ずつ起動します。
vpc-data側のユーザーデータには、次を貼り付けます。#!/bin/bash dnf install -y httpd systemctl enable --now httpd echo "<h1>vpc-data 側のサーバーです</h1>" > /var/www/html/index.htmlインターネット全体には開かないdata-sgのソースは0.0.0.0/0ではなくvpc-appの CIDR だけにします。これにより「ピアリングでつながった相手からだけアクセスできる」状態を作れます。 -
vpc-app 側の EC2 から、vpc-data 側の EC2 へ到達できることを確認する
ローカルのターミナルから
vpc-app側 EC2 のパブリック IP へ SSH します。ログインしたら、vpc-data側 EC2 のプライベート IP アドレスに対して HTTP アクセスします。# vpc-data 側 EC2 のプライベート IP に置き換えて実行 curl http://<vpc-data 側 EC2 のプライベート IP>vpc-data 側のサーバーですという応答が返れば、ピアリング経由のプライベート通信が成功しています。インターネットを経由していないこの通信は、どちらの EC2 もパブリック IP を使わず、VPC ピアリング接続を通じてプライベート IP アドレスのまま行われています。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。
「ピアリングは Active なのに、相手のサーバーに届かない」
確認したい点がいくつかあります。①両方の VPC のルートテーブルに、相手 CIDR 宛のルートを追加したか（片方だけでは不十分です）、②data-sg のインバウンドが vpc-app の CIDR から HTTP（80）を許可しているか、③ vpc-data 側 EC2 で Apache（httpd）が起動しているか——のいずれかが欠けていることが多いです。
「ピアリング接続を作ろうとするとエラーになる」
多くの場合、2 つの VPC の CIDR が重なっていることが原因です。CIDR が完全に同じでなくても、範囲の一部が重複しているだけでピアリングは正しく機能しません。2 つの VPC の CIDR ブロックを見比べて、重なりがないか確認してみてください。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。VPC コンソールを開いて、次を順に確かめましょう。
- 「ピアリング接続」一覧で、
app-to-dataの状態が「Active」になっている。 vpc-app側のルートテーブルに、送信先10.1.0.0/16・ターゲットがピアリング接続の行がある。vpc-data側のルートテーブルに、送信先10.0.0.0/16・ターゲットがピアリング接続の行がある。data-sgのインバウンドルールのソースがvpc-appの CIDR になっている（0.0.0.0/0ではない）。vpc-app側 EC2 からvpc-data側 EC2 のプライベート IP へのcurlが成功し、目印ページの内容が返る。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- ピアリング接続をした 2 つの VPC は、まるで 1 つの大きなネットワークになったように感じます。実際には何が変わって、何が変わっていないのでしょうか。
ヒント
変わったのは「ルートテーブルに相手 CIDR 宛の経路が増えたこと」と「セキュリティグループで許可した通信が通るようになったこと」だけです。VPC そのものが統合されたわけではない、という点から考えてみましょう。 - 今回
data-sgでは「vpc-appの CIDR 全体」からの通信を許可しました。これをもっと絞り込む（例：特定のセキュリティグループだけを許可する）と、何が変わるでしょうか。ヒント
CIDR 全体を許可すると、その VPC 内のどのリソースからでも通信できてしまいます。特定のセキュリティグループを指定できれば、そのセキュリティグループが付いたリソースだけに絞り込めます。「最小権限」という考え方から比べてみましょう。 - もし VPC が 3 つ、4 つと増えて、すべてを互いにつなぎたくなったら、VPC ピアリングだけで対応するとどうなるでしょうか。
ヒント
ピアリングは 1 対 1 の接続です。VPC の数が増えるほど、必要な接続の組み合わせの数も急に増えていきます。すべてを 1 対 1 でつなぐ以外に、中心となる「ハブ」を経由してまとめてつなぐ方式が AWS には別に用意されています。どんな名前のサービスか、調べてみましょう。
後片づけ
作ったものを片づけるところまでが一連の流れです。ルート → ピアリング接続 → サーバーの順に外していくと迷いにくいです。
- 両方のルートテーブルから、ピアリング宛のルートを削除する：
vpc-app側・vpc-data側、それぞれの「ルート」タブから削除。 - ピアリング接続を削除する：
app-to-dataを選び「アクション」→「ピアリング接続の削除」。 - EC2 を終了する：2 台とも「インスタンスの状態」→「インスタンスを終了」。
- インターネットゲートウェイをデタッチして削除する：両方の VPC で同様に行う。
- サブネットと VPC を削除する：このハンズオン用に作った
vpc-app/vpc-dataをそれぞれ削除する。
削除するのは自分で作った 2 つの VPC だけ
一覧には、最初から用意されている「デフォルト VPC」も並んでいます。間違えて削除しないよう、このハンズオンで作った vpc-app / vpc-data という名前のものだけを選んで削除してください。
コストに関する注意: VPC ピアリング接続自体は、今回のように同一リージョン内であれば料金はかかりません（異なるリージョン同士をつなぐ場合はデータ転送料金が発生しますが、今回の範囲には含まれません）。EC2 インスタンスは 2 台分の料金がかかります（無料利用枠対象タイプを使えば最小限に抑えられます）。VPC・サブネット・ルートテーブル・インターネットゲートウェイ・セキュリティグループ自体には料金はかかりません。使い終えたら、上の「後片づけ」を参考に整理しておきましょう。