Which of the possible solutions will allow the Lambda functions to access the Neptune DB cluster and DynamoDB tables?
(Choose two.)
Create three public subnets in the Neptune VPC, and route traffic through an internet gateway. Host the Lambda functions in the three new public subnets.
Create three private subnets in the Neptune VPC, and route internet traffic through a NAT gateway. Host the Lambda functions in the three new private subnets.
Host the Lambda functions outside the VPUpdate the Neptune security group to allow access from the IP ranges of the Lambda functions.
Host the Lambda functions outside the VPC. Create a VPC endpoint for the Neptune database, and have the Lambda functions access Neptune over the VPC endpoint.
Create three private subnets in the Neptune VPC. Host the Lambda functions in the three new isolated subnets. Create a VPC endpoint for DynamoDB, and route DynamoDB traffic to the VPC endpoint.
Explanations:
Creating public subnets and routing traffic through an internet gateway would expose the Neptune DB cluster to the public internet, which is not secure. Lambda functions should ideally run in private subnets to access resources securely.
Creating private subnets and using a NAT gateway allows the Lambda functions to securely access the Neptune DB cluster and other AWS services while keeping the database isolated from the public internet.
Hosting Lambda functions outside the VPC does not allow them to access the Neptune DB cluster directly. The Neptune DB needs to be in the same VPC or have proper VPC peering or endpoints to allow access.
While a VPC endpoint for Neptune could provide access, hosting Lambda functions outside the VPC limits the ability to communicate securely with the Neptune DB directly, which is typically not recommended for VPC resources.
Creating private subnets for the Lambda functions and setting up a VPC endpoint for DynamoDB allows secure access to both the Neptune DB and DynamoDB from within the VPC without exposing the resources to the internet.