Aller au contenu

AWS Mis à jour le 2026-07-04

Délais de connexion RDS : groupes de sécurité, sous-réseaux et accessibilité publique, débogués dans l'ordre

Un délai de connexion (timeout) vers RDS est un problème de chemin réseau, pas de base de données. Voici l'ordre de débogage : groupes de sécurité, puis sous-réseaux et routage, puis l'indicateur publicly accessible et le DNS.

Une connexion vers RDS qui reste suspendue puis expire signifie que vos paquets sont abandonnés en silence quelque part sur le chemin réseau — ce qui, sur AWS, pointe d’abord vers les groupes de sécurité, ensuite vers les sous-réseaux et le routage, puis vers l’indicateur d’accessibilité publique. C’est différent de « connection refused » (vous avez atteint l’hôte, mauvais port ou moteur arrêté) et d’une erreur d’authentification (le réseau est correct, pas les identifiants). Les délais d’attente se déboguent dans un ordre fixe, et le groupe de sécurité est la réponse environ quatre fois sur cinq.

Ce qui se passe

Les instances RDS vivent dans un VPC et ne sont joignables que par les chemins que vous avez explicitement permis. Quatre barrières se dressent entre un client et le port de la base de données, et la défaillance de n’importe laquelle produit le même symptôme — une attente, puis un délai expiré :

Le groupe de sécurité attaché à l’instance doit permettre le trafic entrant sur le port du moteur (3306 pour MySQL/MariaDB, 5432 pour Postgres, 1433 pour SQL Server) depuis la source du client. Les groupes de sécurité abandonnent le trafic non apparié en silence — aucun paquet de rejet, d’où l’attente. Le patron le plus fiable référence le groupe de sécurité de l’application comme source plutôt que des plages d’adresses IP.

Sous-réseaux et routage. Le groupe de sous-réseaux de la base détermine quels sous-réseaux l’instance peut occuper. Un client dans un VPC appairé, une autre région, ou sur site via VPN a besoin de routes dans les deux sens; les ACL réseau des sous-réseaux, si quelqu’un les a personnalisées, doivent ouvrir le port plus les ports éphémères de retour.

L’indicateur d’accessibilité publique. Si PubliclyAccessible est faux, le DNS du point de terminaison ne résout que vers une adresse IP privée, et rien à l’extérieur du VPC ne peut l’atteindre, jamais. S’il est vrai et que l’instance est dans des sous-réseaux publics avec une route vers une passerelle Internet, le point de terminaison résout vers une IP publique de l’extérieur du VPC et une IP privée de l’intérieur — un détail qui explique bien des mystères « ça marche du bureau, ça expire depuis EC2 », à l’envers.

DNS. Connectez-vous toujours au nom d’hôte du point de terminaison, jamais à une IP résolue — l’IP sous-jacente change au basculement et à la maintenance.

Quoi vérifier en premier

  • D’où vous connectez-vous? Un portable sur le Wi-Fi de la maison, une instance EC2 dans le même VPC, un Lambda et un conteneur Fargate ont chacun un chemin réseau différent. Établissez ça avant de toucher à quoi que ce soit.
  • Délai expiré ou refusé? Connection refused signifie que le chemin réseau fonctionne — passez directement au port et au statut du moteur. Une attente qui traîne : continuez à lire.
  • Les règles entrantes du groupe de sécurité de la base — dans RDS > Databases > votre-instance > Connectivity & security, cliquez jusqu’au groupe de sécurité.
  • Ce que le point de terminaison résout depuis votre position : une IP privée (10.x, 172.16-31.x, 192.168.x) depuis l’extérieur du VPC signifie que l’indicateur d’accessibilité publique est votre problème.
  • Est-ce que ça a déjà fonctionné? Un chemin qui marchait hier pointe vers une règle modifiée ou une ressource remplacée, pas une lacune de conception.

Comment vérifier

Testez d’abord la joignabilité TCP brute — ça sépare le réseau des identifiants instantanément :

# Depuis le client qui échoue (nc, ou /dev/tcp de bash)
nc -zv -w 5 prod-db.abc123xyz.ca-central-1.rds.amazonaws.com 5432

# Vers quoi le point de terminaison résout-il d'ici?
dig +short prod-db.abc123xyz.ca-central-1.rds.amazonaws.com

Puis inspectez les barrières du côté AWS :

# Groupes de sécurité, groupe de sous-réseaux et indicateur public en un appel
aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[PubliclyAccessible,DBSubnetGroup.DBSubnetGroupName,
           VpcSecurityGroups[].VpcSecurityGroupId,Endpoint.Address,Endpoint.Port]'

# Les règles entrantes de ce groupe de sécurité
aws ec2 describe-security-groups --group-ids sg-0abc123 \
  --query 'SecurityGroups[0].IpPermissions'

