Neither is easier in every case. A .zip function on a managed runtime receives runtime patches automatically from Lambda, while you update dependencies. A container image gives identical versions everywhere but you must rebuild from the latest base image and redeploy. Choose by who you want to do the patching.
What AWS says each model asks of you
From the shared responsibility table in the Lambda documentation:
| Model | Lambda's job | Your job |
|---|---|---|
| .zip on a managed runtime | Publish runtime updates and apply them automatically by default | Update your function code and dependencies |
| Container image | Publish updated base images | Update dependencies, and regularly rebuild and redeploy from the latest base image |
In both models, dependencies are yours. The difference is whether the operating system and language runtime update by themselves.
Where each model shines
.zip with a managed runtime
- Runtime security updates roll out automatically, so idle functions still get them in the second phase of the rollout.
- Deprecation emails, Health Dashboard notices and Trusted Advisor checks tell you when a runtime is ending.
- Layers let you share dependencies, up to five per function.
Container image
- You control the image, which AWS recommends if you need guaranteed runtime version consistency across environments, because managed runtime versions roll out gradually across regions.
- The code package can be up to 10 GB uncompressed, versus 250 MB unzipped for a .zip.
- The image is a clear, scannable artifact with its own layers.
Where each one bites
- A .zip can drift between regions by a runtime version if you deploy at different times.
- A container image that nobody rebuilds goes stale. AWS notes that deprecation notifications are not available for container image functions, so you must watch base image dates yourself.
- Layers are not available for container image functions. AWS says to package the runtime and all dependencies in the image.
- Switching later is a rebuild: you cannot change the package type of an existing function, so you create a new function.
A decision guide
- Small functions, frequent deploys, standard runtime: .zip on a managed runtime.
- Large dependencies, custom system libraries or strict version consistency: container image.
- Many teams sharing a library: a layer for .zip, a shared base image for containers.
- A team without a rebuild schedule: .zip, because Lambda patches the runtime for you.
- A team with an image pipeline and scanning: container image works well.
If you pick containers, schedule the rebuilds
Set a regular rebuild that pulls the latest base image even when your code is unchanged, scan the result, and redeploy through an alias. Track base image end of support dates alongside your own releases.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the findings by layer. A container based function gives you this view, and a rebuild clears base layer findings.
Quick check
Can I convert a zip function to a container image?
Not in place. AWS says you cannot change the package type of an existing function, so you create a new function.
Does Lambda rebuild my container image?
No. For container image functions you are responsible for rebuilding from the latest base image and redeploying.
Safeguard's container image scanning and SBOM generation help you see what each build contains. Try a free scan at gold.safeguard.sh/scan.
Sources
- AWS Lambda runtimes and shared responsibility
- How Lambda manages runtime version updates
- Lambda layers
- Lambda quotas
- Python deployment packages for Lambda
Last reviewed: 19 October 2026.
