Een e-commerce applicatie exposeert een API via Amazon API Gateway die AWS Lambda-functies aanroept. Gegevens worden opgeslagen in een Amazon RDS for PostgreSQL DB-instance. Tijdens een flash sale piekten de API-aanroepen en vertraagde de applicatie: CloudWatch toonde veel Lambda-invocaties, een groot aantal databaseverbindingen en een hoge CPU op de DB-instance. Wat moet de solutions architect aanbevelen om de prestaties te verbeteren?

De juiste oplossing is het gebruik van Amazon RDS Proxy. Een RDS Proxy beheert automatisch een pool van databaseverbindingen en hergebruikt deze, wat het aantal open verbindingen met de RDS-database aanzienlijk vermindert. Dit is cruciaal bij veel Lambda-invocaties, omdat elke Lambda-invocatie anders een nieuwe verbinding zou kunnen openen, wat leidt tot een overschot aan verbindingen en hoge CPU-belasting op de database. De integratie via de Lambda-console vereenvoudigt de configuratie. Het verhogen van Lambda-geheugen helpt niet direct met databaseverbindingen. Het sluiten van verbindingen in de code kan overhead veroorzaken bij elke aanroep. Een ElastiCache-cluster kan de database-belasting verminderen, maar lost het onderliggende probleem van het grote aantal databaseverbindingen niet op en vereist code-aanpassingen voor caching-logica. Het hergebruiken van een enkele verbinding buiten de handler is een goede praktijk, maar RDS Proxy biedt een robuustere en schaalbaardere oplossing voor connection pooling, vooral bij onvoorspelbare pieken.