Uma empresa está testando seu plano de resposta a incidentes para credenciais comprometidas. Um banco de dados é executado em uma instância EC2, e as credenciais confidenciais do banco de dados são armazenadas como um segredo no AWS Secrets Manager com rotação habilitada por meio de uma função AWS Lambda baseada no modelo de rotação genérico. A instância EC2 e a função Lambda estão na mesma sub-rede privada. A VPC tem um endpoint do Secrets Manager. A rotação está falhando e os logs do CloudWatch mostram: “setSecret: Unable to log into database.” O endpoint da VPC está funcionando conforme o esperado. Qual solução resolve o erro?

O erro "setSecret: Unable to log into database" indica que a função Lambda de rotação não consegue se conectar ao banco de dados para atualizar as credenciais. Como a função Lambda e a instância EC2 estão na mesma sub-rede privada, a comunicação entre elas é controlada por grupos de segurança. A solução correta é permitir que a função Lambda (saída) se conecte à instância EC2 (entrada) nas portas necessárias do banco de dados. A primeira opção está incorreta porque a estrutura JSON do segredo não impede a conexão ao banco de dados; o problema é de conectividade de rede. A terceira opção tenta forçar a rotação, mas não resolve a causa subjacente da falha de conexão. A quarta opção está incorreta porque já existe um endpoint de VPC para o Secrets Manager, e a comunicação entre a Lambda e o banco de dados não precisa de internet gateway ou NAT gateway, pois estão na mesma VPC.