An IoT telemetry ingestion application processes sensor data using an AWS Lambda function written in Node.js and writes the parsed payloads to an Amazon RDS database. During testing under heavy load, the Lambda function execution terminates prematurely after seconds, and the database metrics show a spike in active client connections that reaches the database's limit. The database connection client initialization code is currently located inside the Lambda handler function.
Which TWO actions should be taken to resolve these configuration and execution issues?
- Increase the Lambda function's timeout configuration to a value that accommodates the database write latency.Answer
- Move the database connection initialization code outside of the Lambda handler function to reuse the database client across multiple invocations.Answer
- CDeploy the Lambda function in a public subnet of a VPC to allow direct internet access to the database.
- DEnable active tracing with AWS X-Ray to automatically close database connections at the end of each invocation.
- EReduce the Lambda function's memory configuration to force faster garbage collection of unused database connections.
Answer
Increase the Lambda function's timeout configuration and move the database connection initialization code outside of the Lambda handler function.
Increasing the function timeout allows it to execute beyond the 3-second default threshold, which accommodates database write latency. Moving the database client initialization outside of the handler leverages the Lambda execution context reuse, allowing subsequent requests to share the connection pool and avoiding database connection exhaustion.
Step-by-Step Solution
Key Concept
AWS Lambda configuration tuning and execution context optimization