Uma empresa executa uma instância de banco de dados Amazon RDS for MySQL em uma VPC que não deve enviar ou receber tráfego pela internet pública. Devido a restrições de política, a empresa não pode usar a função de rotação padrão do AWS Lambda que o AWS Secrets Manager fornece, então uma função Lambda personalizada foi implantada na VPC para rotacionar o segredo. O security group da instância de banco de dados permite conexões dessa função. No entanto, quando invocada, a função não consegue alcançar o Secrets Manager para concluir a rotação. O que o engenheiro de segurança deve fazer para permitir que a função rotacione o segredo?

A opção correta é criar um VPC endpoint de interface do AWS Secrets Manager (AWS PrivateLink) e incluir a sub-rede privada da função Lambda na configuração do endpoint. Isso permite que a função Lambda, que está em uma VPC sem acesso à internet pública, se comunique de forma privada e segura com o serviço Secrets Manager dentro da rede AWS, sem precisar sair da VPC. As opções incorretas são: Adicionar um egress-only internet gateway não é aplicável, pois é usado para instâncias IPv6 em sub-redes públicas que precisam iniciar comunicação de saída para a internet, e o Secrets Manager é um serviço AWS, não um destino na internet pública. Adicionar um NAT gateway permitiria que a função Lambda acessasse a internet, mas o Secrets Manager é um serviço AWS e a comunicação deve ser privada, não via internet pública. Além disso, o NAT gateway incorreria em custos desnecessários e não seria a solução mais segura para acesso a serviços AWS. Criar uma conexão de VPC peering para a VPC padrão do Secrets Manager não é possível, pois o Secrets Manager não reside em uma VPC acessível via peering. Serviços AWS são acessados por endpoints ou via PrivateLink.