Une entreprise teste son plan de réponse aux incidents pour des identifiants compromis. Une base de données s'exécute sur une instance Amazon EC2, et les identifiants sensibles de la base de données sont stockés en tant que secret dans AWS Secrets Manager avec la rotation activée via une fonction AWS Lambda basée sur le modèle de rotation générique. L'instance EC2 et la fonction Lambda se trouvent dans le même sous-réseau privé. Le VPC dispose d'un VPC endpoint Secrets Manager. La rotation échoue et les journaux CloudWatch affichent : « setSecret: Unable to log into database. » Le VPC endpoint fonctionne comme prévu. Quelle solution résout l'erreur ?

L'erreur « setSecret: Unable to log into database » indique que la fonction Lambda de rotation n'a pas pu se connecter à la base de données. Puisque la fonction Lambda et l'instance EC2 sont dans le même sous-réseau privé et qu'un VPC endpoint Secrets Manager est en place, le problème n'est pas lié à la connectivité Internet ou au VPC endpoint. La cause la plus probable est un problème de groupe de sécurité. La fonction Lambda a besoin d'une autorisation de sortie pour atteindre l'instance EC2, et l'instance EC2 a besoin d'une autorisation d'entrée pour accepter les connexions de la fonction Lambda. Les autres options sont incorrectes : Modifier la structure JSON du secret ne résoudra pas un problème de connectivité réseau. Utiliser list-secrets ou rotate-secret via l'AWS CLI ne corrigera pas le problème de connectivité sous-jacent qui empêche la rotation. Ajouter une passerelle Internet et une passerelle NAT est inutile car un VPC endpoint pour Secrets Manager existe déjà, et le problème est la connectivité entre la Lambda et l'instance EC2, pas l'accès à Secrets Manager.