How to optimize Lambda RDS connection performance?
A developer has implemented an AWS Lambda function that inserts new customers into an Amazon RDS database. The function is expected to run hundreds of times each hour. The function and RDS database are in the same VPC. The function is configured to use 512 MB of RAM and is based on the following pseudo code: After successfully testing the function multiple times, the developer notices that the execution time is longer than expected. What should the developer do to improve performance? - 
Community Votes
75% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
This question tests understanding of Lambda execution context reuse and the critical best practice of placing database connection initialization outside the handler function to leverage connection pooling across warm starts.
AWS Lambda functions that connect to Amazon RDS should initialize database connections in the global scope outside the handler to reuse connections across warm invocations, significantly reducing execution time and overhead.
Many candidates choose A (increase reserved concurrency), mistakenly believing that throttling due to concurrency limits is causing longer execution times, when in fact the issue is per-invocation overhead from repeatedly establishing database connections inside the handler.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Understanding Lambda Execution Context and Database Connections
When an AWS Lambda function is invoked, AWS initializes an execution context, which includes the runtime environment and any global variables declared outside the handler function. This context is reused for subsequent invocations (warm starts) until it expires or is recycled.
The pseudo code in the question shows the database connection being established inside the handler function. This means every single invocation — even warm starts — creates a new database connection, which involves significant overhead: TCP handshake, authentication, and session setup. When the function runs hundreds of times per hour, this repeated connection overhead accumulates and noticeably increases execution time.
Why Option C is Correct
Option C correctly identifies that moving the database connection (and close statement) to the global space (outside the handler) allows the connection to be created once during container initialization and then reused across all warm invocations. This is a fundamental AWS Lambda best practice for database connectivity.
By placing the connection in the global scope:
- The connection is established only during cold starts
- Warm starts reuse the existing connection, eliminating connection overhead
- Overall execution time drops significantly
- Fewer total connections are opened against the RDS instance, reducing database load
Why the Other Options Are Wrong
- Option A (Increase reserved concurrency): Reserved concurrency sets a ceiling on concurrent executions; it does not improve per-invocation performance. The problem described is longer execution time per invocation, not throttling. Increasing reserved concurrency would not reduce the time each invocation takes.
- Option B (Increase RDS database size): Scaling up the RDS instance might help if the database itself is a bottleneck (CPU, memory, IOPS), but the question specifically points to connection overhead in the Lambda code as the issue, not database capacity.
- Option D (Replace RDS with DynamoDB): While DynamoDB is a valid alternative for certain workloads, the question is about optimizing the existing Lambda-to-RDS architecture, not a complete redesign. Moreover, DynamoDB does not inherently solve the connection reuse pattern being tested here.
Community Consensus
The community overwhelmingly supports Option C (75%), with experienced candidates noting that this is a classic Lambda best practice: "Create the connection once when the Lambda container initializes, reuse that same connection across multiple invocations, significantly reduce the overhead of establishing new connections."
Official Reference
Exam Strategy
When a Lambda performance question mentions database connections and repeated invocations, always check whether the connection is initialized inside or outside the handler. Connection reuse via global scope is one of the most frequently tested Lambda optimization patterns on the DVA-C02 exam.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →