Pour réduire les risques lors de la publication d'une nouvelle version d'une fonction Lambda existante, vous devez répartir le trafic entre la version actuelle et la nouvelle version pour les tests. Quelle approche répond à cette exigence ?

La bonne approche est de créer un alias de fonction et de le configurer pour distribuer le trafic entre les deux versions de Lambda. Les alias de fonction Lambda vous permettent de pointer vers une version spécifique de votre fonction et de configurer un routage de trafic basé sur le poids entre deux versions. Cela est idéal pour les déploiements canary ou les tests A/B, car vous pouvez progressivement acheminer le trafic vers la nouvelle version tout en surveillant les performances. Utiliser une politique de routage pondéré dans Route 53 n'est pas la bonne approche car Route 53 gère le routage au niveau du DNS vers des points de terminaison, pas le routage interne entre les versions d'une fonction Lambda. Placer un Application Load Balancer devant la fonction Lambda n'est pas non plus la solution la plus efficace ou la plus idiomatique pour cette tâche spécifique, car Lambda a des mécanismes intégrés pour la gestion des versions et du trafic. Enfin, packager la nouvelle version en tant que couche Lambda est incorrect car les couches sont utilisées pour gérer les dépendances et le code partagé, et non pour le routage du trafic entre les versions d'une fonction.