Dépannage des problèmes courants de connexion RDS depuis les instances EC2

Connecter une instance Amazon EC2 à une instance Amazon Relational Database Service (RDS) est une opération fondamentale dans de nombreuses architectures AWS. Cependant, les complexités de configuration réseau entraînent souvent des échecs de connexion. Ce guide propose une approche systématique pour diagnostiquer et résoudre les problèmes de connectivité les plus courants entre votre couche de calcul (EC2) et votre couche de base de données gérée (RDS).

Sachant que EC2 et RDS résident tous deux dans l'environnement Virtual Private Cloud (VPC) d'AWS, la plupart des problèmes de connexion proviennent de règles de groupe de sécurité incorrectes, de problèmes de routage de sous-réseau ou de mauvaises configurations de paramètres de base de données. En vérifiant méthodiquement ces composants, vous pouvez rapidement rétablir l'accès à la base de données.

Prérequis pour une connexion réussie

Avant de vous lancer 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 simplifiée, bien que la connectivité inter-VPC soit possible via le VPC Peering.
2. Zones de disponibilité (AZ) : Assurez-vous que votre infrastructure applicative (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 fréquent)

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 sortantes qui autorisent le trafic à quitter sur 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 judicieux de le vérifier.

B. Vérification des règles entrantes du groupe de sécurité RDS

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

Vérification actionnable :

1. Accédez à la console RDS et sélectionnez votre instance de base de données.
2. Accédez à l'onglet Connectivité et sécurité et trouvez le(s) groupe(s) de sécurité associé(s).
3. Modifiez les Règles entrantes.
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é.

Bonne 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'une mise à l'échelle ou d'un redémarrage).

Exemple de règle entrante (PostgreSQL) :

Type	Protocole	Plage de ports	Source
PostgreSQL	TCP	5432	sg-012345abcdef67890 (Votre ID de 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 (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 ne peut être atteinte que par les ressources au sein du même VPC (comme une instance EC2 dans un sous-réseau privé).
3. Si Accessible publiquement est défini sur Oui, assurez-vous que l'instance EC2 dispose d'une route valide vers le passerelle Internet ou la passerelle NAT si elle se trouve dans un sous-réseau privé, et que le groupe de sécurité autorise les entrées des plages d'adresses IP publiques nécessaires (ou est sécurisé via une liste blanche d'IP stricte).

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. Les divergences 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 l'accessibilité TCP de base au point de terminaison et au port RDS :

# Pour MySQL sur le port 3306
telnet your-rds-endpoint.rds.amazonaws.com 3306

# Pour PostgreSQL sur le port 5432
nc -zv your-rds-endpoint.rds.amazonaws.com 5432

Une connexion réussie aboutit à 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 des groupes de sécurité ou un routage de sous-réseau.

Étape 3 : Analyser la configuration des sous-réseaux et du routage

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

A. Listes de contrôle d'accès réseau (NACL)

Les NACL sont des pare-feu sans état fonctionnant au niveau du sous-réseau. Si vous avez implémenté des NACL personnalisées, elles pourraient bloquer le trafic de retour nécessaire à la complétion 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 entrantes et sortantes 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. Points de terminaison VPC (si applicable)

Si votre instance EC2 se trouve dans un sous-réseau privé et accède aux points de terminaison RDS via un point de terminaison de passerelle VPC pour S3 ou des points de terminaison d'interface pour d'autres services, assurez-vous que la politique du point de terminaison autorise la communication pour le service RDS si applicable, bien que RDS repose généralement sur un routage VPC standard.

Étape 4 : Vérifications de la configuration de l'instance de base de données

Si la connectivité réseau est confirmée (l'étape 2 réussit), le problème se situe dans le moteur de base de données lui-même.

A. Informations d'identification de la base de données et autorisation

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 tels que MySQL et PostgreSQL appliquent une authentification utilisateur stricte.

B. Groupes de paramètres et état de la base de données

1. État de la base de données : Assurez-vous que le statut de l'instance RDS est Disponible. S'il est en cours de modification, de sauvegarde ou de redémarrage, les connexions échoueront.
2. Groupes de paramètres : Vérifiez tous 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 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.

Résumé du flux de dépannage

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

1. Vérification Ping/Telnet : EC2 peut-il atteindre le port RDS en utilisant telnet ou nc ? (Teste le chemin réseau de base/les groupes de sécurité).
2. Groupe de sécurité RDS : La règle entrante autorise-t-elle le trafic depuis le groupe de sécurité EC2 vers le port RDS ?
3. NACL : Les règles entrantes et sortantes sont-elles ouvertes pour les ports nécessaires (Port de base de données + Ports éphémères) ?
4. Point de terminaison/Informations d'identification : La chaîne de connexion est-elle correcte et les informations d'identification sont-elles valides ?
5. État de la base de données : L'instance RDS est-elle Disponible ?

En vérifiant méthodiquement ces couches — du périmètre de sécurité vers la couche d'authentification de la base de données — vous pouvez isoler et corriger efficacement la plupart des obstacles courants à la connectivité EC2-RDS.