パブリックアクセスを無効にした RDS エンドポイントへ別の閉域 VPC やオンプレミスから名前解決できるか整理する

閉域にあるパブリックアクセスが無効に設定された RDS へ、同じ閉域下にあるオンプレミスや別 VPC から接続したいというケースがあると思います。

この時注意しなければいけないのは、RDS は基本的にエンドポイント名で接続するサービスとなっていることです。

もちろん RDS のプライベートIP アドレスが分かるのであれば直接 IP アドレスで RDS に接続することはできます。しかし、フェールオーバーなどがあった際に元と同じ IP アドレスになることは保証されていません。

そのため、閉域の別 VPC やオンプレミスから RDS へ接続するためには、原則これらの環境から RDS のエンドポイント名を名前解決する必要があります。

そこで、閉域に閉じた環境下の VPC とオンプレミスにて、パブリックアクセスが無効になっている RDS のエンドポイント名を名前解決しようとした時の挙動について検証してみました。

最初に結論

1. amazonaws.com ドメインを名前解決できる環境であれば、パブリックアクセスが無効の RDS のエンドポイント名を名前解決してプライベート IP アドレスが返ってきます
2. つまり、閉域 VPC でもデフォルトの DNS サーバーである AmazonProvidedDNS で名前解決できる設定であれば、RDS のある VPC と別 VPC からであったとしてもエンドポイント名を名前解決できます
3. そのため、閉域オンプレミスからも、Route 53 インバウンドエンドポイントに RDS のエンドポイント名のドメインの名前解決クエリを条件付きフォワードすれば名前解決できます
4. 変形パターンとして、amazonaws.com への名前解決クエリのみインターネット上のパブリックな DNS へフォワードすることができれば名前解決できます

「パブリックアクセスを無効にした RDS のエンドポイントは同じ VPC 内からしか名前解決できず、かつパブリック DNS 側も応答を返さない」と思い込んでいたのですが、実際はエンドポイントが作られるとパブリックな DNS からも、AWS 内の AmazonProvidedDNS からも、同じプライベート IP アドレスが返ることが分かりました。

よって、VPC ピアリングや Transit Gateway (TGW) で RDS のあるプライベートサブネットとルーティングできる環境であれば、上記のいずれかのパターンで名前解決できれば RDS のエンドポイントへ接続することができます。

検証パターンの概要図など

今回の検証環境の概要は次の図のとおりです。

TGW を介して、RDS のある VPC、別の VPC、オンプレミスが相互にルーティング可能となっています。オンプレミス環境が参照する DNS リゾルバーサーバーは、Route 53 インバウンドエンドポイントと連携しています。

また、比較用として、TGW に接続しない独立したネットワークの VPC も一つ用意しました。

なお、RDS のエンドポイントやパブリックアクセスの状況は次の図のようになっています。

RDS と別の閉域 VPC から名前解決するパターン

次の 3 パターンのプライベートサブネットしか持たない閉域 VPC を用意し、それぞれの VPC の EC2 インスタンスから RDS のエンドポイント名を名前解決しました。結果、全てのパターンで同じプライベート IP アドレスが返ってきました。

接続元	RDS のサブネットとの経路	DNS 参照先	返ってくるレコード
RDS と同じ VPC	local 経由	AmazonProvidedDNS	プライベート IP アドレス
RDS と別 VPC	TGW 経由	AmazonProvidedDNS	プライベート IP アドレス
RDS と別 VPC	なし	AmazonProvidedDNS	プライベート IP アドレス

VPC が別であっても、また別の VPC との間でルーティングができなくても、AmazonProvidedDNS に名前解決要求ができれば RDS のエンドポイント名は名前解決できます。

なお、TGW で接続していない VPC で名前解決できていることからも明らかですが、TGW の DNS サポートの有効無効は RDS エンドポイントの名前解決の結果には全く影響しませんでした。

閉域のオンプレミスから名前解決するパターン

今度は閉域のオンプレミスから RDS のエンドポイント名を名前解決してみます。オンプレミスの DNS リゾルバーサーバーに、amazonaws.com ドメインの名前解決クエリを Route 53 インバウンドエンドポイントへ転送するように設定したところ、RDS エンドポイントの名前解決ができました。

Route 53 インバウンドエンドポイントは、名前解決クエリを内部で AmazonProvidedDNS へ転送しているので、理屈的には別 VPC から名前解決する時と変わらないことになるかと思います。

接続元	RDS のサブネットとの経路	DNS 参照先	返ってくるレコード
オンプレミス	TGW 経由	Route 53 インバウンドエンドポイント	プライベート IP アドレス

インターネットのパブリックな DNS にクエリできる環境から名前解決するパターン

このようなパターンを採用することはないと思いますが（名前解決できたとしてもそのプライベート IP アドレスにリーチャビリティがないケースがほとんどだと思うので）、一応検証した結果を残しておきます。

RDS のエンドポイント名をインターネット環境（インターネット経由でパブリックに名前解決できる環境）から名前解決したところ、普通にプライベート IP アドレスが返ってきます。

なので、閉域 DNS リゾルバーサーバーで、amazonaws.com への名前解決クエリだけ、インターネットへ抜けられる別の DNS サーバーに条件付きフォワードすれば、技術的には名前解決できることになります。

接続元	RDS のサブネットとの経路	DNS 参照先	返ってくるレコード
インターネット	なし	パブリックな DNS リゾルバーサーバー	プライベート IP アドレス

まとめ

パブリックアクセスを無効にした閉域の RDS のエンドポイントは、特に意識をしなくても、VPC 内のみならずインターネット側からでもプライベート IP アドレスに名前解決ができます。

ただし、RDS の作成時に自動で作られるエンドポイント名を接続先に直接採用するよりも、データベースの移行や構成変更に備えて、エンドポイント名に対して一意となる CNAME レコードを Route 53 プライベートホストゾーンに書いておいた方が良いと思います。