EC2インスタンスからRDSへの一般的な接続問題のトラブルシューティング

EC2上のアプリケーションがRDSに接続できない場合、まず障害の種類を特定します。タイムアウトは、通常、経路上のどこかでトラフィックがドロップされていることを意味します。connection refused（接続拒否）は、ホストには到達したがポートが接続を受け付けなかったことを示します。認証エラーは、ネットワーク経路はおそらく機能しており、問題はデータベースユーザー、パスワード、SSL、IAM認証、または権限に移行していることを意味します。

この区別により時間を節約できます。ネットワークタイムアウトに対してパスワードをリセットしたり、パスワードの誤りに対してセキュリティグループを開放したりしないでください。EC2インスタンスから外側に向かって、DNS、ポート到達性、セキュリティグループ、サブネットルーティング、NACL、RDSステータス、そしてデータベース認証の順に作業を進めます。

接続成功の前提条件

トラブルシューティングに入る前に、以下の基本要素が正しく設定されていることを確認します。

VPCの整合性： 最も簡単な設定では、EC2インスタンスとRDSインスタンスの両方が同じVPC内にあることが理想的ですが、VPCピアリングを介したクロスVPC接続も可能です。
アベイラビリティゾーン（AZ）： 必要に応じて、アプリケーションインフラストラクチャ（EC2）がデータベースインフラストラクチャ（RDS）にAZをまたいで到達できることを確認します。ただし、ルーティングは通常、VPC内でこれを処理します。
ネットワーク到達性： EC2インスタンスが実行中であり、アクティブなネットワーク接続（例：インターネットや他の内部サービスに到達可能）があることを確認します。

ステップ1：セキュリティグループ設定の確認（最も一般的な原因）

セキュリティグループは、EC2インスタンスとRDSインスタンスの両方に対して仮想ファイアウォールとして機能します。ここでの設定ミスが、接続障害の大部分の原因です。

A. EC2セキュリティグループの確認

EC2インスタンスには、データベースポートへのトラフィックを許可するアウトバウンドルールが必要です。デフォルトでは、ほとんどのセキュリティグループはすべてのアウトバウンドトラフィック（すべてのプロトコル/ポートで0.0.0.0/0）を許可しますが、確認することをお勧めします。

B. RDSセキュリティグループのインバウンドルールの確認

これが重要なステップです。RDSセキュリティグループは、EC2インスタンスからのインバウンドトラフィックを明示的に許可する必要があります。

実行可能な確認手順：

RDSコンソールに移動し、データベースインスタンスを選択します。
接続とセキュリティタブに移動し、関連するセキュリティグループを見つけます。
インバウンドルールを編集します。
特定のデータベースポート（例：MySQLの場合は3306、PostgreSQLの場合は5432）のトラフィックを許可するルールがあることを確認します。
このルールの送信元は、EC2インスタンスのセキュリティグループID、またはセキュリティグループ参照を使用しない場合はEC2インスタンスの特定のプライベートIP範囲である必要があります。

ベストプラクティス： 送信元フィールドで特定のIPアドレスを使用するのではなく、常に送信元リソース（EC2）のセキュリティグループIDを参照してください。これにより、EC2インスタンスのプライベートIPが変更された場合（例：スケーリングや再起動時）でも、接続を維持できます。

インバウンドルールの例（PostgreSQL）：

タイプ	プロトコル	ポート範囲	送信元
PostgreSQL	TCP	5432	sg-012345abcdef67890（EC2セキュリティグループID）

ステップ2：RDSのパブリックアクセス可能性とエンドポイントの確認

EC2インスタンスがプライベートサブネットにない場合、またはパブリックインターネット経由での接続が必要な場合（通常、本番環境では推奨されません）、RDSのパブリックアクセス可能性を確認する必要があります。

A. パブリックアクセス可能性の設定

RDSコンソールで、RDSインスタンスの接続とセキュリティタブを確認します。
パブリックアクセス可能がいいえに設定されている場合、データベースはプライベートネットワークパス（同じVPC内のリソースや、ピアリング、Transit Gateway、VPN、Direct Connectを介して接続されたネットワーク）からのみ到達可能です。ルーティングとセキュリティルールで許可されている場合に限ります。
パブリックアクセス可能がはいに設定されている場合、それを本番環境アクセスのショートカットとして扱わないでください。クライアントに有効なパブリックルートがあることを確認し、RDSセキュリティグループを可能な限り最小の実用的な送信元範囲に制限してください。同じVPC内のEC2インスタンスは、通常、プライベートパスを使用する必要があります。

