Cuando actualizas el runtime de una función Lambda, por ejemplo de Python 3.9 a Python 3.12 o de Node.js 16 a Node.js 18, puedes encontrarte con un error aparentemente inesperado al ejecutar una invocación en frío: /lib64/libc.so.6: version `GLIBC_2.28' not found. El mensaje indica que una biblioteca nativa (como un wheel de Python o un addon .node) no puede cargarse porque fue enlazada contra una versión más reciente de glibc que la disponible en el sistema operativo base del runtime. El código de tu aplicación no ha cambiado, pero la actualización del runtime modifica la capa de compatibilidad subyacente. Este problema no es un bug en tu lógica, sino una discrepancia entre la versión de glibc con la que se compiló el binario y la que ofrece el entorno de ejecución.
Para entender el origen, hay que mirar las imágenes base que utiliza AWS Lambda. Los runtimes más antiguos, como Python 3.9 y Node.js 16.x, se ejecutan sobre Amazon Linux 2 (AL2), que incorpora glibc 2.26. Los runtimes más modernos, como Python 3.12 y Node.js 20.x, usan Amazon Linux 2023 (AL2023), que trae glibc 2.34. Cuando instalas una dependencia con una extensión nativa —por ejemplo, cryptography, numpy, pydantic-core, grpcio o psycopg2—, el binario se enlaza contra la glibc de la máquina donde se compiló. Si tu pipeline de CI/CD utiliza un runner moderno con una glibc más reciente (como Ubuntu 22.04 con glibc 2.35) y descargas un wheel manylinux_2_28, ese binario pedirá GLIBC_2.28, que no existe en AL2. El resultado es un error en tiempo de importación que solo aparece cuando el contenedor Lambda arranca desde cero, es decir, en un cold start.
Este fallo se manifiesta con mayor frecuencia durante migraciones parciales de runtime. Imagina que en tu cuenta de AWS tienes funciones Lambda repartidas entre runtimes antiguos y nuevos. Un equipo actualiza el pipeline de integración continua para construir los paquetes de dependencias usando una imagen base de AL2023 o un runner con glibc moderna. Las funciones que todavía se ejecutan en AL2 empiezan a fallar al siguiente despliegue, aunque su código no haya cambiado. El impacto puede ser grave: interrupción del servicio en producción, errores difíciles de depurar y pérdida de confianza en el proceso de actualización.
La solución definitiva es completar la migración a un runtime basado en AL2023, como Python 3.12 o Node.js 20.x en adelante. Al hacerlo, la glibc 2.34 del nuevo sistema operativo es suficiente para cualquier wheel moderno. Además, te adelantas a las políticas de deprecación de AWS: los runtimes antiguos tienen fechas de bloqueo programadas, y mantener funciones en ellos supone un riesgo de seguridad y de disponibilidad. Si por razones de compatibilidad o roadmap necesitas mantener una función en un runtime antiguo durante un tiempo, puedes forzar la construcción de las dependencias para la plataforma manylinux2014_x86_64, que exige glibc 2.17 como mínimo. Ese binario funcionará tanto en AL2 (glibc 2.26) como en AL2023 (glibc 2.34). Por ejemplo, usando pip install --platform manylinux2014_x86_64 --only-binary=:all: --target ./package . También puedes construir dentro de la imagen base exacta del runtime Lambda mediante Docker: docker run --rm -v '$PWD':/var/task public.ecr.aws/lambda/python:3.9 pip install -r requirements.txt -t /var/task/package. Este método garantiza que los binarios se enlacen contra la misma glibc que tendrán en producción.
No olvides verificar la arquitectura del procesador. Las funciones Lambda pueden ejecutarse en x86_64 o arm64 (Graviton). Un binario compilado para la arquitectura incorrecta generará un error diferente pero igualmente opaco. Asegúrate de que tu pipeline utilice la plataforma y arquitectura adecuadas: manylinux2014_aarch64 para arm64, por ejemplo. En entornos empresariales donde se gestionan decenas o cientos de funciones Lambda, detectar estos problemas antes de que lleguen a producción es crítico. Una práctica recomendada es realizar pruebas de cold start local utilizando la misma imagen base que despliegas: docker run public.ecr.aws/lambda/ .... También puedes auditar tus funciones buscando dependencias nativas que puedan generar conflictos de glibc. Herramientas de análisis de riesgos en la nube, como las que ofrecemos en Q2BSTUDIO, pueden escanear tu cuenta de AWS en segundos para identificar funciones con runtimes obsoletos y posibles incompatibilidades ABI.
En Q2BSTUDIO somos una empresa de desarrollo de software y tecnología especializada en la nube de AWS y Azure. Ayudamos a nuestras empresas clientes a migrar sus arquitecturas serverless de forma segura, evitando este tipo de errores mediante buenas prácticas de construcción y despliegue. Nuestro equipo integra soluciones de aplicaciones a medida con un enfoque cloud-native, utilizando inteligencia artificial para automatizar la detección de anomalías y agentes de IA que monitorizan la salud de tus funciones Lambda. Además, combinamos estas capacidades con servicios de ciberseguridad para proteger tus entornos serverless, y con soluciones cloud en AWS y Azure que garantizan que cada despliegue cumpla con los requisitos de compatibilidad y rendimiento. También ofrecemos consultoría en Business Intelligence con Power BI para analizar los logs de Lambda y anticipar incidentes como el error GLIBC 2.28. Nuestros agentes de IA pueden incluso sugerir automáticamente la versión de runtime más adecuada para cada función basándose en su árbol de dependencias.
Si estás en medio de una migración de runtime y te encuentras con este error, recuerda que no es un problema de código, sino de entorno. La solución más limpia es finalizar la migración a AL2023. Si necesitas un parche temporal, construye tus dependencias con manylinux2014 o dentro de la imagen base correcta. Y para evitar sorpresas, automatiza las pruebas de cold start y la auditoría de compatibilidad. En Q2BSTUDIO te acompañamos en todo el proceso, desde el análisis inicial hasta la implantación de un pipeline de CI/CD robusto que gestione automáticamente las versiones de glibc y las arquitecturas. No dejes que un error de enlace dinámico detenga tu innovación en la nube.
