Uma função Lambda agendada atualmente é executada sem acesso à VPC e busca conjuntos de dados da internet. O aplicativo será alterado para que a função Lambda precise gravar em uma instância de banco de dados RDS localizada em uma sub-rede privada. A VPC tem duas sub-redes públicas e duas privadas. Qual configuração permite que a função Lambda alcance o banco de dados privado e ainda acesse a internet?

A opção correta permite que a função Lambda acesse o banco de dados RDS privado e a internet. Ao habilitar o acesso à VPC e colocar a função Lambda nas sub-redes privadas, ela pode se comunicar com o RDS. Para acesso à internet, os gateways NAT nas sub-redes públicas, combinados com tabelas de rotas privadas direcionando o tráfego 0.0.0.0/0 para esses gateways NAT, fornecem conectividade de saída. Um grupo de segurança na função Lambda com acesso de saída permitido garante a comunicação. As outras opções estão incorretas porque: Criar uma função Lambda com Elastic IP e anexá-la a sub-redes públicas não é a forma padrão de permitir que funções Lambda acessem recursos privados e a internet simultaneamente. Funções Lambda habilitadas para VPC não usam Elastic IPs diretamente. Anexar a função Lambda a sub-redes públicas e adicionar dois IPs públicos não permite acesso direto a um banco de dados RDS em uma sub-rede privada, nem é a maneira correta de gerenciar o acesso à internet para funções Lambda em uma VPC. Enviar o tráfego destinado à internet diretamente para o internet gateway a partir de sub-redes privadas não é possível sem um gateway NAT ou internet gateway anexado diretamente à sub-rede privada, o que não é uma prática recomendada para recursos privados. Além disso, abrir regras de entrada em grupos de segurança para acesso à internet não é a forma correta de permitir que a função Lambda acesse a internet.