Install wheels built for Linux and your function's architecture, using pip's platform, python-version and only-binary options, into a package directory, then zip it. Packages with C or C++ code built on your laptop may not run on Lambda, and the lockfile you scan should match what you ship.
Why architecture matters
AWS explains that many popular Python libraries, including NumPy and Pandas, are not pure Python and contain compiled code. Most packages on PyPI come as wheels, which are built distributions with pre compiled binaries for a particular operating system and instruction set. To be compatible with Lambda you need the wheel for Linux and for your function's architecture, x86_64 or arm64.
From a security view this matters twice. A wrong architecture build fails at run time, which pushes teams toward quick fixes such as building from source on whatever machine is handy. And the binary you ship is the thing you must be able to describe later.
The steps
- Pick the runtime and architecture for the function, for example Python 3.14 on arm64.
- Install matching wheels into a package folder. For arm64, AWS shows:
pip install \
--platform manylinux2014_aarch64 \
--target=package \
--implementation cp \
--python-version 3.14 \
--only-binary=:all: --upgrade \
your-package
For x86_64, swap the platform for manylinux2014_x86_64.
- Zip the contents of the package folder, with your handler file at the root of the zip.
- If a dependency has no wheel, AWS says you must build its C or C++ parts yourself in an Amazon Linux environment such as an EC2 instance, so that it matches the execution environment.
- Leave out pycache folders. AWS advises against including them, because bytecode compiled on a different architecture or operating system may not be compatible.
- Check the size. A .zip deployment package is limited to 250 MB unzipped, counting layers.
- Generate a software bill of materials from the same lockfile and archive it with the build.
What to record
| Item | Why |
|---|---|
| Runtime identifier and architecture | A rebuild must target the same pair |
| Exact versions of every package, direct and transitive | Needed to answer a new advisory quickly |
| Wheel file names or hashes | Shows which binary you shipped |
| Build date and builder | Evidence for later review |
| Source builds, if any | These deserve extra scrutiny |
Hash pinning and trust
Using the only-binary option stops pip from running build scripts for source distributions during this install, which removes one category of surprise. It also means a package without a wheel fails loudly rather than compiling on your machine. Treat that failure as a decision point: either find a package that ships a wheel, or build in a controlled environment and review what you built.
Rebuild for the next runtime too
When a runtime reaches deprecation you change the runtime identifier, and compiled wheels may need rebuilding for the new Python version. Put that into the upgrade plan rather than discovering it on the block update date.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the version column for each package. That is the record you want archived for every build.
Quick check
Can I build the zip on my laptop?
Yes for pure Python packages. For compiled packages, install the correct Linux wheels with the platform flags, or build in a matching Amazon Linux environment.
Does AWS patch the libraries in my zip?
No. AWS says that under shared responsibility you manage the dependencies in your deployment package, including updates and security patches.
Safeguard's SBOM and dependency scanning can read your lockfile and flag vulnerable versions before you build the zip. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
