Le site web de commerce électronique d'une entreprise a un trafic imprévisible et utilise des fonctions AWS Lambda pour accéder directement à une instance de base de données privée Amazon RDS for PostgreSQL. L'entreprise souhaite des performances de base de données prévisibles et veut s'assurer que les invocations Lambda ne surchargent pas la base de données avec trop de connexions. Que doit faire un architecte de solutions pour répondre à ces exigences ?

La bonne réponse est de pointer le pilote client vers un point de terminaison de proxy RDS et de déployer les fonctions Lambda à l'intérieur d'un VPC. Amazon RDS Proxy est un service entièrement géré qui établit et maintient un pool de connexions à la base de données, réduisant ainsi la surcharge de connexion pour la base de données RDS. Il gère également le multiplexage des connexions, permettant à de nombreuses invocations Lambda d'utiliser un nombre limité de connexions à la base de données, ce qui assure des performances prévisibles et empêche la surcharge de la base de données. Déployer les fonctions Lambda à l'intérieur d'un VPC leur permet d'accéder directement à l'instance RDS privée sans passer par l'internet public, améliorant ainsi la sécurité et réduisant la latence. Les autres options sont incorrectes car : Un point de terminaison personnalisé RDS n'offre pas les capacités de pooling et de multiplexage des connexions nécessaires pour gérer un trafic imprévisible et éviter la surcharge de la base de données. Déployer les fonctions Lambda à l'extérieur d'un VPC ne leur permettrait pas d'accéder à une instance RDS privée, à moins d'utiliser des mécanismes plus complexes et moins sécurisés comme les passerelles NAT ou les points de terminaison VPC.