A company runs a critical application where API Gateway exposes an HTTP API integrated with a Lambda function. The application stores data in an RDS for MySQL instance (2 vCPUs, 64 GB RAM). During unpredictable peak periods some API calls return HTTP 500 errors. CloudWatch Logs show “too many connections.” The database must remain available except during scheduled maintenance. How can the company make the application resilient to connection spikes?

Amazon RDS Proxy is the most effective solution because it pools and shares database connections, significantly reducing the number of open connections to the RDS instance. This prevents the "too many connections" error during connection spikes without requiring application code changes beyond updating the connection endpoint. Reducing vCPUs and increasing maxconnections is counterproductive; reducing vCPUs can worsen performance, and simply increasing maxconnections without connection pooling will eventually hit a new limit and consume more memory. Changing the DB instance class via a CloudWatch alarm is a reactive scaling measure that takes time and causes a brief outage, which is not suitable for immediate connection spikes. Using an EventBridge rule to increase maxconnections based on CPU utilization is also reactive and doesn't address the underlying connection management issue.