Articles

Affichage des articles associés au libellé VPC

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...

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...

Connecter Deux VPCs avec le VPC Peering : Configuration et Tables de Routage

Vous avez deux VPCs dans le même compte et la même région AWS, et vos instances ne peuvent pas se parler en IP privée — c'est une situation classique quand on sépare les environnements (prod/staging) ou qu'on isole des workloads par domaine métier. Le VPC Peering est la solution native pour établir cette connectivité sans passer par Internet, mais la moitié des ingénieurs qui le configurent pour la première fois se retrouvent avec une connexion 'Active' qui ne route toujours rien, parce qu'ils ont oublié de mettre à jour les tables de routage des deux côtés. TL;DR — Résumé de la Configuration VPC Peering Étape Action Côté concerné 1 Créer la demande de peering VPC requérant 2 Accepter la connexion de peering VPC acceptant 3 Ajouter une route vers le CIDR distant Les deux VPCs 4 Mettre à jour les Security Groups Les deux VPCs 5 Vérifier la résolution DNS (optionnel) Les deux VPCs ...

EC2 SSH Connexion Timeout : Quelles Règles de Sécurité Vérifier

Vous venez de lancer une nouvelle instance EC2, vous tapez ssh ec2-user@<ip-publique> et le terminal reste figé pendant 20 secondes avant d'afficher 'Connection timed out' — c'est l'un des problèmes les plus fréquents sur EC2, et il est presque toujours lié à une règle entrante manquante dans le Security Group ou à un problème de routage réseau sous-jacent. TL;DR — Résumé Rapide Couche à vérifier Problème typique Action corrective Security Group (SG) Port 22 TCP absent en entrée Ajouter une règle inbound TCP/22 Network ACL (NACL) Règle DENY sur port 22 ou ports éphémères bloqués Vérifier les règles NACL entrantes ET sortantes Table de routage Pas d'Internet Gateway associée au sous-réseau public Associer une IGW et vérifier la route 0.0.0.0/0 IP publique Instance sans IP publique ou Elastic IP Allouer et associer une Elastic IP Pare-feu OS iptables ou firewalld bloquan...