Dépannage des Problèmes Courants de Connexion RDS depuis des Instances EC2

Lorsqu'une application sur EC2 ne peut pas se connecter à RDS, identifiez d'abord le type de panne. Un délai d'attente signifie généralement que le trafic est interrompu quelque part sur le chemin. Un connection refused rapide signifie que l'hôte a été atteint mais que le port n'a pas accepté la connexion. Une erreur d'authentification signifie que le chemin réseau fonctionne probablement et que le problème est passé aux utilisateurs de la base de données, aux mots de passe, SSL, à l'authentification IAM ou aux autorisations.

Cette distinction fait gagner du temps. Ne réinitialisez pas les mots de passe pour un délai d'attente réseau et n'ouvrez pas les groupes de sécurité pour un mauvais mot de passe. Travaillez depuis l'instance EC2 vers l'extérieur : DNS, accessibilité du port, groupes de sécurité, routage de sous-réseau, NACL, état RDS, puis authentification de la base de données.

Prérequis pour une Connexion Réussie

Avant de plonger dans le dépannage, assurez-vous que les éléments fondamentaux suivants sont correctement configurés :

1. Alignement VPC : L'instance EC2 et l'instance RDS doivent idéalement résider dans le même VPC pour une configuration la plus simple, bien que la connectivité inter-VPC soit possible via le Peering VPC.
2. Zones de Disponibilité (AZ) : Assurez-vous que votre infrastructure d'application (EC2) peut atteindre l'infrastructure de base de données (RDS) à travers les AZ si nécessaire, bien que le routage gère généralement cela au sein du VPC.
3. Accessibilité Réseau : Confirmez que l'instance EC2 est en cours d'exécution et dispose d'une connexion réseau active (par exemple, elle peut atteindre Internet ou d'autres services internes).

Étape 1 : Vérifier les Configurations des Groupes de Sécurité (Le Coupable le Plus Courant)

Les groupes de sécurité agissent comme des pare-feu virtuels pour votre instance EC2 et votre instance RDS. Une mauvaise configuration ici est la source de la grande majorité des échecs de connexion.

A. Vérification du Groupe de Sécurité EC2

Votre instance EC2 a besoin de Règles de Sortie qui permettent au trafic de quitter le port de la base de données. Par défaut, la plupart des groupes de sécurité autorisent tout le trafic sortant (0.0.0.0/0 sur tous les protocoles/ports), mais il est sage de vérifier cela.

B. Vérification des Règles d'Entrée du Groupe de Sécurité RDS

C'est l'étape critique. Le groupe de sécurité RDS doit explicitement autoriser le trafic entrant depuis l'instance EC2.

Vérification Actionnable :

1. Accédez à la console RDS et sélectionnez votre instance de base de données.
2. Allez dans l'onglet Connectivité et sécurité et trouvez le(s) groupe(s) de sécurité associé(s).
3. Modifiez les Règles d'Entrée.
4. Assurez-vous qu'il existe une règle autorisant le trafic sur le port spécifique de la base de données (par exemple, 3306 pour MySQL, 5432 pour PostgreSQL).
5. La Source de cette règle doit être l'ID du Groupe de Sécurité de votre instance EC2, ou la plage d'adresses IP privées spécifique de l'instance EC2 si vous n'utilisez pas de références de groupe de sécurité.

Meilleure Pratique : Référencez toujours l'ID du Groupe de Sécurité de la ressource source (EC2) plutôt que d'utiliser des adresses IP spécifiques dans le champ source. Cela permet à la connexion de persister même si l'adresse IP privée de l'instance EC2 change (par exemple, lors d'un redimensionnement ou d'un redémarrage).

Exemple de Règle d'Entrée (PostgreSQL) :

Type	Protocole	Plage de Ports	Source
PostgreSQL	TCP	5432	sg-012345abcdef67890 (ID du Groupe de Sécurité EC2)

Étape 2 : Confirmer l'Accessibilité Publique RDS et le Point de Terminaison

Si votre instance EC2 n'est pas dans un sous-réseau privé ou nécessite une connexion via Internet public (généralement déconseillé pour la production), vous devez vérifier l'Accessibilité Publique RDS.

A. Paramètre d'Accessibilité Publique

1. Dans la console RDS, vérifiez l'onglet Connectivité et sécurité de l'instance RDS.
2. Si Accessible publiquement est défini sur Non, la base de données est accessible uniquement via des chemins réseau privés, tels que les ressources dans le même VPC ou les réseaux connectés via le peering, Transit Gateway, VPN, ou Direct Connect lorsque le routage et les règles de sécurité le permettent.
3. Si Accessible publiquement est défini sur Oui, ne traitez pas cela comme un raccourci pour l'accès en production. Confirmez que le client dispose d'une route publique valide et maintenez le groupe de sécurité RDS restreint à la plus petite plage source pratique. Une instance EC2 dans le même VPC devrait normalement utiliser le chemin privé.

