Cuando una empresa migra sus funciones Lambda a un runtime más reciente, el temido error '/lib64/libc.so.6: version `GLIBC_2.28' not found' suele aparecer en el peor momento: durante un arranque en frío en producción, dejando sin servicio a usuarios críticos. Este problema no es un bug en el código, sino un desajuste entre la versión de glibc con la que fue compilada alguna dependencia nativa (como cryptography, numpy, pydantic-core, grpcio o un binario de Go/Rust empaquetado como capa) y la que ofrece el sistema base del runtime de Lambda. Al actualizar el runtime, las dependencias suelen recompilarse con una glibc más moderna —por ejemplo, la 2.34 de Amazon Linux 2023— y si la función sigue ejecutándose sobre un runtime basado en Amazon Linux 2 (glibc 2.26), el enlazador dinámico no encuentra los símbolos requeridos y la función muere al cargarse.
La raíz del problema es que Lambda no permite elegir la versión de glibc de forma independiente; va ligada al sistema operativo base de cada runtime. Los runtimes basados en Amazon Linux 2 (python3.9 y anteriores, nodejs16.x y anteriores) utilizan glibc 2.26, mientras que los basados en Amazon Linux 2023 (python3.12+, nodejs18.x+) incorporan glibc 2.34. Si una dependencia fue compilada en una máquina con glibc 2.28 o superior —algo habitual en CI modernos, imágenes manylinux recientes o entornos de desarrollo basados en AL2023— al desplegarla sobre un runtime AL2, el sistema operativo no encuentra la versión requerida. glibc es compatible hacia atrás, pero no hacia adelante: no se puede 'bajar' la versión de la librería sin recompilar desde origen.
Este escenario es especialmente frecuente durante migraciones parciales: mientras algunos equipos ya han movido sus funciones a python3.12 o nodejs22.x, otras permanecen en runtimes antiguos. El pipeline de CI/CD, al reconstruir las dependencias para todas las funciones, puede generar artefactos que solo funcionan con la glibc más nueva. El resultado: funciones que nunca tocamos empiezan a fallar en el siguiente arranque en frío. Para una empresa que gestiona decenas o cientos de funciones Lambda, este error puede escalar rápido y afectar la disponibilidad de servicios clave.
La solución más limpia y definitiva es completar la migración del runtime: pasar la función a un runtime basado en Amazon Linux 2023 (python3.12+, nodejs20.x, nodejs22.x). De esta forma, la glibc 2.34 del nuevo sistema satisface cualquier dependencia moderna. Además, se elimina el riesgo de usar un runtime que ya está en proceso de deprecación o bloqueo por parte de AWS. No obstante, si por razones de compatibilidad o planificación una función debe permanecer temporalmente en un runtime antiguo, existen estrategias alternativas.
Una opción es forzar la compilación de las dependencias para la plataforma manylinux2014, que tiene como objetivo glibc 2.17, una versión lo suficientemente antigua como para ejecutarse tanto en AL2 (2.26) como en AL2023 (2.34). Usando pip con las opciones --platform manylinux2014_x86_64 --only-binary=:all: --target ./package se obtienen wheels que funcionan en ambos entornos. Otra alternativa más segura es construir las dependencias dentro de la imagen base exacta del runtime Lambda que se va a usar en producción, por ejemplo ejecutando docker run --rm -v '$PWD':/var/task public.ecr.aws/lambda/python:3.9 pip install -r requirements.txt -t /var/task/package. Así el binario se enlaza contra la glibc real del runtime, eliminando cualquier conjetura.
Además del emparejamiento de glibc, hay que verificar la arquitectura. Un binario compilado para x86_64 no funcionará en una función Lambda con arquitectura arm64 (Graviton), y viceversa. El error será diferente (probablemente 'Exec format error' o similar), pero igualmente opaco. Asegurarse de que la plataforma de compilación coincida con la de despliegue es un paso que a menudo se pasa por alto.
Para evitar que este error llegue a producción, conviene realizar pruebas de arranque en frío locales usando la misma imagen base que se despliega. Ejecutar docker run public.ecr.aws/lambda/ ... con el código y dependencias empaquetados permite detectar el fallo antes de subirlo. También es recomendable auditar periódicamente las funciones que utilizan runtimes deprecados, ya que el riesgo de desajuste de glibc es solo un síntoma más de una deuda técnica mayor. Herramientas como el escáner gratuito de EOLkits pueden identificar en segundos qué funciones de tu cuenta tienen dependencias nativas en riesgo, sin necesidad de revisar cada paquete manualmente.
En Q2BSTUDIO, como empresa de desarrollo de software y tecnología, sabemos que este tipo de incidentes no solo afectan a la operativa diaria, sino que erosionan la confianza del negocio. Por eso, cuando ayudamos a nuestros clientes a migrar sus arquitecturas serverless, no solo resolvemos el error de glibc: revisamos todo el ecosistema de dependencias, la estrategia de cloud AWS/Azure y la madurez de los pipelines de CI/CD. Integramos IA en los procesos de monitorización para anticipar fallos antes de que impacten en producción, y aplicamos principios de ciberseguridad para evitar que una dependencia desactualizada se convierta en una puerta de entrada a vulnerabilidades.
La experiencia nos ha enseñado que el verdadero coste de un error como este no es solo el tiempo de inactividad, sino la necesidad de reaccionar bajo presión. Por eso recomendamos a las empresas que estén planificando la migración de sus runtimes Lambda que lo hagan de forma ordenada, usando un enfoque de aplicaciones a medida que contemple la compatibilidad de dependencias desde el principio. Un software a medida bien diseñado incluye tests de integración que simulan el entorno real de Lambda, no solo el de desarrollo local.
Además, la combinación de inteligencia artificial y automatización puede ayudar a detectar patrones de error antes de que afecten a los usuarios. En Q2BSTUDIO desarrollamos agentes IA que analizan logs de CloudWatch y métricas de Lambda para identificar funciones con alto riesgo de fallo en arranque en frío. Esto se une a nuestras soluciones de BI/Power BI, que permiten visualizar el estado de salud de toda la infraestructura serverless en tiempo real, facilitando la toma de decisiones informadas.
Por último, no olvidemos que la ciberseguridad es un pilar fundamental en cualquier estrategia cloud. Una dependencia nativa mal compilada no solo provoca errores de carga, sino que puede exponer la función a ataques si la versión de glibc o de la librería tiene vulnerabilidades conocidas. En Q2BSTUDIO integramos análisis de vulnerabilidades en nuestros pipelines de CI/CD como parte de nuestros servicios de ciberseguridad, garantizando que cada despliegue cumpla con los estándares de seguridad más exigentes.
En resumen, el error GLIBC_2.28 no encontrado en Lambda es un síntoma de una migración incompleta, pero también una oportunidad para mejorar la arquitectura y las prácticas de desarrollo. Completar la migración a runtimes basados en AL2023, construir dependencias en el entorno exacto de destino y auditar regularmente las funciones son pasos clave. Si tu empresa necesita apoyo técnico para afrontar estos desafíos, en Q2BSTUDIO ofrecemos consultoría y desarrollo especializado en cloud, IA, ciberseguridad y automatización, ayudando a transformar problemas operativos en ventajas competitivas.
