VPCの外部からRDSインスタンスに接続できません（エラー2003（HY000）MySQLサーバーに接続できません）

VPCを作成し、その中にRDSインスタンスを作成しました。RDSインスタンスは一般公開されており、その設定は次のとおりです。

RDSインスタンスに接続されたセキュリティグループは、すべてのトラフィックを受け入れます。

セキュリティグループ設定

私のネットワークACLはすべて、すべてのトラフィックを受け入れます。ただし、VPCの外部のマシンからインスタンスにアクセスすることはできません。次のエラーが表示されます。

    root@vps151014:~# mysql -h mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com -P 3306 -u skullberry -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com' (110)

VPC内のEC2から同じコマンドを実行すると、接続できます。私はいくつかのマシンから接続しようとしましたが、それらはすべてファイアウォールなし（ポート3306が開いている）でした。

私は明らかに何かが欠けていますが、すべてが正しく構成されているようです。何が問題なのでしょうか？

— ダゼドバイパー
ソース

(110)エラーメッセージの意味で「接続がタイムアウトし、」これは間違いなく、これは、IP接続の問題です。RDSインスタンスが2つのサブネットに関連付けられていることが表示されます。VPCコンソールでは、これら2つのサブネットのデフォルトルートは何ですか？「igw-xxxxxxxx」ですか、それとも「i-xxxxxxxx」ですか？

— マイケル-sqlbot

両方のサブネットは、VPCのメインルートテーブルに暗黙的に関連付けられています。

— -dazedviper

すべての発信トラフィックをVPCのインターネットゲートウェイにルーティングするカスタムルートテーブルに両方のサブネットを明示的に関連付けても、違いはまったくありません。

— dazedviper

まあ、それは残念です。「igw」へのデフォルトのルートは、最も可能性の低い行方不明のピースのように見えました...そして、いずれにしても、これが機能するために必要なはずです。それに応じてサブネットの構成を変更した後、VPCがバックグラウンドで自身を再構成するのに十分な時間を与えたと仮定すると、私は考えを失います。

— マイケル-sqlbot

ああ、すべてのIPアドレスに必要なブロックは0.0.0.0/0です。答えを投稿します。

— マイケル-sqlbot

回答:

「パブリック」（インターネット）アクセス可能なVPCのRDSインスタンスの場合、接続するサブネットはすべて、「プライベート」ではなく「パブリック」である必要があります-VPCのサブネット。

パブリックサブネットは、本質的に、インターネットへのルートとして、または少なくともアクセスする必要があるインターネットの宛先へのルートとして、インターネットゲートウェイオブジェクト（igw-xxxxxxxx）を持つサブネットとして定義されます。通常、これはの宛先アドレスです0.0.0.0/0。パブリックサブネットは、パブリックIPアドレスが関連付けられているインスタンス（RDSを含む）で使用する必要があります。パブリックIPアドレスを持たないインスタンスには使用しないでください。プライベートアドレスは変換なしではインターネット上で機能しません。

一方、プライベートサブネットには、別のEC2インスタンス（通常はNATインスタンス）を介してインターネットの宛先に到達するようにルーティングテーブルが構成されています。これは、そのサブネットに関連付けられたVPCルートテーブルに、「igw」ではなくi-xxxxxxxxとして表示されます。そのマシン（それ自体は、実際にルートの宛先として機能するサブネットとは異なるサブネット上にあります）はトランスレーターとして機能し、プライベートIPのみのインスタンスがNATマシンのパブリックを使用して透過的にアウトバウンドインターネットリクエストを行うことができますインターネットのニーズに応えるIP。パブリックIPアドレスを持つインスタンスは、プライベートサブネットに接続されている場合、インターネットと適切に対話できません。

特定の場合、ここでは、RDSインスタンスに関連付けられたサブネットは、プライベートルートまたはパブリックサブネットとして単純に分類できるものとして実際に構成されていません。これは、サブネットにデフォルトルートがまったくないためです。「igw」オブジェクトを介してデフォルトルートを追加するか、OPのように、接続が必要なインターネットIPアドレスへの静的ルートをサブネットのVPCルートテーブルに追加すると、接続の問題が修正されます。

ただし...同様の問題が発生した場合、サブネット上で既に正常に動作しているものが他にない場合を除き、ルートテーブルを単に変更したり、新しいルートテーブルを構築してサブネットを関連付けたりすることはできません。既存の接続が切断されることが予想されます。その場合の正しいコースは、適切なルートテーブルエントリを使用して、異なるサブネット上のインスタンスをプロビジョニングすることです。

VPCをセットアップするときは、サブネットの役割を明確に定義し、VPCが最初にコミッションされたときに必要なルートを完全にプロビジョニングすることが理想的です。また、VPC「LAN」全体がソフトウェア定義のネットワークであることを覚えておくことも重要です。ルーターがボトルネックになる可能性があり、同じサブネット上にトラフィックの多いマシンを配置するのが賢明な物理ネットワークとは異なり、サブネットを越えるトラフィックはVPCでパフォーマンス上のデメリットはありません。マシンは、マシンのIPアドレス指定のニーズに適したサブネット（パブリックアドレス、パブリックサブネット）に配置する必要があります。パブリックアドレスなし、プライベートサブネット。

VPCでのプライベート/パブリックサブネットのロジスティクスの詳細については、「VPCでプライベートサブネットが必要な理由（スタックオーバーフロー時）」を参照してください。

— マイケル-sqlbot
ソース

これにはすでに大きな答えがありますが、「パブリックにアクセス可能」オプションを選択すると、AWSがパブリックサブネットを作成します。むしろ、私にとって問題はデフォルトのVPCセキュリティグループでした。セキュリティグループではなく、ネットワークACLルールを見ていました。（RDSで「パブリックにアクセス可能」オプションを選択すると、セキュリティグループが追加されますが、インバウンドルールは自動的に追加されません。）

[RDS]をクリックし、セキュリティグループを特定してクリックします。次に、「インバウンドルール」の下にポート3306を追加し、接続するIPV4アドレスxxxx / 32（またはインターネット全体を接続する場合は0.0.0.0/32-ただし注意が必要）を追加します。

— チャーリー・ダルサス
ソース

また、接続しているネットワークがポート3306での別のサーバーへの接続をブロックしていないことを確認してください。これは、企業ネットワークに接続したときのことです。

— gary69
ソース