Una aplicación web serverless se implementa con funciones Lambda a través de CloudFormation. Una versión reciente causó una interrupción. El proceso de implementación debe admitir lanzamientos de tipo "canary" para desviar una parte del tráfico a una nueva versión de Lambda. ¿Qué enfoque logra esto?

La opción correcta es crear un alias para cada versión de Lambda y usar el comando update-alias con el parámetro routing-config. Los alias de Lambda permiten apuntar a diferentes versiones de una función y configurar un enrutamiento ponderado para dividir el tráfico entre dos versiones. Esto es ideal para despliegues canary, ya que permite desviar un pequeño porcentaje del tráfico a la nueva versión, monitorearla y, si es estable, aumentar gradualmente el tráfico. Las otras opciones son incorrectas porque: Implementar en un stack separado y usar Route 53 para enrutamiento ponderado es más complejo y no aprovecha la funcionalidad nativa de Lambda para el control de versiones y el enrutamiento de tráfico. El comando update-function-configuration no tiene un parámetro routing-config para dividir el tráfico entre versiones; esta funcionalidad se gestiona a través de los alias. AWS CodeDeploy puede gestionar despliegues canary para Lambda, pero la opción específica CodeDeployDefault.OneAtATime es para despliegues secuenciales, no para el enrutamiento de tráfico gradual que se necesita en un canary.