パブリックアクセスを有効にした Aurora (RDS) に閉域網から接続したい

パブリックアクセスを有効にした Aurora / RDS に閉域網経由で接続しようとした際の、ハマったところと、その解決方法をまとめました。
2020.04.30

みなさま Xin chao !

 

Aurora または RDS で「パブリックアクセス (Public accessibility)」を有効にした状態で使用したことはありますか?

インターネット側から到達可能なパブリックサブネットに、「パブリックアクセス」を有効にした Aurora / RDS を起動し、セキュリティグループ等で接続を許可すると、インターネット側から Aurora / RDS のデータベースに接続することが可能です。

ちょっとしたテスト環境などで、手元の端末からサクっと直接データベースに接続したい時に便利ですが、自分ではこれまでテスト環境以外で使う場面はありませんでした。

今回、運用環境で使う機会があり、かつ、ハマった部分がありましたので、備忘録として書き残しておこうと思います。

今回の構成

外部システム (=SaaS 的な仕組み) と連携させるために、外部システムから直接 PostgreSQL データベースにアクセスさせる必要があります。 外部システムは Aurora への接続をサポートしているため、パブリックアクセスを有効にした Aurora PostgreSQL インスタンスで実現できると考えました。

また、社内のデータとも連携させるために、オンプレミス環境、および、既存の EC2 インスタンスからも PostgreSQL データベースにアクセスする必要があったため、以下のような構成になりました。

オンプレミス環境には、インターネットアクセス可能な経路がありますが、PostgreSQL データベース接続に使用されるポート (既定では 5432 / TCP) は許可されておらず、その設定を変更することはできない状況です。

また、Aurora とは別の VPC 上にある EC2 はインターネットにアクセス可能な経路がありません。

したがって、オンプレミス環境からは Direct Connect または Site to Site VPN 経由で、別 VPC からは VPC Peering 経由で、といった閉域網経由で、それぞれ Aurora PostgreSQL データベースへの接続を行うことになります。

以上を踏まえて Aurora PostgreSQL データベースへの接続パターンを整理すると、以下のようになります。

  1. 外部システム → (インターネット経由) → Aurora   ※ 黒線の接続
  2. 同一 VPC 上の EC2 → Aurora   ※ 青線の接続
  3. 別 VPC 上の EC2 → (VPC Peering 経由) → Aurora   ※ 黄線の接続
  4. オンプレミス環境 → (Direct Connect または Site to Site VPN 経由) → Aurora   ※ 赤線の接続

勘の良い方は、そろそろハマリポイントにお気づきでしょうか (笑)。

ハマったところ

先に白状すると、接続パターンの 3. と 4. です。

まず前提として、Aurora / RDS のインスタンスの IP アドレスは変わる可能性があるため、データベースへの接続は DNS 名で行うことが推奨されています。

ただし、DB インスタンスに接続するときは DNS 名を使用することを強くお勧めします。基になる IP アドレスは、フェイルオーバー中に変わる可能性があります。

VPC の DB インスタンスの使用 - Amazon Relational Database Service (RDS) ユーザーガイド より抜粋

パブリックアクセスを有効にした Aurora / RDS の場合、インスタンスと同一の VPC 内を除き、DNS 名はパブリック IP アドレスに名前解決されます。

つまり、接続パターン 3. と 4. においても、パブリック IP アドレスを接続先として、インターネット経由で Aurora / RDS インスタンスに接続しようとしてしまいます (当然ながらインターネット経由では接続できません)。

接続パターン 2. では、DNS 名がプライベート IP アドレスで名前解決され Aurora / RDS インスタンスに問題なく接続できることから、接続パターン 3. と 4. において閉域網 (=Direct Connect, Site to Site VPN, VPC Peering など) 経由で接続するには、DNS 名をプライベート IP アドレスで名前解決させる必要がある、ということになります。

  • パブリック IP アドレスで名前解決 ・・・ インターネット経由
  • プライベート IP アドレスで名前解決 ・・・ 閉域網経由

それぞれの接続パターンで確かめてみた

以下のようなテスト環境を用意して、Aurora の DNS 名がどのように名前解決されるのか、それぞれの接続パターンで実際に確認してみます。

1. 外部システム → (インターネット経由) → Aurora

パブリックアクセスを有効にした Aurora の DNS 名はパブリック IP アドレスで名前解決されるため、インターネット経由で Aurora に接続するこの接続パターンは特に問題はありません。

外部システムの接続元パブリック IP からの接続を許可するようにセキュリティグループ・NACL が設定されていれば、接続できます。

2. 同一 VPC 上の EC2 → Aurora

パブリックアクセスを有効にしても、Aurora と同一の VPC 内では Route 53 Resolver (Amazon Provided DNS) によって、DNS 名がプライベート IP アドレスで名前解決されるため、この接続パターンでも特に問題はありません。

接続元の EC2 からの接続を許可するようにセキュリティグループ・NACL が設定されていれば、接続できます。