B. Vérification du Point de Terminaison

Assurez-vous que l'application sur l'instance EC2 utilise le bon Point de Terminaison RDS (nom DNS) et le bon Port. Des discordances ici entraînent des délais d'attente ou des refus de connexion.

Utilisez l'utilitaire telnet ou nc (netcat) depuis votre instance EC2 pour tester la connectivité TCP de base au point de terminaison et au port RDS :

# Pour MySQL sur le port 3306
telnet votre-point-de-terminaison-rds.rds.amazonaws.com 3306

# Pour PostgreSQL sur le port 5432
nc -zv votre-point-de-terminaison-rds.rds.amazonaws.com 5432

Une connexion réussie se traduit par un écran vide ou un message de connexion immédiat. Un échec (délai d'attente ou refus) indique un blocage réseau, généralement les groupes de sécurité ou le routage de sous-réseau.

Étape 3 : Analyser la Configuration du Sous-réseau et du Routage

Si les groupes de sécurité semblent corrects, le problème peut résider dans la façon dont les sous-réseaux communiquent.

A. ACL Réseau (NACL)

Les ACL réseau sont des pare-feu sans état fonctionnant au niveau du sous-réseau. Si vous avez implémenté des NACL personnalisées, elles peuvent bloquer le trafic de retour nécessaire à l'établissement d'une connexion.

• Vérifiez les NACL pour le sous-réseau EC2 et le sous-réseau RDS.
• Assurez-vous que les règles d'Entrée et de Sortie autorisent le trafic sur le port de la base de données et la plage de ports éphémères (1024-65535) pour le trafic de retour.

B. Routage Inter-VPC ou Hybride

Les connexions à la base de données RDS utilisent généralement le routage VPC normal, pas un point de terminaison de passerelle de type S3. Si EC2 et RDS sont dans des VPC différents ou connectés depuis des réseaux sur site, vérifiez la route privée complète dans les deux directions. Le peering VPC, Transit Gateway, VPN, et Direct Connect nécessitent tous des entrées de table de routage ainsi que des règles de groupe de sécurité et NACL compatibles.

Étape 4 : Vérifications de la Configuration de l'Instance de Base de Données

Si la connectivité réseau est confirmée (Étape 2 réussie), le problème se situe au sein du moteur de base de données lui-même.

A. Identifiants et Autorisation de la Base de Données

Vérifiez le nom d'utilisateur, le mot de passe et le nom de la base de données utilisés par l'application se connectant depuis l'instance EC2. Les services RDS comme MySQL et PostgreSQL appliquent une authentification stricte des utilisateurs.

B. Groupes de Paramètres et État de la Base de Données

1. État de la Base de Données : Assurez-vous que l'état de l'instance RDS est Disponible. Si elle est en cours de modification, de sauvegarde ou de redémarrage, les connexions échoueront.
2. Groupes de Paramètres : Vérifiez les groupes de paramètres personnalisés appliqués à l'instance RDS. Certains paramètres (comme skip-networking dans certaines configurations MySQL, bien que moins courant dans RDS géré) peuvent empêcher les connexions.

C. Authentification de Base de Données IAM (Si Utilisée)

Si vous utilisez IAM pour l'authentification de la base de données au lieu de mots de passe, assurez-vous que le rôle IAM attaché à l'instance EC2 (ou le profil utilisateur exécutant l'application) dispose des autorisations correctes (rds-db:connect) et que la chaîne de connexion inclut correctement les jetons d'authentification nécessaires.

Flux de Dépannage

Utilisez cette liste de contrôle priorisée pour résoudre les problèmes rapidement :

1. Vérification du Port : EC2 peut-il atteindre le port RDS en utilisant telnet ou nc ? Ne vous fiez pas au ping ICMP ; RDS n'est pas un serveur normal que vous pouvez dépanner de cette façon.
2. Groupe de Sécurité RDS : La règle d'Entrée autorise-t-elle le trafic depuis le Groupe de Sécurité EC2 vers le port RDS ?
3. NACL : Les règles d'Entrée et de Sortie sont-elles ouvertes pour les ports nécessaires (Port de la Base de Données + Ports Éphémères) ?
4. Point de Terminaison/Identifiants : La chaîne de connexion est-elle correcte et les identifiants sont-ils valides ?
5. État de la DB : L'instance RDS est-elle Disponible ?

Si le test de port échoue, restez dans la couche réseau jusqu'à ce qu'il réussisse. Si le test de port réussit mais que le client de base de données échoue, arrêtez de modifier les règles VPC et lisez attentivement l'erreur de la base de données. La plupart des incidents EC2-vers-RDS deviennent beaucoup plus faciles une fois que l'accessibilité réseau et l'authentification de la base de données sont traitées comme des questions distinctes.