Une application e-commerce expose une API via Amazon API Gateway qui invoque des fonctions AWS Lambda. Les données sont stockées dans une instance de base de données Amazon RDS for PostgreSQL. Lors d'une vente flash, les appels d'API ont explosé et l'application a ralenti : CloudWatch a montré de nombreuses invocations Lambda, un grand nombre de connexions à la base de données et une utilisation élevée du CPU sur l'instance de base de données. Que devrait recommander l'architecte de solutions pour améliorer les performances ?

La bonne réponse est de créer un Amazon RDS Proxy et de mettre à jour la fonction Lambda pour se connecter via son point de terminaison. RDS Proxy gère efficacement les pools de connexions à la base de données, réutilisant les connexions existantes et réduisant la charge sur l'instance RDS. Cela résout directement le problème du grand nombre de connexions à la base de données et de l'utilisation élevée du CPU lors des pics de trafic. Augmenter la mémoire Lambda peut améliorer les performances de calcul mais ne résout pas le problème fondamental de la gestion des connexions à la base de données. Fermer les connexions immédiatement est une bonne pratique mais ne gère pas la mise en commun des connexions à grande échelle. Ajouter ElastiCache for Redis est une excellente solution pour la mise en cache et la réduction de la charge sur la base de données, mais le problème principal ici est la gestion des connexions et la surcharge de la base de données, que RDS Proxy adresse plus directement et avec moins de changements architecturaux immédiats. Modifier la fonction Lambda pour réutiliser une seule connexion est une bonne pratique de développement, mais elle est difficile à mettre en œuvre efficacement avec des fonctions Lambda sans état et ne fournit pas la même robustesse et évolutivité que RDS Proxy pour gérer des milliers de connexions simultanées.