Articles

Affichage des articles associés au libellé RDS

Lambda vers RDS privé : configuration VPC, sous-réseaux et groupes de sécurité

Vous avez déployé une fonction Lambda et une instance RDS dans un sous-réseau privé, mais la connexion échoue silencieusement — timeout après 30 secondes, aucun message d'erreur applicatif, juste un délai d'attente. Ce scénario est l'un des plus fréquents en production AWS, et la cause racine est presque toujours une mauvaise compréhension de la façon dont Lambda s'intègre au réseau VPC. TL;DR — Lambda vers RDS privé Point clé Détail Configuration VPC obligatoire Sans configuration VPC sur la fonction Lambda, elle s'exécute dans le réseau AWS géré et ne peut pas atteindre vos ressources privées. Sous-réseaux privés Attachez Lambda aux mêmes sous-réseaux privés (ou à des sous-réseaux avec routage vers RDS) que votre instance RDS. Groupes de sécurité Le groupe de sécurité de RDS doit autoriser le trafic entrant depuis le groupe de sécurité de Lambda sur le port de la base de données. Acc...

Quand utiliser ElastiCache Redis : accélérer les lectures RDS avec un cache distribué

Votre base RDS répond en 200-400 ms sur des requêtes identiques relancées toutes les secondes — c'est le symptôme classique d'une absence de couche cache. Ajouter ElastiCache Redis devant RDS n'est pas une optimisation cosmétique : c'est un changement architectural qui déplace la charge de lecture du moteur relationnel vers un store en mémoire conçu pour ça. TL;DR — ElastiCache Redis face à RDS : quand et pourquoi Situation Sans cache Avec ElastiCache Redis Lecture répétée du même enregistrement Requête SQL à chaque appel Réponse depuis la mémoire, RDS non sollicité Pic de trafic soudain Connexions RDS saturées Cache absorbe la majorité des lectures Données de session utilisateur Stockage en base ou fichier TTL natif, accès O(1) Résultats de calculs coûteux Recalcul à chaque requête Résultat mis en cache jusqu'à expiration Données qui changent souvent Cache inutile ou dangereux I...

RDS Multi-AZ : haute disponibilité, basculement automatique et impact réel sur les performances

Quand une instance RDS tombe en production à 3h du matin, la question n'est pas 'pourquoi Multi-AZ n'était pas activé' — c'est 'combien de temps avant que le basculement soit terminé'. Comprendre ce que le Multi-AZ RDS apporte réellement, et ce qu'il ne fait pas, évite des surprises architecturales coûteuses. TL;DR — RDS Multi-AZ en un coup d'œil Dimension Comportement Multi-AZ Objectif principal Haute disponibilité et reprise automatique après incident Réplication Synchrone vers l'instance secondaire (standby) Basculement automatique Oui — RDS détecte la défaillance et redirige l'endpoint DNS Gain de performance en lecture Non — le standby ne sert pas de trafic en lecture Durée typique de basculement Varie selon le moteur et la charge — consultez la documentation AWS Coût Environ le double d'une instance Single-AZ (instance secondaire facturée) ...

Pourquoi utiliser Secrets Manager plutôt que de coder les secrets en dur ?

Un dépôt privé ne protège pas un mot de passe de base de données codé en dur — c'est une illusion de sécurité que l'on découvre souvent trop tard, après une rotation d'accès forcée ou une fuite via un log d'application. AWS Secrets Manager existe précisément pour découpler les secrets du code, et sa rotation automatique change fondamentalement la surface d'attaque. Résumé (TL;DR) — Secrets Manager vs. secrets codés en dur Critère Secret codé en dur AWS Secrets Manager Exposition en cas de fuite du dépôt Immédiate et permanente Aucune (le code ne contient pas le secret) Rotation du mot de passe Manuelle, risquée, souvent ignorée Automatique, sans interruption de service Audit d'accès Impossible CloudTrail enregistre chaque appel GetSecretValue Gestion multi-environnements Copie manuelle, divergence garantie Secrets distincts par environnement, même code Révocation d'urgence...

Restauration RDS depuis un Snapshot : Nouvelle Instance ou Écrasement ?

Quand une restauration RDS depuis un snapshot devient urgente — après une migration ratée ou une corruption de données — la première question qui bloque les équipes en production est toujours la même : est-ce que ça écrase l'instance existante, ou est-ce qu'une nouvelle instance est créée avec un endpoint différent ? La réponse a des conséquences directes sur la stratégie de bascule et le temps d'indisponibilité. TL;DR — Restauration RDS depuis un Snapshot Question Réponse Écrase l'instance existante ? Non. AWS crée toujours une nouvelle instance RDS distincte. Endpoint identique ? Non. La nouvelle instance reçoit un endpoint différent. L'instance source est-elle affectée ? Non. Elle continue de fonctionner normalement. Groupes de sécurité conservés ? Non. Le groupe par défaut est assigné — reconfiguration manuelle requise. Parameter group conservé ? Non. Le groupe par défaut est ...