Una aplicación sin servidor utiliza AWS Lambda y DynamoDB. La nueva funcionalidad requiere que las funciones Lambda accedan a un clúster de Amazon Neptune DB ubicado en tres subredes en una VPC. ¿Qué soluciones permitirán que las funciones Lambda accedan tanto al clúster de Neptune como a DynamoDB? (Elija dos.)

Las funciones Lambda que necesitan acceder a recursos dentro de una VPC (como Neptune) deben configurarse para ejecutarse dentro de esa VPC, específicamente en subredes privadas para mayor seguridad. Para permitir que estas funciones accedan a servicios externos (como DynamoDB, que es un servicio público de AWS), se necesita una ruta de salida. La opción "Cree tres subredes privadas en la VPC de Neptune y enrute el tráfico saliente a Internet a través de un NAT gateway. Configure las funciones Lambda para que se ejecuten en esas subredes privadas" es correcta porque permite que las funciones Lambda accedan a Neptune (dentro de la VPC) y a DynamoDB (a través del NAT Gateway para tráfico público). La opción "Cree tres subredes privadas en la VPC de Neptune y aloje las funciones Lambda en esas subredes privadas aisladas. Cree un VPC endpoint para DynamoDB y enrute el tráfico de DynamoDB a través de ese endpoint" también es correcta. Al usar un VPC endpoint para DynamoDB, el tráfico a DynamoDB permanece dentro de la red de AWS, mejorando la seguridad y el rendimiento, sin necesidad de un NAT Gateway para ese servicio específico. Las opciones incorrectas son: Crear subredes públicas para Lambda es una mala práctica de seguridad. Ejecutar Lambda fuera de la VPC y permitir rangos de IP es inseguro y los rangos de IP de Lambda pueden cambiar. Un VPC endpoint para Neptune no es aplicable porque Neptune ya está dentro de la VPC.