A common performance issue for Lambda functions that access relational databases is the overhead of establishing a new database connection on every invocation. In the provided pseudocode, each call to lambda_handler opens a connection, executes one statement, and closes the connection. When the function runs hundreds of times per hour, repeatedly creating and tearing down connections adds latency (TCP handshake, TLS negotiation if used, authentication, database session setup), and can also increase load on the database connection manager.

AWS guidance for Lambda execution environments explains that the runtime environment may be reused across multiple invocations of the same function (a “warm” execution environment). Code that is initialized outside the handler runs once per execution environment lifecycle and can be reused on subsequent invocations in that environment. By moving database.connect() into the global scope (module-level initialization), the function can reuse an existing connection when the execution environment is warm, reducing per-invocation latency and improving overall throughput.

This change directly targets the slow part of the flow (connection setup) without changing the database engine, resizing the database, or adding unrelated concurrency settings. Increasing reserved concurrency (A) controls scaling limits but does not reduce the per-invocation connection overhead; it can even amplify connection storms. Resizing the database (B) might help capacity, but it does not address the repeated connection establishment cost and is not the first optimization. Replacing RDS with DynamoDB (D) is a major redesign and unnecessary for the stated issue.

So the best improvement, with minimal code change and aligned with Lambda best practices, is option C: create the connection outside the handler and reuse it when possible, while still handling retries and reconnect logic if the connection becomes stale.