Une entreprise doit s'intégrer à un flux de données tiers qui envoie un webhook lorsque de nouvelles données sont prêtes. Un développeur a écrit une fonction AWS Lambda pour récupérer les données lorsqu'un rappel de webhook arrive. Le développeur doit rendre la fonction Lambda disponible pour que le tiers puisse l'appeler avec la PLUS GRANDE efficacité opérationnelle. Quelle solution répond à ces exigences ?

La création d'une URL de fonction Lambda est la solution la plus efficace sur le plan opérationnel car elle fournit un point d'accès HTTP(S) dédié et public directement à la fonction Lambda, sans nécessiter de services AWS supplémentaires. Cela simplifie l'architecture et réduit la complexité de la gestion. Déployer un Application Load Balancer (ALB) devant la fonction Lambda ajouterait une couche de complexité et de coût inutile pour ce cas d'utilisation simple, car l'ALB est généralement utilisé pour distribuer le trafic vers plusieurs cibles. Créer une rubrique Amazon SNS ou une file d'attente Amazon SQS ne convient pas car ces services sont des systèmes de messagerie asynchrones. Le tiers a besoin d'un point de terminaison HTTP(S) direct pour envoyer un webhook, et non d'un mécanisme de publication/abonnement ou de file d'attente. De plus, les rubriques SNS et les files d'attente SQS n'exposent pas de "nom d'hôte public" dans le sens d'un point de terminaison de webhook HTTP(S) direct pour un tiers.