B. エンドポイントの確認

EC2インスタンス上のアプリケーションが、正しいRDSエンドポイント（DNS名）と正しいポートを使用していることを確認します。ここでの不一致は、タイムアウトや接続拒否につながります。

EC2インスタンスからtelnetまたはnc（netcat）ユーティリティを使用して、RDSエンドポイントとポートへの基本的なTCP到達性をテストします。

# MySQL（ポート3306）の場合
telnet your-rds-endpoint.rds.amazonaws.com 3306

# PostgreSQL（ポート5432）の場合
nc -zv your-rds-endpoint.rds.amazonaws.com 5432

成功した接続は、空白の画面または即時の接続メッセージになります。失敗（タイムアウトまたは拒否）は、通常、セキュリティグループまたはサブネットルーティングによるネットワークのブロックを示します。

ステップ3：サブネットとルーティング設定の分析

セキュリティグループが正しいように見える場合、問題はサブネット間の通信方法にある可能性があります。

A. ネットワークACL（NACL）

ネットワークACLは、サブネットレベルで動作するステートレスなファイアウォールです。カスタムNACLを実装している場合、接続完了に必要な戻りトラフィックをブロックしている可能性があります。

EC2サブネットとRDSサブネットの両方のNACLを確認します。
インバウンドルールとアウトバウンドルールの両方が、データベースポートと戻りトラフィック用のエフェメラルポート範囲（1024-65535）のトラフィックを許可していることを確認します。

B. クロスVPCまたはハイブリッドルーティング

RDSデータベース接続は、通常、S3スタイルのゲートウェイエンドポイントではなく、通常のVPCルーティングを使用します。EC2とRDSが異なるVPCにある場合、またはオンプレミスネットワークから接続されている場合、双方向の完全なプライベートルートを確認します。VPCピアリング、Transit Gateway、VPN、Direct Connectはすべて、ルートテーブルエントリと互換性のあるセキュリティグループおよびNACLルールが必要です。

ステップ4：データベースインスタンス設定の確認

ネットワーク接続が確認された場合（ステップ2が成功）、問題はデータベースエンジン自体にあります。

A. データベース認証情報と認可

EC2インスタンスから接続するアプリケーションが使用するユーザー名、パスワード、データベース名を確認します。MySQLやPostgreSQLなどのRDSサービスは、厳格なユーザー認証を実施します。

B. パラメータグループとデータベースステータス

データベースステータス： RDSインスタンスのステータスが利用可能であることを確認します。変更中、バックアップ中、または再起動中の場合、接続は失敗します。
パラメータグループ： RDSインスタンスに適用されたカスタムパラメータグループを確認します。特定の設定（管理対象RDSでは一般的ではありませんが、一部のMySQL設定でのskip-networkingなど）が接続を妨げる可能性があります。

C. IAMデータベース認証（使用する場合）

パスワードの代わりにIAMをデータベース認証に使用している場合、EC2インスタンスにアタッチされたIAMロール（またはアプリケーションを実行するユーザープロファイル）に正しい権限（rds-db:connect）があり、接続文字列に必要な認証トークンが正しく含まれていることを確認します。

トラブルシューティングフロー

以下の優先順位付きチェックリストを使用して、問題を迅速に解決します。

ポート確認： EC2はtelnetまたはncを使用してRDSポートに到達できますか？ICMP pingに依存しないでください。RDSはその方法でトラブルシューティングできる通常のサーバーではありません。
RDSセキュリティグループ： インバウンドルールは、EC2セキュリティグループからRDSポートへのトラフィックを許可していますか？
NACL： インバウンドルールとアウトバウンドルールの両方が、必要なポート（データベースポート+エフェメラルポート）に対して開放されていますか？
エンドポイント/認証情報： 接続文字列は正しく、認証情報は有効ですか？
DBステータス： RDSインスタンスは利用可能ですか？

ポートテストが失敗した場合は、成功するまでネットワークレイヤーにとどまります。ポートテストが成功したがデータベースクライアントが失敗した場合は、VPCルールの変更を停止し、データベースエラーを注意深く読みます。ネットワーク到達性とデータベース認証を別々の問題として扱うことで、ほとんどのEC2からRDSへのインシデントははるかに簡単になります。