Une fonction Lambda planifiée s'exécute actuellement sans accès VPC et récupère des jeux de données sur Internet. L'application va être modifiée de sorte que la fonction Lambda doive écrire dans une instance de base de données RDS située dans un sous-réseau privé. Le VPC dispose de deux sous-réseaux publics et de deux sous-réseaux privés. Quelle configuration permet à la fonction Lambda d'atteindre la base de données privée tout en ayant accès à Internet ?

La bonne approche consiste à activer l'accès VPC pour la fonction Lambda et à la placer dans les sous-réseaux privés où se trouve la base de données RDS. Cela permet à la fonction Lambda de communiquer directement avec la base de données via le réseau privé. Pour l'accès à Internet, des passerelles NAT doivent être déployées dans les sous-réseaux publics. Les tables de routage des sous-réseaux privés doivent être configurées pour diriger tout le trafic sortant (0.0.0.0/0) vers ces passerelles NAT. Enfin, un groupe de sécurité doit être attaché à la fonction Lambda pour autoriser l'accès sortant. Les options incorrectes sont les suivantes : Attacher la fonction Lambda à des sous-réseaux publics ne lui permettrait pas d'accéder directement à une base de données RDS dans un sous-réseau privé sans configuration supplémentaire complexe et moins sécurisée. Les adresses IP élastiques ne sont pas directement attachées aux fonctions Lambda. Attacher la fonction à des sous-réseaux publics avec des adresses IP publiques ne résout pas le problème d'accès à une base de données privée et expose la fonction inutilement. Acheminer le trafic Internet directement via une passerelle Internet depuis un sous-réseau privé n'est pas possible sans une passerelle NAT, car les instances dans les sous-réseaux privés n'ont pas d'adresses IP publiques et ne peuvent pas initier de connexions directes à Internet.