SAP-C02 Practice Question 17: Lambda Database Connection Exhaustion
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 2 · question 7 of 10
A retailer moved its checkout API from EC2 instances to AWS Lambda. The functions connect to an Amazon Aurora MySQL-Compatible Edition cluster. During flash sales, Lambda concurrency jumps from about 50 to more than 2,000 within a minute. At those moments the application logs fill with Too many connections errors, database CPU spikes even though query volume has barely changed, and checkout requests fail. The operations team also noticed that a recent Aurora writer failover caused a spike of errors lasting longer than the failover itself.
The company wants to stop the connection storms and shorten the error window during failovers. The fix must not change the SQL or the MySQL driver the functions use, must not require moving off Aurora MySQL, and must keep database credentials out of the function code. What should the solutions architect do?
Show answer and explanation
Answer:
The symptoms (connection errors and CPU burned while query volume is flat) point to connection churn, not query load. Every new Lambda execution environment opens its own database connection, and setting up MySQL connections and TLS sessions at that rate consumes the database. Amazon RDS Proxy sits between the functions and Aurora and keeps a pool of database connections that it reuses. It multiplexes many client connections onto far fewer database connections, and it queues or throttles clients that can't be served immediately instead of letting them overwhelm the database. The same service addresses the failover complaint: RDS Proxy connects to the new writer automatically while preserving application connections, which shortens the error window. It is wire-compatible with the engine, so most applications need no code changes beyond the endpoint. It retrieves database credentials from Secrets Manager, and functions can authenticate to the proxy with IAM.
Option A treats the symptom and gets more expensive. Each connection costs memory and CPU on the writer, so raising the ceiling lets the storm consume even more of the database. Bigger instances cost more on every day that isn't a flash sale, and failover behaviour doesn't change.
Option B protects the database by turning away customers. Capping concurrency at 100 during a flash sale means requests are throttled at the Lambda layer, so checkout still fails.
Option D doesn't apply to this workload. Checkout writes orders, and writes can only go to the writer, so moving connections to the reader endpoint either breaks the writes or moves the storm to the replicas without touching its cause.
Reference: Amazon RDS Proxy