Une entreprise utilise un compte AWS pour l'ingénierie logicielle. Le compte a accès au centre de données sur site de l'entreprise via une paire de connexions AWS Direct Connect. Tout le trafic non-VPC est acheminé vers la passerelle privée virtuelle. Une équipe de développement a créé une fonction AWS Lambda via la console. L'équipe doit permettre à la fonction d'accéder à une base de données qui s'exécute dans un sous-réseau privé du centre de données de l'entreprise. Quelle solution répondra à ces exigences ?

Pour permettre à une fonction Lambda d'accéder à des ressources dans un centre de données sur site via Direct Connect, la fonction doit être configurée pour s'exécuter dans un VPC. En plaçant la fonction Lambda dans le VPC, elle peut utiliser les routes existantes du VPC qui dirigent le trafic vers le centre de données via Direct Connect. Le groupe de sécurité approprié garantira que la fonction Lambda a l'autorisation réseau nécessaire pour communiquer avec la base de données. Les autres options sont incorrectes car : Établir une connexion VPN supplémentaire est redondant et inutile puisque Direct Connect est déjà en place. Mettre à jour les tables de routage dans le VPC est nécessaire, mais ne suffit pas à lui seul ; la fonction Lambda doit d'abord être dans le VPC pour utiliser ces routes. Créer une adresse IP Elastic ne permet pas à la fonction Lambda d'accéder aux ressources sur site ; les adresses IP Elastic sont utilisées pour l'accès public à Internet ou pour une adresse IP statique publique pour une instance EC2, pas pour l'accès privé à un centre de données.