Una empresa está probando su plan de respuesta a incidentes por credenciales comprometidas. Una base de datos se ejecuta en una instancia de Amazon EC2, y las credenciales confidenciales de la base de datos se almacenan como un secreto en AWS Secrets Manager con la rotación habilitada a través de una función de AWS Lambda basada en la plantilla de rotación genérica. La instancia EC2 y la función Lambda están en la misma subred privada. La VPC tiene un VPC endpoint de Secrets Manager. La rotación está fallando y CloudWatch Logs muestra: “setSecret: Unable to log into database.” El VPC endpoint está funcionando como se espera. ¿Qué solución resuelve el error?

La rotación de Secrets Manager con una función Lambda genérica requiere que la función Lambda pueda conectarse a la base de datos para verificar las credenciales y realizar la rotación. El error "Unable to log into database" indica un problema de conectividad. Dado que la instancia EC2 y la función Lambda están en la misma subred privada, la comunicación entre ellas está controlada por los grupos de seguridad. La solución correcta implica configurar los grupos de seguridad para permitir esta comunicación. La opción de editar la estructura JSON del secreto es incorrecta porque el problema no es el formato del secreto, sino la incapacidad de la función Lambda para acceder a la base de datos. La opción de usar la CLI para forzar la rotación no resuelve la causa subyacente del fallo de conectividad. La opción de agregar un internet gateway y NAT gateway es incorrecta porque ya existe un VPC endpoint para Secrets Manager, y el problema es la comunicación entre Lambda y la base de datos, no con Secrets Manager.