Un développeur déploie un code Lambda mis à jour qui suit l'activité en ligne des utilisateurs. L'application web invoque la fonction Lambda via l'AWS SDK. Le développeur souhaite qu'un faible pourcentage seulement des requêtes invoquées par le SDK appellent le nouveau code, tandis que la plupart continuent d'appeler le code original. Quelle approche satisfait cette exigence ?

La bonne réponse est de créer un alias pour la fonction Lambda et de le configurer avec un routage pondéré. Les alias Lambda permettent de diriger un pourcentage spécifique du trafic vers différentes versions d'une fonction, ce qui est idéal pour les déploiements canary ou les tests A/B. Dans ce cas, le développeur peut diriger un faible pourcentage vers la nouvelle version et le reste vers l'ancienne. Créer une version Lambda et lui attribuer un poids spécifique n'est pas une option directe ; les poids sont appliqués aux alias, pas aux versions elles-mêmes. Les Application Load Balancers (ALB) et Network Load Balancers (NLB) ne sont pas les mécanismes appropriés pour gérer le routage du trafic entre différentes versions d'une fonction Lambda invoquée directement via le SDK. Ils sont utilisés pour distribuer le trafic HTTP/TCP vers des cibles comme des instances EC2 ou des fonctions Lambda via des URL, mais pas pour le contrôle de version interne des invocations SDK.