Not in place. AWS states you cannot change the deployment package type of an existing function, so a zip function cannot become a container image function. You create a new function, move traffic to it, then retire the old one. Plan the cutover so the old code does not linger.
What AWS says
The container image documentation notes that you cannot change the deployment package type (.zip or container image) for an existing function, and that you must create a new function. Lambda supports two package types, and layers apply only to .zip functions.
Why teams move
Common reasons, in plain terms:
- Dependencies too large for the 250 MB unzipped zip limit. Container images allow 10 GB uncompressed.
- A shared base image across services, owned by a platform team.
- Native libraries that are easier to build in a Dockerfile.
None of these are security reasons by themselves. The move trades one patching model for another, so decide with that in mind. Zip or container, which is easier to keep patched compares them.
Migration plan
- Inventory the old function. Runtime, layers, environment variables, role, triggers, concurrency settings and aliases.
- Build the image from the same source and lockfile. Use a base image you have a refresh plan for.
- Recreate configuration on the new function. The execution role deserves a review, not a copy. See least privilege for execution roles.
- Scan the image and compare findings with the old zip.
- Shift traffic gradually. If callers use an alias or function URL, move them in steps and watch errors.
- Retire the old function. Remove triggers first, then the function, then any layers only it used.
The step people skip: removal
After a migration, the old function often stays. It keeps its triggers, its role and its old dependencies. An unused function that still accepts events is an exposed, unpatched copy. Set a date when you create the new function, and put it on the ticket.
AWS also points out in its best practices that you should delete functions you no longer use, so they do not needlessly count against the package size limits.
What changes after the move
| Area | Zip function | Container function |
|---|---|---|
| Layers | Supported, up to 5 | Not used |
| Runtime updates | Runtime management modes | You rebuild on a new base |
| Size ceiling | 250 MB unzipped | 10 GB uncompressed |
| Dependency scanning | Scan the zip | Scan the image, including OS packages |
Try it yourself
Open the container image scan demo to see how an image scan shows OS packages next to application packages. That is the new surface a migration adds.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans both source dependencies and container images, so you can compare the zip build and the image build of the same function before cutting over. Free scan: gold.safeguard.sh/scan.
Quick check
Can I switch an existing function to a container image in the console?
No. AWS says the package type cannot be changed for an existing function. Create a new one.
What happens to my layers after a move?
Container functions package their own dependencies and do not use layers.
Sources
- Create a Lambda function using a container image, AWS documentation
- Managing Lambda dependencies with layers, AWS documentation
- Best practices for working with Lambda functions, AWS documentation
- Lambda quotas, AWS documentation
Last reviewed: 19 October 2026.
