Une entreprise utilise des fonctions AWS Lambda pour automatiser la réponse aux incidents pour les instances Amazon EC2. Les fonctions collectent des artefacts (par exemple, l'ID d'instance et la configuration du groupe de sécurité) et écrivent un résumé dans un compartiment Amazon S3. Le VPC de l'entreprise dispose de sous-réseaux publics avec une passerelle Internet et de sous-réseaux privés avec une passerelle NAT. Tout le trafic S3 lié à la réponse aux incidents doit rester sur le réseau AWS et ne doit pas transiter par l'Internet public. Quelle solution répond à ces exigences ?

La bonne réponse est de déployer les fonctions Lambda dans des sous-réseaux privés et de créer un point de terminaison de VPC de passerelle S3. Les fonctions Lambda dans un sous-réseau privé nécessitent un moyen d'accéder à S3 sans passer par l'Internet public. Un point de terminaison de passerelle S3 permet aux fonctions d'accéder à S3 de manière privée et sécurisée via le réseau AWS. Déployer les fonctions Lambda dans des sous-réseaux privés et acheminer le trafic S3 via la passerelle NAT est incorrect car la passerelle NAT enverrait le trafic vers l'Internet public, ce qui contredit l'exigence. Placer le compartiment S3 et les fonctions Lambda dans le même sous-réseau privé et utiliser le point de terminaison public Amazon S3 par défaut est incorrect car S3 est un service public et n'est pas lié à un sous-réseau VPC spécifique. L'utilisation du point de terminaison public par défaut enverrait le trafic sur l'Internet public. Déployer une file d'attente Amazon SQS et les fonctions Lambda dans le même sous-réseau privé et configurer la file d'attente pour livrer les données au compartiment S3 est incorrect. SQS est un service de messagerie et ne résout pas le problème d'accès privé à S3 pour les fonctions Lambda. De plus, SQS devrait lui-même accéder à S3, ce qui nécessiterait également un point de terminaison VPC.