Pour une réponse définitive sur un chemin interne au VPC, VPC Reachability Analyzer (VPC > Reachability Analyzer) trace la source jusqu’à la destination et nomme le composant bloquant exact — les quelques minutes en valent la peine dans tout cas non évident.

Le runbook

  1. Corriger le groupe de sécurité d’abord. Ajoutez une règle entrante sur le groupe de sécurité de la base pour le port du moteur avec le groupe de sécurité de l’application comme source (même VPC), ou le CIDR appairé / CIDR VPN pour les chemins inter-réseaux. Ça résout la grande majorité des délais RDS. Évitez 0.0.0.0/0 sur un port de base de données — si vous êtes tenté, c’est SSM ou un bastion qu’il vous faut.
  2. Vérifier les règles sortantes du client et les NACL. Les groupes de sécurité sont à états, donc la permission sortante par défaut couvre le chemin de retour — mais un SG de sortie verrouillé ou une ACL réseau personnalisée (sans états — il faut les ports éphémères 1024-65535 au retour) le brise. Les NACL par défaut permettent tout; ne les déboguez que si quelqu’un les a modifiées.
  3. Vérifier le routage pour les chemins inter-VPC et hybrides. L’appairage exige des entrées de route dans les tables de routage des deux VPC plus des règles SG référençant le CIDR appairé. VPN et Direct Connect exigent que le CIDR sur site soit routé et permis. Le trafic intra-VPC n’a besoin d’aucun travail de routes — si l’intra-VPC expire, c’est le SG ou la NACL, point final.
  4. Trancher l’accessibilité publique délibérément. Si un portable de développeur doit atteindre la base directement, soit rendez l’instance publiquement accessible (elle doit être dans des sous-réseaux avec une route IGW, et modifier l’indicateur est un changement de configuration, pas une reconstruction) — soit, mieux, gardez-la privée et connectez-vous par une session de redirection de port SSM ou un bastion. Un point de terminaison de base publique est une invitation permanente au trafic de bourrage d’identifiants.
  5. Se reconnecter via le nom d’hôte du point de terminaison. Si le client avait une IP codée en dur ou en cache (les JVM avec leur cache DNS par défaut sont notoires), ça casse après tout basculement. Connectez-vous par nom et respectez les TTL DNS.
  6. Seulement ensuite, soupçonner l’instance. Si TCP se connecte mais que le pilote expire quand même, regardez le moteur : une instance en état rebooting ou storage-full, ou saturée de connexions — ce qui est un autre article : trop de connexions.

Quand c’est la mauvaise approche

Si l’erreur est un échec d’authentification, un désaccord TLS ou un connection refused, le débogage réseau est de l’effort gaspillé — le chemin est prouvé. Si les connexions réussissent mais tombent après exactement N secondes d’inactivité, vous combattez un délai d’inactivité (passerelle NAT à 350 s, tables d’états de pare-feu) et le correctif, ce sont les keepalives TCP, pas les règles. Et résistez à « régler » un délai en basculant PubliclyAccessible à vrai — souvent ça ne fonctionnera pas de toute façon (sous-réseaux privés seulement), et quand ça fonctionne, vous avez élargi l’exposition pour corriger une règle que vous auriez pu cibler précisément. La documentation Amazon VPC couvre la sémantique des groupes de sécurité; notre article groupes de sécurité vs NACL couvre quelle couche déboguer et quand.

Erreurs fréquentes

  • Ajouter l’adresse IP publique du client au groupe de sécurité alors que le client est une instance EC2 qui se connecte dans le VPC depuis son IP privée — la règle ne s’applique jamais.
  • Déboguer les NACL, les tables de routage et le DNS pendant une heure avant de lire une seule fois les règles entrantes du groupe de sécurité.
  • Coder en dur l’IP résolue du point de terminaison « pour la fiabilité » — c’est le contraire; l’IP change au basculement.
  • Supposer que Lambda a un accès de type Internet vers RDS : un Lambda attaché au VPC a besoin que son SG soit permis en entrée sur le SG de la base; un Lambda hors VPC ne peut pas du tout atteindre une instance privée.

Prévention

  • Référencez des groupes de sécurité, pas des IP, pour les règles application-vers-base — ils survivent à l’autoscaling et au redéploiement.
  • Gardez les bases de production privées et standardisez l’accès des développeurs par la redirection de port SSM.
  • Nommez les groupes de sécurité par rôle (prod-db-postgres, prod-app-web) pour que l’intention des règles s’audite d’un coup d’œil.
  • Consignez le chemin réseau prévu par environnement dans le runbook — la plupart des incidents de délai, c’est quelqu’un qui le redécouvre sous pression.
  • Alarme sur le taux d’erreurs de connexion côté application pour qu’un chemin brisé remonte avant que les utilisateurs le signalent.

Les délais de connexion semblent opaques, mais l’ordre des barrières ne change jamais : groupe de sécurité, NACL et routes, accessibilité publique, DNS — vérifiés dans cet ordre, la plupart se diagnostiquent en moins de dix minutes. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.