A developer has implemented an AWS Lambda function that is triggered by an Amazon SQS queue. The function retrieves database credentials from AWS Secrets Manager, connects to an Amazon RDS PostgreSQL database in a private subnet, and processes messages. During load testing, the database experiences connection exhaustion, and some SQS messages are processed multiple times. Which TWO actions should the developer take to resolve these issues?
- Move the database connection initialization and secrets retrieval code outside of the Lambda handler function.Answer
- Configure the SQS queue's visibility timeout to be at least six times the timeout configuration of the Lambda function.Answer
- CHardcode the database credentials directly in the SDK client initialization within the Lambda function code to bypass retrieving secrets.
- DDecrease the SQS queue's visibility timeout to a value less than the Lambda function's timeout to speed up processing.
- EAssociate the Lambda function with the private subnets containing the database without creating a NAT Gateway or VPC endpoint.
Answer
Initialize the database connection and secrets retrieval outside of the handler function, and configure the SQS queue's visibility timeout to be at least six times the Lambda function's timeout.
Moving the connection code outside the handler allows subsequent invocations to reuse the established database connections from the execution context. Configuring the SQS visibility timeout to be at least six times the Lambda function's timeout prevents messages from being visible to other pollers before the active execution has completed.
Step-by-Step Solution
Key Concept
Reusing execution contexts and managing integration timeouts are critical for optimizing Lambda performance and ensuring message delivery semantics.
Estimated Time:1m 30s