Problema
Al utilizar AWS Lambda para nuestros servicios, podemos encontrarnos con un escenario común: el código fuente de la función no cambia, pero sí se actualiza alguna de las dependencias, ya sea una librería propia o de terceros; el asunto cambia un poco.
En estos casos, es necesario forzar un nuevo despliegue para que la función incorpore los cambios. Sin embargo, AWS Lambda no genera una nueva versión si no detecta modificaciones en el código fuente, lo que puede provocar que la función siga ejecutándose con dependencias desactualizadas, aun cuando estas hayan sido modificadas o recompiladas.
Contexto
Cabe destacar que este problema se ha presentado utilizando las siguientes herramientas (aunque es probable que también ocurra con otras configuraciones o tecnologías):
- Node.js v22.15.0
- Se usa alias y versions de aws lambda y se usa una version alias (prod)
Solución
Variables de entorno
También es importante mencionar que agregar o modificar dinámicamente una variable de entorno podría parecer una solución al problema; sin embargo, esto no lo resuelve.
AWS Lambda no detecta cambios cuando únicamente se modifica el valor de una variable de entorno, por lo que no se publica una nueva versión de la función, manteniéndose el mismo artefacto desplegado.
Solución aplicada
Una de las soluciones es usar la propiedad AutoPublishCodeSha256 en la definición de AWS Lambda:
Una de las soluciones consiste en utilizar la propiedad AutoPublishCodeSha256 en la definición de la función AWS Lambda.
Esta propiedad corresponde a un hash del artefacto de despliegue; mientras su valor no cambie, AWS Lambda no publicará una nueva versión, incluso si el despliegue es ejecutado nuevamente.
Por lo tanto, es indispensable que este valor se actualice para forzar la publicación de una nueva versión. Si el código o las dependencias cambian pero el valor de AutoPublishCodeSha256 permanece igual, la nueva versión de la función no será desplegada.
Con este cambio se introduce una configuración que inyecta un valor dinámico en cada despliegue, garantizando que AWS Lambda detecte el cambio y publique una nueva versión.
No obstante, es importante destacar que, aunque las librerías no hayan cambiado, esta solución provoca igualmente la creación de un nuevo Layer, ya que se estaría actualizando la versión definida en el package.json.
En términos generales, esto no representa un inconveniente siempre que se cuente con un buen ciclo de vida y una correcta gestión de los layers, eliminando o descontinuando aquellos que ya no están en uso.
Otras posibles soluciones
Otra alternativa, simple y directa, consiste en utilizar la propiedad PublishLambdaVersion en el recurso del layer (AWS::Serverless::LayerVersion). No obstante, según el comportamiento actual de AWS SAM, tanto la definición del layer como la de la función Lambda deben encontrarse dentro del mismo manifiesto (template.yaml); de lo contrario, la publicación de una nueva versión no se ejecuta correctamente. Para más detalles sobre esta limitación, se puede revisar el siguiente issue:
https://github.com/aws/serverless-application-model/issues/3802
En mi caso particular, esta solución no funcionó debido a que manejo múltiples manifiestos de CloudFormation. El layer está definido en un template de nivel superior y es compartido por varias funciones Lambda, lo cual impide aprovechar esta propiedad en dicho escenario.
Cierre
Con alguna de las configuraciones mencionadas aseguras que cada cambio en tu Layer, ya sea una actualización de dependencias, un parche de seguridad o una nueva librería, desencadene automáticamente una nueva versión de tu función Lambda que apunte al Layer actualizado. Esto elimina la brecha entre lo que despliegas y lo que realmente se ejecuta en producción, garantizando que tus funciones siempre utilicen las versiones correctas de las dependencias sin intervención manual. El resultado: deploys predecibles, menos bugs ocultos y la tranquilidad de saber que lo que probaste localmente es exactamente lo que está corriendo en AWS.
Top comments (0)