A serverless permit API opens many short database connections and forces the city to run a larger RDS instance than query CPU warrants. How can RDS Proxy help cost?
Select an answer to reveal the explanation.
Short Explanation
Hundreds of brief Lambda handshakes can bully you into an oversized RDS just for connections. RDS Proxy pools those chats so a smaller instance can breathe—and cost less.
Full Explanation
RDS Proxy pools and multiplexes connections, often allowing a smaller RDS instance class by smoothing connection spikes, which is how it helps cost for a serverless permit API that opens many short database connections and forced an oversized RDS beyond what query CPU warrants. Lambda concurrency can open more connections than a small instance handles; Proxy absorbs that storm so rightsizing becomes possible. Claiming RDS Proxy replaces RDS entirely so no database instance is billed fails factually: Proxy sits in front of RDS/Aurora and does not eliminate the database. Claiming RDS Proxy forces every Lambda to use dedicated physical hosts fails conceptually: Proxy is a managed connection pooler, not a dedicated-host placement engine for Lambda. Claiming RDS Proxy converts SQL databases into DynamoDB tables automatically fails because Proxy does not change the database engine or migrate schemas to DynamoDB. Exam caveat: use RDS Proxy to tame serverless connection storms and enable rightsizing; it is not a database replacement, dedicated-host mandate, or DynamoDB converter. Operational check: place the permit API’s Lambdas behind RDS Proxy; measure connection counts and CPU; downsize the instance class if headroom appears; load-test renewal spikes; and confirm Proxy failover behavior meets the city’s permit SLA.