A serverless application uses AWS Lambda functions that each open a new connection to an RDS MySQL database on every invocation, and during traffic spikes the database frequently runs out of available connections. Which change addresses this without redesigning the application's connection logic?
- Place Amazon RDS Proxy in front of the database and have the functions connect through it
- Increase the Lambda function's memory allocation
- Switch the database from RDS to DynamoDB on-demand mode
- Enable RDS storage autoscaling on the DB instance
Why A? And why not the others?
Correct answer: A. Place Amazon RDS Proxy in front of the database and have the functions connect through it
RDS Proxy sits between an application and the database, maintaining a warm pool of established database connections and multiplexing many short-lived client connections, such as those opened by frequently invoked Lambda functions, onto that pool, which directly solves connection exhaustion caused by high-concurrency, short-lived connection patterns without requiring any change to how the application code opens connections. The option about increasing Lambda memory is wrong because Lambda memory allocation affects CPU and execution speed, not the number of concurrent database connections the function pattern generates. The option about switching to DynamoDB is wrong because it would require redesigning the application's data model and queries around a non-relational engine, which the question explicitly rules out. The option about RDS storage autoscaling is wrong because that feature only manages disk space growth for the database's allocated storage and has no effect on the number of connections the database can accept.
Source: AWS RDS documentation: Amazon RDS Proxy