EC2インスタンスからRDSインスタンスに接続できません
EC2インスタンスi-78a8df00から、RDSインスタンスmysql。************。us-east-1.rds.amazonaws.comに接続しようとしています。どちらも米国東部地域にあります。 EC2インスタンスのセキュリティグループ（sg-********）をRDSセキュリティグループに追加しましたが、役に立ちませんでした。このコマンドを実行するとタイムアウトになるため、ファイアウォール/ DNSの問題のようです。
ubuntu@ip-10-195-189-237:~$ mysql -h mysql.************.us-east-1.rds.amazonaws.com
エラー2003（HY000）：「mysql。************。us-east-1.rds.amazonaws.com」のMySQLサーバーに接続できません（110）
上記と同じ行を使用して、ローカルマシンからRDSインスタンスに正常に接続できます。さまざまなフォーラムソリューションを試しましたが、解決しません。
前回の投稿から今回の投稿までの間に、AmazonはDNSルーティングの問題を修正したようです。
新しいEC2インスタンスをスピンしたときに同様の問題が発生しましたが、RDSインスタンスのポート3306への接続が許可されている受信IPアドレスのRDSセキュリティグループの設定を変更しませんでした。
混乱を招くビットは、セキュリティグループと呼ばれるRDSダッシュボードのオプションでした。問題を解決するためにそれを必要としません。
本当に必要なのは、RDSインスタンスのリストに移動し、接続しようとしているインスタンスをクリックしてから、中央のタブをクリックして、Security and Networkを見つけますセクションを開き、セキュリティグループの名前をクリックします。
これにより、セキュリティグループの詳細を含む新しいブラウザタブまたはウィンドウが開きます。下部にあるいくつかのタブを見つけ、Inboundタブを選択して、Editボタンをクリックします。
値をEC2インスタンスまたはIPv4 CIDRブロックのIPアドレスに変更します。
174.33.0.0/16
この値を取得するには、インスタンスにsshしてifconfigを実行するか、ブラウザーでEC2 Managerを実行してPrivate IPsインスタンスの詳細。
RDSまたはRedShiftに接続しようとすると、同様の問題が発生する可能性がある人向けの追加情報：
1）セキュリティグループを確認する
RDSインスタンスのセキュリティグループが、ソースサーバーが属するセキュリティグループ（またはAWSの外部の場合は直接追加されたIP）からのアクセスを許可することを確認します。確認する必要があるセキュリティグループは、RDSコンソールUIのRDSインスタンス属性で指定されているものです（「セキュリティグループ」という名前）。
[〜＃〜] note [〜＃〜]：データベースセキュリティグループはAWS EC2セキュリティグループとは異なる場合があります。 RDSインスタンスがクラシック/パブリックEC2にある場合は、RDS UIの「データベースセキュリティグループ」セクションをチェックする必要があります。 VPCユーザーの場合、セキュリティグループは通常のVPCセキュリティグループになります（名前sg-xxxはRDSインスタンスの属性にリストされます）。
2）DNSが問題でないことを確認します。
AmazonはスプリットDNSを使用するため、AWS外部のDNSルックアップはパブリックIPを返し、AWS内部のルックアップはプライベートIPを返します。 DNSの問題であると思われる場合、異なるアベイラビリティーゾーンから異なるIPが返されることを確認しましたか？異なるAZが異なるIPを取得する場合、AWSサポートに連絡する必要があります。
3）ソケット接続を確立してネットワーク接続を確認します。
RDSは現在ICMPトラフィックをドロップするため、tracepathやtracerouteなどのツールは役に立たない可能性があります。
ポート3306（mysql、またはpostgresの場合は5432）でRDSインスタンスへのソケット接続を確立して、ポート接続をテストします。 RDSインスタンスのIPを見つけて、telnetまたはncを使用することから始めます。
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a）接続試行が成功せず、すぐに失敗する場合、ポートがブロックされているか、リモートホストがそのポートでサービスを実行していない可能性があります。さらにトラブルシューティングするためにAWSサポートに連絡する必要がある場合があります。 AWSの外部から接続する場合は、最初にAWS内の別のインスタンスから接続してみてください（ファイアウォールがこれらの接続をブロックしている可能性があるため）。
b）接続が成功せず、タイムアウトが発生した場合、パケットはおそらくファイアウォールによってドロップ/無視されているか、パケットは別のポートに戻っていますネットワークパス。これを確認するには、netstat -an | grep SYNを実行します（実行中に別のCLIウィンドウ/セッションから、telnet/ncコマンドがタイムアウトするのを待ちます）。 SYN状態の接続とは、接続要求を送信したが、何も受信していないことを意味します（SYN_ACKまたは拒否/ブロック）。通常、これはファイアウォールまたはセキュリティグループがパケットを無視またはドロップしていることを意味します。
ホストとRDSインスタンス間でiptablesまたはNATゲートウェイを使用していないことを確認してください。VPCを使用している場合は、ソースホスト。
c）ソケット接続テストは成功したが、mysqlクライアント（CLI、ワークベンチ、アプリなど）に接続できない場合は、 netstatの出力を見て、接続の状態を確認します（xxxxをRDSインスタンスの実際のIPアドレスに置き換えます）。
netstat -an | grep x.x.x.x
TelnetまたはNCを使用しているときに接続が確立されていたが、mysqlクライアントを使用しているときに「SYN」状態が表示される場合、MTUの問題が発生している可能性があります。
RDSは、これが記述されている時点では、PMTUDに使用されるICMPパケットをサポートしていない可能性があります（ https://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ）。 ClassicLinkを介してクラシックec2インスタンスからVPCにあるRDSまたはRedShiftにアクセスしようとしている場合、これは問題になる可能性があります。以下を使用してMTUを下げてから、もう一度テストしてください。
Sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
Sudo ip link set dev eth0 mtu 1400
低いMTUが機能した場合は、AWSのカスタマーサポートに連絡して、RDSインスタンスに接続しようとしているときにMTUの問題が発生していることを伝えてください。これは、TCPパケットがトンネリングのカプセル化でラップされ、パケットデータ/ペイロードの使用可能なMTUが低くなる場合に発生します。ソースサーバーのMTUを低くすると、ラップされたパケットは限定。
うまくいかなかった場合は、MTUをデフォルトに戻し、AWSサポートに連絡してさらにトラブルシューティングを行います。
マークの問題はマルチAZルーティングとEC2クラシックに関係しているように見えましたが、今日もまったく同じ問題に遭遇しました。
それを修正するために、EC2インスタンスから2つのプライベートIPアドレスを追加して、RDSインスタンスで自動的に作成されたセキュリティグループを変更しました。
これはかなり明らかな問題でしたが、私は一般的にAWSを初めて使用するので、これが私のような他の人にとって役立つことを願っています。
どうやら、マルチAZはすべてをねじ止めします。デフォルトのマルチAZ構成はデータベースをus-east-1dリージョンに配置し、EC2インスタンスはus-east-1aリージョンにあったため、DNSは正しくルーティングされませんでした。 RDSインスタンスを非マルチAZとして再作成し、us-east-1aでライブにしました。すべてが満足です。
RDS、ELB、およびマルチAZ機能を備えたAWSのDNSルーティングに関して超天才がいる場合、これを行う方法を知ることは非常に素晴らしいことです。 。
EC2インスタンスがRDSインスタンスへのアクセスを突然失い、Wordpressは動作を停止しました。セキュリティグループは正しく、EC2インスタンスのコンソールからではなくMySQL PHP。何らかの理由でEC2サーバーを再起動することで助けられました。