Een bedrijf draait een bedrijfskritische applicatie waarbij API Gateway een HTTP API beschikbaar maakt die is geïntegreerd met een Lambda-functie. De applicatie slaat gegevens op in een RDS for MySQL-instantie (2 vCPU's, 64 GB RAM). Tijdens onvoorspelbare piekperioden retourneren sommige API-aanroepen HTTP 500-fouten. CloudWatch Logs tonen "too many connections". De database moet beschikbaar blijven, behalve tijdens gepland onderhoud. Hoe kan het bedrijf de applicatie veerkrachtig maken tegen verbindingspieken?

Amazon RDS Proxy is de meest effectieve oplossing. Het beheert en deelt databaseverbindingen, waardoor het aantal open verbindingen met de RDS-instantie wordt verminderd en de veerkracht tijdens verbindingspieken toeneemt. De Lambda-functie kan verbinding maken met de proxy, die de verbindingen met de database poolt en hergebruikt. Het verminderen van vCPU's en het verhogen van maxconnections is contraproductief; minder vCPU's kunnen de prestaties verslechteren, en meer verbindingen zonder pooling kunnen de database verder belasten. Een CloudWatch-alarm dat de instantieklasse wijzigt, is te traag en disruptief voor een snelle oplossing van verbindingspieken. Een EventBridge-regel om maxconnections te verhogen op basis van CPU-gebruik pakt de onderliggende oorzaak van te veel verbindingen niet aan en kan de database verder overbelasten.