When a company migrates its Lambda functions to a newer runtime, the dreaded error '/lib64/libc.so.6: version `GLIBC_2.28' not found' often strikes at the worst moment: during a cold start in production, leaving critical users without service. This issue is not a bug in your code, but a mismatch between the glibc version used to compile a native dependency (such as cryptography, numpy, pydantic-core, grpcio, or a Go/Rust binary packaged as a layer) and the one provided by the Lambda runtime's base OS. When you upgrade the runtime, dependencies are often rebuilt with a newer glibc — for example, 2.34 from Amazon Linux 2023 — and if the function still runs on an Amazon Linux 2-based runtime (glibc 2.26), the dynamic linker cannot find the required symbols, causing the function to fail on load.
The root cause is that Lambda does not let you choose the glibc version independently; it is tied to the base OS of each runtime. Runtimes based on Amazon Linux 2 (python3.9 and earlier, nodejs16.x and earlier) use glibc 2.26, while those based on Amazon Linux 2023 (python3.12+, nodejs18.x+) bundle glibc 2.34. If a dependency was compiled on a machine with glibc 2.28 or higher — common in modern CI runners, recent manylinux images, or AL2023-based development environments — deploying it on an AL2 runtime will fail because the OS lacks the required version. glibc is backward compatible, but not forward compatible: you cannot 'downgrade' the library without recompiling from source.
This scenario is especially common during partial migrations: while some teams have already moved their functions to python3.12 or nodejs22.x, others remain on older runtimes. The CI/CD pipeline, when rebuilding dependencies for all functions, may produce artifacts that only work with the newer glibc. The result: functions we never touched start failing on the next cold start. For a company managing dozens or hundreds of Lambda functions, this error can escalate quickly and affect the availability of key services.
The cleanest and most definitive solution is to complete the runtime migration: move the function to a runtime based on Amazon Linux 2023 (python3.12+, nodejs20.x, nodejs22.x). This way, the glibc 2.34 of the new system satisfies any modern dependency. Additionally, it eliminates the risk of using a runtime that is already deprecated or heading toward a block window by AWS. However, if for compatibility or planning reasons a function must remain temporarily on an older runtime, alternative strategies exist.
One option is to force dependency compilation for the manylinux2014 platform, which targets glibc 2.17 — old enough to run on both AL2 (2.26) and AL2023 (2.34). Using pip with the options --platform manylinux2014_x86_64 --only-binary=:all: --target ./package yields wheels that work in both environments. Another safer alternative is to build dependencies inside the exact Lambda base image that will be used in production, for example by running docker run --rm -v '$PWD':/var/task public.ecr.aws/lambda/python:3.9 pip install -r requirements.txt -t /var/task/package. This links the binary against the real glibc of the runtime, eliminating any guesswork.
Besides glibc alignment, you must verify the architecture. A binary compiled for x86_64 will not work on a Lambda function with arm64 architecture (Graviton), and vice versa. The error will be different (likely 'Exec format error' or similar), but equally opaque. Ensuring that the build platform matches the deployment target is a step often overlooked.
To prevent this error from reaching production, it is advisable to perform local cold-start tests using the same base image you deploy. Running docker run public.ecr.aws/lambda/ ... with the packaged code and dependencies allows you to detect the failure before uploading. It is also recommended to periodically audit functions that use deprecated runtimes, since the glibc mismatch risk is just one symptom of a larger technical debt. Tools like the free scanner from EOLkits can identify in seconds which functions in your account have native dependencies at risk, without needing to inspect each package manually.
At Q2BSTUDIO, as a software development and technology company, we know that incidents like this not only affect daily operations but also erode business trust. That is why when we help our clients migrate their serverless architectures, we do not just fix the glibc error: we review the entire dependency ecosystem, the cloud AWS/Azure strategy, and the maturity of CI/CD pipelines. We integrate AI into monitoring processes to anticipate failures before they impact production, and we apply cybersecurity principles to prevent an outdated dependency from becoming an entry point for vulnerabilities.
Experience has taught us that the true cost of an error like this is not just downtime, but the need to react under pressure. That is why we recommend that companies planning their Lambda runtime migration do so in an orderly fashion, using a custom software approach that considers dependency compatibility from the start. A well-designed custom software includes integration tests that simulate the real Lambda environment, not just the local development setup.
Furthermore, the combination of artificial intelligence and automation can help detect error patterns before they affect users. At Q2BSTUDIO we develop AI agents that analyze CloudWatch logs and Lambda metrics to identify functions with a high risk of cold-start failure. This ties into our BI/Power BI solutions, which allow you to visualize the health status of your entire serverless infrastructure in real time, facilitating informed decision-making.
Finally, let's not forget that cybersecurity is a fundamental pillar in any cloud strategy. A poorly compiled native dependency not only causes load errors but can also expose the function to attacks if the glibc or library version has known vulnerabilities. At Q2BSTUDIO we integrate vulnerability analysis into our CI/CD pipelines as part of our cybersecurity services, ensuring that every deployment meets the most stringent security standards.
In summary, the GLIBC_2.28 not found error in Lambda is a symptom of an incomplete migration, but also an opportunity to improve architecture and development practices. Completing the migration to AL2023-based runtimes, building dependencies in the exact target environment, and regularly auditing functions are key steps. If your company needs technical support to face these challenges, at Q2BSTUDIO we offer consulting and specialized development in cloud, AI, cybersecurity, and automation, helping to turn operational problems into competitive advantages.
