A SaaS application on AWS uses AWS Lambda for compute and an Amazon RDS for MySQL Multi-AZ database. During high-demand market events, database connection counts spike and users experience slow responses. The company needs to improve the database’s scalable performance and availability to handle many concurrent connections from Lambda. Which solution meets this need?

The correct solution is to migrate to Amazon Aurora, add an Aurora Replica, and configure Amazon RDS Proxy. Amazon Aurora is a highly scalable and performant database compatible with MySQL, offering better throughput and availability than standard RDS for MySQL. Adding an Aurora Replica provides read scaling and high availability. Most critically, Amazon RDS Proxy is designed to manage and pool database connections, which is essential for serverless applications like Lambda that can rapidly open many connections, preventing database overload and improving response times. Creating a CloudWatch alarm to add a read replica is reactive and doesn't address the connection pooling issue. Migrating to Aurora and adding a read replica is good, but initializing a connection pool outside the Lambda handler is not a robust solution for managing connections across many concurrent Lambda invocations. Using Route 53 weighted records with Aurora read replicas helps distribute read traffic but doesn't solve the core problem of connection management and pooling for a high volume of Lambda invocations.