A developer is designing a serverless ordering system where an AWS Lambda function processes message batches from an Amazon SQS queue. The function is configured with a timeout of 2 minutes and is placed inside private subnets of a custom VPC to write data to an Amazon Aurora DB cluster. The function also needs to call a public endpoint of an external payment gateway. During initial testing under load, the developer observes that the Lambda function fails to reach the external payment gateway, resulting in connection timeouts. Furthermore, the Aurora database cluster runs out of available database connections very quickly, and SQS messages are being received and processed multiple times by different Lambda invocations, even though the executions complete successfully in 90 seconds. Which combination of steps should the developer take to resolve these issues?
- Initialize the database connection pool outside the Lambda handler function. Deploy a NAT Gateway in a public subnet, and configure the route table of the Lambda private subnets to route outbound traffic through the NAT Gateway. Increase the SQS visibility timeout to at least 12 minutes.Cevap
- BInitialize the database connection pool inside the Lambda handler function. Deploy the Lambda function in a public subnet, and configure the VPC route table to send outbound traffic through an Internet Gateway. Decrease the SQS visibility timeout to 15 seconds.
- CInitialize the database connection pool outside the Lambda handler function. Deploy a NAT Gateway in a public subnet, and configure the route table of the Lambda private subnets to route outbound traffic through the NAT Gateway. Decrease the SQS visibility timeout to 15 seconds to minimize message processing latency.
- DInitialize the database connection pool inside the Lambda handler function. Configure a VPC Endpoint for the database, and attach an Internet Gateway directly to the Lambda function's private subnets. Increase the SQS visibility timeout to at least 12 minutes.