A Lambda .zip package can be 50 MB zipped when uploaded through the API or SDKs and 250 MB unzipped, counting layers. Container image functions can be up to 10 GB uncompressed. Staying well under those numbers is good practice, because every extra package is more code to patch.
The limits that apply
From AWS's Lambda quotas page:
| Item | Documented quota |
|---|---|
| .zip package, uploaded via API or SDKs | 50 MB zipped |
| .zip package contents, including layers and custom runtimes | 250 MB unzipped |
| Layers per function | 5 |
| Container image code package | 10 GB uncompressed, including all layers |
| /tmp storage | 512 MB to 10,240 MB |
AWS also notes you can upload larger zip files through Amazon S3. Check the quotas page for your Region before planning, since values can be raised or changed.
Why trimming is a security habit
Bundle weight is a proxy for attack surface. A package you never call still sits in the artifact, still shows up in scanners, and still needs an owner when an advisory appears. Trimming reduces noise as well as bytes.
What to remove first
- Development dependencies. Test frameworks, linters and type tooling do not belong in a production zip. Install production dependencies only when you build the package.
- Duplicate copies. Two versions of the same library often arrive through different parents. Align them.
- Runtime-included libraries you do not need to override. AWS notes that the Node.js runtime includes version 3 of the AWS SDK for JavaScript and that Lambda periodically updates it, though you can bundle your own version for full control. Decide on purpose which you want. See whether to bundle the AWS SDK.
- Large packages used for one function. Replace with a smaller import or your own few lines, except for security-sensitive code.
- Unused files in packages. Docs, tests, sample data and source maps add bytes without value.
Do not trim by hiding
Moving code out of the zip to meet a limit can make it invisible to review. Downloading packages at start up is the common example, and it is covered in why you should not install packages at cold start. Anything the function runs should be in the build, the scan and the inventory.
A repeatable trim routine
- Build the package in CI from the lockfile.
- Record the zipped and unzipped sizes as build output.
- Fail the build if the size jumps by an agreed percentage without a note.
- List the ten largest packages in the artifact each release.
- Review that list quarterly and ask what each one is for.
Try it yourself
Open the dependency inventory demo and look for packages that appear under a single service and carry many transitive entries. Those are your best trim candidates.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning show every package in a build, direct and transitive, so the trim list is data instead of a guess. Reachability analysis helps rank findings by whether your code calls the vulnerable path. Free scan: gold.safeguard.sh/scan.
Quick check
Do layers count toward the 250 MB limit?
Yes. AWS lists 250 MB unzipped as the maximum size of the deployment package contents, including layers and custom runtimes.
Does a container image avoid size worries?
The limit is much higher, at 10 GB uncompressed, but a larger image still means more packages to patch.
Sources
- Lambda quotas, AWS documentation
- Deploy Node.js Lambda functions with .zip file archives, AWS documentation
Last reviewed: 19 October 2026.
