本記事では、VPCピアリングで別VPCのRDSにプライベートで接続する方法を記載します。単純にVPCピアリングを設定するだけで良さそうに見えますが、パブリックアクセシビリティが有効になっている場合、少し詰まった点があったため、記録しておきます。
そもそもVPCピアリングとは
VPCピアリングとは、2つのVPC(別アカウント/別リージョンも可)を接続することで、別VPCのリソースに対してもプライベート接続可能なようにする機能のことです。VPC間でインターネットを経由した通信を行いたくない(行えない)場合、この機能の利用が最有力候補となります。
ただし、VPCピアリングの作成条件には制限もあるため、事前に確認する必要があります。特に、VPCのCIDRが重複する場合には作成できないというのが、最も大きな制限事項です。
詳しくは、以下をご確認ください。
検証環境の構成
2つのCIDRが異なるVPCをVPCピアリングを使って接続しています。VPCにはパブリックサブネットを作成し、接続元のEC2と接続先のRDSを配置する構成です。EC2もRDSもパブリックIPを持っています。
この場合、何もしなければ、EC2からRDSに対する接続はインターネットを経由して行われます。RDSのパブリックアクセシビリティが有効になっているため、エンドポイント名がパブリックIPアドレスに解決されるためです。
ただし、VPCエンドポイントを導入することで、パブリックアクセシビリティが有効になっているRDSのエンドポイントをプライベートIPアドレスに解決することができるため、プライベートでの接続が可能になります。
検証環境の構築
VPCの設定
冒頭で「パブリックアクセシビリティが有効になっている場合、少し詰まった点があった」と記載しましたが、それがここです。この設定を忘れてしまうと、パブリックアクセシビリティが有効になっているRDSのエンドポイント名をプライベートIPに解決することができません。
その設定とは何かと言いますと、VPCのDNS 解決およびDNS ホスト名を有効にするという点です。また、この設定は、VPCピアリングを行う両方のVPCで行う必要がある点に注意が必要です。
上図の通り、執筆時点では、VPCのデフォルト設定値として、次のような値が利用されています。デフォルトから変更しない場合はDNS ホスト名が無効となっているのです。
- DNS 解決
- 有効
- DNS ホスト名
- 無効
このままだと、別VPCのRDSのエンドポイントをプライベートIPアドレスに解決することができないため、DNS ホスト名をデフォルト値から変更していきます。まずは、該当のVPCを選択し、アクション ＞ DNS ホスト名の編集をクリックします。
DNS ホスト名の有効化にチェックを付け、保存をクリックします。
該当のVPCについて、DNS ホスト名が有効となっていることを確認します。もし、DNS 解決が無効になっている場合は、同じようにしてアクション ＞ DNS 解決の編集から設定することができます。
VPCピアリングの作成
VPCピアリング接続の作成
ダッシュボードからピアリング接続を選択し、ピアリング接続の作成をクリックします。
ここでは、次のように設定しています。重要なのは、 VPC (リクエスタ)には接続元を、VPC (アクセプタ)には接続先を指定する点です。 今回の構成だと、VPC (リクエスタ)をVPC-Aに、VPC (アクセプタ)をVPC-Bにします。指定後、ピアリング接続の作成をクリックします。
- ピアリング接続ネームタグ
- test-peering
- VPC (リクエスタ)
- VPC-A
- アカウント
- 自分のアカウント
- リージョン
- このリージョン (ap-northeast-1)
- VPC (アクセプタ)
- VPC-B
VPCピアリングの承諾
上記で作成したVPCピアリング接続ですが、承認作業を経ていないため、承諾の保留中となり利用することができません。
該当のVPCピアリングを選択し、アクション ＞ リクエストの承諾をクリックすることで、このVPCピアリングがアクティブとなります。
VPCピアリングのDNS設定
VPCだけでなく、VPCピアリング自体でもDNSにまつわる設定を行う必要があります。デフォルトだとリクエスタ VPC からプライベート IP への DNS 解決が無効となっているためです。
設定の変更のために、アクション ＞ DNS 設定の編集からアクセプタ DNS 解決にチェックを入れて保存します。
ルートテーブルの編集
続いて、VPCピアリングを利用したいサブネットのルートテーブルをアクション ＞ ルートの編集から編集します。接続元と先の両方で編集します。今回の構成で言うと、PublicSubnetAおよびPublicSubnetBサブネットが利用している両方のルートテーブルを編集します。
それぞれのルートテーブルでは、通信先、つまり、VPCピアリング先のIPアドレスをVPCピアリングに向けるようなルートを追加します。今回はピアリング先のCIDR単位で指定します。片方だけの設定ですと、戻りの通信が迷子になりますので、両方指定する必要があります。
名前解決の確認
最後に、名前解決の確認を行います。VPCピアリング元から、VPCピアリング先のRDSのエンドポイントを解決してみます。無事にプライベートIPアドレスに解決できたことを確認できました。
プライベートIPアドレスへの解決
[ec2-user@ip-10-10-0-104 ~]$ nslookup testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server: 10.10.0.2
Address: 10.10.0.2#53
Non-authoritative answer:
testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com canonical name = ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com.
Name: ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com
Address: 10.20.0.218また、RDSへの接続時にも、きちんとプライベートIPアドレスを利用していることが確認できます。
RDSへの接続
[ec2-user@ip-10-10-0-104 ~]$ netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 10.10.0.104:44472 10.20.0.218:5432 TIME_WAIT
tcp 0 252 10.10.0.104:22 xx.xx.xx.xx:65333 ESTABLISHED
tcp 0 0 10.10.0.104:44476 10.20.0.218:5432 ESTABLISHED
tcp 0 0 10.10.0.104:22 xx.xx.xx.xx:65288 ESTABLISHED
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 :::22 :::* LISTENちなみに、VPCのDNS ホスト名を無効にした状態だと、次のように、グローバルIPアドレスがエンドポイントから解決されます。
パブリックIPアドレスへの接続
[ec2-user@ip-10-10-0-104 ~]$ nslookup testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server: 10.10.0.2
Address: 10.10.0.2#53
Non-authoritative answer:
testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com canonical name = ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com.
Name: ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com
Address: 18.176.xx.xx最後に
VPCピアリングでパブリックアクセシビリティが有効になっているRDSに対してプライベートIPアドレスで接続するためには、接続元先のVPC自体でDNS 解決およびDNS ホスト名を有効にする必要があるという記事でした。
そもそも、RDSをパブリックサブネットに配置するパターンは多くないかもしれませんが、そのような構成を取らざるを得ない時に、役に立つ構成かもしれません。
コメント