SW BBANG F

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

Vous avez arrêté votre instance EC2 et vous découvrez, quelques jours plus tard, que les frais continuent de s'accumuler sur votre facture AWS. L'Elastic IP attachée à cette instance génère des coûts horaires — et c'est un piège que la majorité des ingénieurs rencontrent au moins une fois en production. TL;DR — Arrêter les frais d'Elastic IP Situation Facturation active ? Action requise Instance EC2 en cours d'exécution, EIP associée Non (inclus dans l'instance) Aucune Instance EC2 arrêtée, EIP associée Oui Désassocier + Libérer EIP allouée mais non associée Oui Libérer EIP libérée Non — Comment fonctionne la facturation des Elastic IPs AWS AWS facture les Elastic IPs selon un principe simple mais contre-intuitif : une adresse IP publique statique...

Vous regardez votre Target Group et toutes les instances affichent Healthy — pourtant l'ALB retourne des 502 à vos utilisateurs. C'est l'un des scénarios les plus frustrants en production : le health check passe, mais le trafic réel échoue. Le problème n'est pas la disponibilité de l'instance, c'est la nature de la réponse HTTP que l'application renvoie à l'ALB. TL;DR — Diagnostic Rapide ALB 502 Cause Signal Observable Couche Réponse HTTP invalide ou malformée access_log ALB : 502 , target_status_code: - Application Connexion fermée prématurément par la cible target_status_code: - ou vide TCP/Application Désalignement keep-alive (timeout) 502 intermittents, pas de log d'erreur applicatif Connexion Réponse trop lente (idle timeout dépassé) target_processing_time proche de 60s Timing Mauvais protocole cible (HTTP vs HTTPS) Erreur TLS dans les logs cible Protocole ...

Vous venez de créer un VPC personnalisé, lancé une instance EC2 dans un sous-réseau public, et pourtant ping google.com ne répond pas. Ce scénario est l'un des plus fréquents en démarrage AWS — non pas parce que la configuration est complexe, mais parce que le VPC par défaut masque plusieurs étapes que AWS effectue silencieusement en arrière-plan, et qu'un VPC personnalisé exige explicitement. Résumé (TL;DR) : EC2 sans accès Internet dans un VPC personnalisé Composant Problème fréquent Action corrective Internet Gateway (IGW) Non créée ou non attachée au VPC Créer et attacher l'IGW Table de routage Aucune route 0.0.0.0/0 vers l'IGW Ajouter la route et associer au sous-réseau Adresse IP publique Instance sans IP publique ou Elastic IP Activer l'auto-assign ou associer une EIP Security Group Règles sortantes trop restrictives Autoriser le trafic sortant HTTPS/HTTP Network ACL Règl...