3. 別 VPC 上の EC2 → (VPC Peering 経由) → Aurora

ここからが問題です。

既定の状態では、Aurora の VPC とは別の VPC 内の Route 53 Resolver では、Aurora の DNS 名がパブリック IP アドレスで名前解決されてしまうため、インターネットへのアクセス経路がない EC2 からは Aurora に接続することができません。

また、Route 53 Resolver は同一 VPC 内からの問い合わせに対してのみ応答を返すため、Aurora の VPC 内の Route 53 Resolver を別 VPC 上の EC2 が使用する DNS サーバーとして指定することもできません。

Aurora の DNS 名をプライベート IP アドレスで名前解決させる方法がないか調べたところ、ピッタリな情報がありました。

この情報にもとづき、VPC の DNS ホスト名を有効化したうえで VPC Peering の DNS 解決を有効にしたところ、別 VPC 上の EC2 上で、パブリックアクセスを有効にした Aurora の DNS 名がプライベート IP アドレスで名前解決されることを確認できました。

(変更前)

(変更後)

4. オンプレミス環境 → (Direct Connect または Site to Site VPN 経由) → Aurora

最後がこの接続パターンです。

DNS 名がパブリック IP アドレスで名前解決されてしまうため、インターネットへのアクセス経路を介して Aurora に接続しようとしますが、PostgreSQL データベースへの接続に使用する通信が許可されていないため、Aurora に接続することができません。

閉域接続されているという点では接続パターン 3. に似ているとも言えますが、(テスト環境ではなく実際の環境では) VPC Peering ではないため接続パターン 3. で使用した DNS 解決は使えません。 また、接続パターン 3. でも書いた通り、Route 53 Resolver は同一 VPC 内からの問い合わせに対してのみ応答を返すため、Aurora の VPC 内の Route 53 Resolver をフォワーダ先としてオンプレミス環境の DNS サーバーを設定することもできません。

以下のブログを見ると、オンプレミス環境から Route 53 Resolver for Hybrid Clouds (Resolver Endpoint) を介して、Route 53 Resolver で名前解決を行うことが出来そうです。

しかし耐障害性も考慮してマルチ AZ 構成で 2 つのインバウンドエンドポイントを用意すると、次の利用料がかかります (本ブログ執筆時点の利用料金, 別途クエリ料金が課金されます)。

0.125 USD × 2 ENI = 0.25 USD / 時間 = 180 USD / 30 日間

Route 53 リゾルバー - Amazon Route 53 料金表

 

もう少し安価に実現できないものかと探したところ、Route 53 Resolver for Hybrid Clouds が登場するより前の古い情報になりますが、Directory Service を使うことでオンプレミス環境から VPC 内の名前解決が実現できそうなことが分かりました。

Simple AD (スモール) であれば利用料金が Route 53 Resolver for Hybrid Clouds を使った場合の 3 分の 1 以下になります (本ブログ執筆時点の利用料金, 東京リージョンの場合)。

0.08 USD / 時間 = 57.6 USD / 30 日間

その他のディレクトリタイプ の料金表 - AWS Directory Service 料金表

 

Directory Service はマルチ AZ 構成が基本であり、かつ AWS のマネージドサービスであるため運用負荷も最小限で済みます。

今回の構成の場合、Aurora の名前解決が行われる頻度はそれほど高くないため、Simple AD (スモール) を使用することにしました。

 

Aurora と同一の VPC 内に Simple AD を構築し、オンプレミス環境の DNS サーバーの条件付きフォワーダー設定で、Aurora エンドポイントについてのみ Simple AD の DNS サーバーにフォワードするよう設定します。 オンプレミス環境からの接続先 VPC が 1 つのみであれば、amazonaws.com 全体を Simple AD にフォワードさせることも可能です。

Simple AD の DNS サーバーアドレスは、AWS マネジメントコンソールで確認することが可能です。

条件付きフォワーダーを設定しても、Aurora の DNS 名がパブリック IP アドレスで名前解決されてしまう場合、DNS サーバーでキャッシュの消去をお試しください。

(DNS フォワーダー設定前)

(DNS フォワーダー設定後)

まとめ

パブリックアクセスを有効にした Aurora / RDS を使用する場合、何も対処を行わないと、接続先として指定する DNS 名がパブリック IP アドレスで名前解決されるため、Aurora / RDS が稼働している VPC と閉域網 (Direct Connect, Site to Site VPN, VPC Peering など) で接続されていても、インターネット経由で接続しようとしてしまいます。

しかし、DNS 名をプライベート IP アドレスで名前解決できるようにすることで、閉域網経由で接続させることが可能です。

あわせて読みたい

20190313 AWS Black Belt Online Seminar Amazon VPC Basic - Amazon Web Services Japan

[レポート]Deep dive ハイブリッドクラウドでのDNS #NET410 #reinvent - Developers.IO