Un développeur migre des fonctionnalités d'un monolithe existant vers AWS Lambda. Les données de l'application résident dans un cluster de base de données Amazon Aurora situé dans des sous-réseaux privés d'un VPC. Le compte possède un seul VPC ; les fonctions Lambda et le cluster de base de données se trouvent dans la même région AWS et le même compte. Les fonctions Lambda doivent accéder au cluster de base de données de manière sécurisée sans traverser l'internet public. Quelle configuration répond à cette exigence ?

La bonne réponse est de configurer les fonctions Lambda pour qu'elles s'exécutent dans le même VPC en spécifiant le VPC, les sous-réseaux appropriés et un groupe de sécurité. Cela permet aux fonctions Lambda d'accéder au cluster Aurora en privé via le réseau interne du VPC, sans passer par l'internet public. Le groupe de sécurité associé à la fonction Lambda doit autoriser le trafic sortant vers le groupe de sécurité du cluster Aurora sur le port de la base de données, et le groupe de sécurité du cluster Aurora doit autoriser le trafic entrant depuis le groupe de sécurité de la fonction Lambda. Définir le paramètre d'accès public du cluster de base de données sur Oui exposerait la base de données à l'internet public, ce qui est une faille de sécurité. Configurer un Amazon RDS Proxy est une bonne pratique pour la gestion des connexions, mais cela ne résout pas le problème de l'accès privé depuis Lambda si Lambda n'est pas dans le VPC. Déployer une passerelle NAT est inutile ici car la passerelle NAT est utilisée pour permettre aux ressources privées d'un VPC d'accéder à Internet, et non pour permettre aux ressources du VPC de communiquer entre elles en privé.