The root cause of the problem is that the RDS PostgreSQL instance is exceeding its database connection limit due to high volumes of concurrent GET requests. The most efficient and lowest-effort remediation is to reduce the number of connections that reach the database and serve as many reads as possible from a cache layer. Option B accomplishes both goals with minimal changes to the existing architecture.

First, RDS Proxy manages database connections efficiently by pooling and reusing them. This reduces connection churn and prevents the Lambda function from opening excessive concurrent connections during traffic spikes. RDS Proxy is natively integrated with RDS and requires only minor configuration changes without altering application logic.

Second, enabling API Gateway caching allows caching GET responses directly at the API layer. Because over 90% of requests are GET operations, enabling caching drastically reduces traffic hitting both Lambda and RDS, significantly improving performance and lowering connection pressure.

Option C also improves read scaling, but adding ElastiCache introduces additional infrastructure and requires modifying application code to query Redis before querying the database. This is more complex than enabling API Gateway caching. Options A and D require full database migration, which is far more labor-intensive.

Option B is the simplest, most effective, and most aligned with AWS best practices for reducing RDS connection saturation.