異なる AWS アカウント間での VPC ピアリング接続を試してみた～2025年冬
コーヒーが好きな emi です。最近はカフェインを控えています。
異なる AWS アカウント間での VPC ピアリング接続をする機会がありました。
難しいことではないのですが、既存の記事は古いものが多かったので、画面キャプチャも含め、改めて手順を記載します。
構成イメージ
以下のように異なる AWS アカウントそれぞれに VPC を作成し、その中にプライベートサブネットを一つ作成します。VPC 同士を VPC Peering で接続して、通信できるようにルートテーブルを編集します。
| 項目 | AWS アカウント：WorkloadsTest1 | AWS アカウント：WorkloadsTest3 |
|---|---|---|
| VPC CIDR | 192.168.0.0/24 | 172.16.0.0/24 |
1. VPC の作成
今回はマネジメントコンソール上からサクッと作成しました。
▼ AWS アカウント：WorkloadsTest1 は赤枠で表現します。
- プライベートサブネット CIDR：192.168.0.0/28
S3 ゲートウェイエンドポイントも作成しましたが、なくても良いです。
▼ AWS アカウント：WorkloadsTest3 は青枠で表現します。
- プライベートサブネット CIDR：172.16.0.0/28
2. VPC ピアリングの作成
WorkloadsTest1 側のアカウント作業
VPC ピアリングの作成は WorkloadsTest1 側のアカウントで行います。
VPC コンソール左のナビゲーションペインから「ピアリング接続を作成」に進みます。
- 「リクエスタ」は、VPC ピアリングを作成する方のアカウントが該当します。今回は WorkloadsTest1 側のことです。
- 「アクセプタ」は、VPC ピアリング接続のリクエストを受け付けて承認する側を指します。今回は WorkloadsTest3 側のことです。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 名前 | peer-test | 任意の名前 |
| VPC ID（リクエスタ） | vpc-xxxxxxxxxxxxxxxxx | WorkloadsTest1 側で作成した VPC の VPC ID |
| アカウント | 別のアカウント | |
| リージョン | このリージョン | |
| VPC ID（アクセプタ） | vpc-yyyyyyyyyyyyyyyyy | WorkloadsTest3 側で作成した VPC の VPC ID |
ピアリング接続の作成ができると以下のような表示になります。
WorkloadsTest3 側のアカウント作業
ここから WorkloadsTest3 側のアカウントに切り替えて作業していきます。こちらがアクセプタになります。
VPC コンソールでピアリング接続を確認すると、ステータスが「承認の保留中」のピアリング接続が見えるようになっています。
ピアリング接続の詳細を開くと、7 日間以内に承認する必要があると表示されています。
[アクション] - [リクエストを承認] をクリックします。
リクエストを承認します。
承認されました。これで VPC ピアリング接続の作成は完了です。次は「ルートテーブルを今すぐ変更」をクリックしてルートテーブルを編集していきます。
3. ルートテーブルを編集
WorkloadsTest3 側のアカウント作業
このまま WorkloadsTest3 側のアカウントで作業を続けます。
ルートテーブルの画面に遷移しますので、1 つだけ作成済みのプライベートサブネットに関連付けられたルートテーブルを選択し、ルートを編集します。
通信先は WorkloadsTest1 側のアカウントで作成した VPC の CIDR（今回は 192.168.0.0/24）を入力します。
ターゲットは「ピアリング接続」を選択します。
候補に作成済みのピアリング接続が出てきますので、選択してルートの変更を保存します。
WorkloadsTest1 側のアカウントの VPC へのルートが作成できました。
WorkloadsTest1 側のアカウント作業
WorkloadsTest1 側のアカウントに切り替えます。
ピアリング接続画面を見ると、ステータスが Active になっていますね。
WorkloadsTest1 側でもルートを編集します。
1 つだけ作成済みのプライベートサブネットに関連付けられたルートテーブルを開き、ルートを編集します。
通信先は WorkloadsTest3 側のアカウントで作成した VPC の CIDR（今回は 172.16.0.0/24）を入力します。
ターゲットは「ピアリング接続」を選択します。
候補に作成済みのピアリング接続が出てきますので、選択してルートの変更を保存します。
WorkloadsTest3 側のアカウントの VPC へのルートが作成できました。
さて、ここまででピアリング接続の作成と通信のための設定変更は完了です。
4. EC2 インスタンスを立てて疎通確認する
EC2 インスタンスをたてて、ピアリング接続した VPC 間で疎通できるか確認してみます。今回は簡易的に Ping で疎通確認します。
以下のような構成で EC2 やセキュリティグループを作成します。
プライベートサブネットの EC2 インスタンスに Systemsn Manager セッションマネージャーで接続するために、VPC エンドポイントと VPC エンドポイント用のセキュリティグループも作成します。
WorkloadsTest1 側の EC2 のセキュリティグループ
- インバウンドルール
| タイプ | プロトコル | ポート番号 | ソース | 説明 |
|---|---|---|---|---|
| すべての ICMP - IPv4 | ICMP | すべて | 172.16.0.0/24 | from WorkloadsTest3-vpc |
- アウトバウンドルール：すべて許可
EC2 は Amazon Linux 2023 を作成し、SSM セッションマネージャー接続のために IAM ポリシー AmazonSSMManagedInstanceCore が付与された IAM ロールをアタッチしました。
プライベート IP 192.168.0.13 をメモしておきます。
VPC エンドポイントと VPC エンドポイント用のセキュリティグループは以下ブログの CloudFormation で展開しました。
同様に WorkloadsTest3 側でも EC2 インスタンス、セキュリティグループ、VPC エンドポイントを作成します。
WorkloadsTest3 側の EC2 のセキュリティグループ
- インバウンドルール
| タイプ | プロトコル | ポート番号 | ソース | 説明 |
|---|---|---|---|---|
| すべての ICMP - IPv4 | ICMP | すべて | 192.168.0.0/24 | from WorkloadsTest1-vpc |
- アウトバウンドルール：すべて許可
EC２ インスタンスは以下のように作成しました。プライベート IP 172.16.0.12 をメモしておきます。
VPC エンドポイントも以下のように作成しました。
さて、それでは WorkloadsTest1 側の EC2 インスタンスにセッションマネージャーで接続し、WorkloadsTest3 側の EC2 インスタンスに向けて ping を打ってみます。
実行コマンド
ping 172.16.0.12
▼実行結果
sh-5.2$ ping 172.16.0.12
PING 172.16.0.12 (172.16.0.12) 56(84) bytes of data.
64 bytes from 172.16.0.12: icmp_seq=1 ttl=127 time=0.608 ms
64 bytes from 172.16.0.12: icmp_seq=2 ttl=127 time=0.252 ms
64 bytes from 172.16.0.12: icmp_seq=3 ttl=127 time=0.356 ms
64 bytes from 172.16.0.12: icmp_seq=4 ttl=127 time=0.237 ms
64 bytes from 172.16.0.12: icmp_seq=5 ttl=127 time=0.221 ms
64 bytes from 172.16.0.12: icmp_seq=6 ttl=127 time=0.283 ms
64 bytes from 172.16.0.12: icmp_seq=7 ttl=127 time=0.246 ms
^C
--- 172.16.0.12 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6257ms
rtt min/avg/max/mdev = 0.221/0.314/0.608/0.126 ms
sh-5.2$
疎通できています！
同様に WorkloadsTest3 側の EC2 インスタンスにセッションマネージャーで接続し、WorkloadsTest1 側の EC2 インスタンスに向けて ping を打ってみます。
実行コマンド
ping 192.168.0.13
▼実行結果
sh-5.2$ ping 192.168.0.13
PING 192.168.0.13 (192.168.0.13) 56(84) bytes of data.
64 bytes from 192.168.0.13: icmp_seq=1 ttl=127 time=0.219 ms
64 bytes from 192.168.0.13: icmp_seq=2 ttl=127 time=0.225 ms
64 bytes from 192.168.0.13: icmp_seq=3 ttl=127 time=0.218 ms
64 bytes from 192.168.0.13: icmp_seq=4 ttl=127 time=0.228 ms
64 bytes from 192.168.0.13: icmp_seq=5 ttl=127 time=0.220 ms
64 bytes from 192.168.0.13: icmp_seq=6 ttl=127 time=0.213 ms
64 bytes from 192.168.0.13: icmp_seq=7 ttl=127 time=0.206 ms
^C
--- 192.168.0.13 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6260ms
rtt min/avg/max/mdev = 0.206/0.218/0.228/0.006 ms
sh-5.2$
こちらも疎通できました！
余談
ピアリング接続の画面下部を見ると、「アクセプタ VPC がリクエスタ VPC 内のホストの DNS をプライベート IP アドレスに解決できるように許可」が「無効」になっています。
ちょっと気になってプライベート IP DNS 名で ping を打ってみましたが、届きますし、名前解決もできました。
sh-5.2$ hostname
ip-192-168-0-13.ap-northeast-1.compute.internal
sh-5.2$ ifconfig
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
inet 192.168.0.13 netmask 255.255.255.240 broadcast 192.168.0.15
inet6 fe80::49f:83ff:fe76:ff69 prefixlen 64 scopeid 0x20<link>
ether 06:9f:83:76:ff:69 txqueuelen 1000 (Ethernet)
RX packets 22776 bytes 54114156 (51.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17582 bytes 1991895 (1.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 12 bytes 1020 (1020.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12 bytes 1020 (1020.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
sh-5.2$
sh-5.2$ ping ip-172-16-0-12.ap-northeast-1.compute.internal
PING ip-172-16-0-12.ap-northeast-1.compute.internal (172.16.0.12) 56(84) bytes of data.
64 bytes from ip-172-16-0-12.ap-northeast-1.compute.internal (172.16.0.12): icmp_seq=1 ttl=127 time=0.172 ms
64 bytes from ip-172-16-0-12.ap-northeast-1.compute.internal (172.16.0.12): icmp_seq=2 ttl=127 time=0.240 ms
64 bytes from ip-172-16-0-12.ap-northeast-1.compute.internal (172.16.0.12): icmp_seq=3 ttl=127 time=0.223 ms
64 bytes from ip-172-16-0-12.ap-northeast-1.compute.internal (172.16.0.12): icmp_seq=4 ttl=127 time=0.251 ms
^C
--- ip-172-16-0-12.ap-northeast-1.compute.internal ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3050ms
rtt min/avg/max/mdev = 0.172/0.221/0.251/0.030 ms
sh-5.2$
sh-5.2$ nslookup ip-172-16-0-12.ap-northeast-1.compute.internal
Server: 192.168.0.2
Address: 192.168.0.2#53
Non-authoritative answer:
Name: ip-172-16-0-12.ap-northeast-1.compute.internal
Address: 172.16.0.12
以下ドキュメントを見ると、
DNS 解決が無効 (デフォルト）
パブリック IPv4 DNS ホスト名は、インスタンスのパブリック IPv4 アドレスに解決されます。
DNS 解決が有効
パブリック IPv4 DNS ホスト名は、インスタンスのプライベート IPv4 アドレスに解決されます。
つまり、VPC Peering の「DNS 設定」は、パブリック DNS ホスト名の解決方法にのみ影響するということでした。
プライベート IP DNS 名が解決できる理由は、AmazonProvidedDNS（VPC の .2 アドレスで予約された DNS リゾルバー）が使われるためです。
おわりに
本記事への質問やご要望については画面下部のお問い合わせ「DevelopersIOへのご意見」からご連絡ください。記事に関してお問い合わせいただけます。
参考
