Testing and Deployment · Topic 1 of 6
Packaging Code and Container Images
Package dependencies for DVA-C03: Lambda zip files, layers and container images, plus Amazon ECR repositories, image tags and lifecycle policies.
- 5 min
- A .zip deployment is limited to 50 MB zipped (direct upload) and 250 MB unzipped, layers included.
- A container image function can be up to 10 GB, which is the choice for large dependencies.
- A function can use up to 5 layers, extracted to
/opt, and layers do not work with container images.
What it is
Before code can be deployed, it must be bundled with everything it needs: libraries, configuration files and the runtime it expects. The package format you pick decides the size limits, the deployment speed and how you share code between functions.
For Lambda you have three formats: a .zip file, a .zip file plus layers, or a container image. For containers on ECS, EKS or Lambda, the image is stored in Amazon ECR.
How it works
Managing dependencies in a package
Install dependencies at build time and include them in the package. A Node.js function ships its node_modules folder, and a Python function ships the packages installed next to the handler. Running sam build does this for you from package.json or requirements.txt.
Lambda unpacks your code into the /var/task directory, so a configuration file inside the package is read from there. Keep values that change per environment out of the package and use environment variables instead. All environment variables of a function together can use at most 4 KB.
Never bake secrets into a package or image. Read them at run time from Secrets Manager or Parameter Store.
Lambda packaging methods
| Method | Size limit | Best for |
|---|---|---|
| .zip file | 50 MB zipped when uploaded directly, 250 MB unzipped including layers | Small functions with few dependencies |
| .zip file with layers | Same 250 MB unzipped total, up to 5 layers per function | Shared libraries used by many functions |
| Container image | 10 GB uncompressed image | Large dependencies, machine learning libraries, existing Docker tooling |
A zip package larger than 50 MB can be uploaded through Amazon S3, but it still has to fit in 250 MB when unzipped.
Layers
A layer is a .zip archive of libraries or other content that you publish once and attach to many functions. Lambda extracts layers into the /opt directory. Each publish creates a new immutable layer version, and the function points at a specific version.
Layers keep the function package small and let you update a shared library in one place. They work only with .zip functions, not with container image functions. A runtime finds layer content in a folder it expects, such as python/ for Python or nodejs/node_modules for Node.js.
Container images and Amazon ECR
A container image is built from a Dockerfile, ideally starting from an AWS provided Lambda base image. Images deployed to Lambda must be stored in an ECR repository in the same Region.
The push sequence is: authenticate Docker with aws ecr get-login-password, build the image, tag it with the repository URI, then docker push.
Tags are labels that point to an image digest. Use unique tags such as a Git commit ID or a build number for releases. A tag like latest moves with every push, so it is a poor choice for traceable deployments. Turning on tag immutability on the repository stops anyone from overwriting an existing tag.
ECR lifecycle policies clean up old images automatically. A rule has a priority, a selection (tag status, tag prefix, image count or days since push) and an action to expire the matching images. A common rule keeps only the last 10 images or expires untagged images after a few days.
ECR can also scan images for known vulnerabilities, either when pushed or continuously.
How the exam asks about this
- "Ten functions share the same large library and each deployment is slow." -> Put the library in a Lambda layer and attach it to the functions.
- "A function needs a 4 GB machine learning dependency." -> Package it as a container image stored in Amazon ECR.
- "The ECR repository fills up with old untagged images." -> Add an ECR lifecycle policy that expires them.
What to remember for the exam
- A .zip deployment is limited to 50 MB zipped (direct upload) and 250 MB unzipped, layers included.
- A container image function can be up to 10 GB, which is the choice for large dependencies.
- A function can use up to 5 layers, extracted to
/opt, and layers do not work with container images. - Layer versions are immutable, so updating a layer means publishing a new version and updating the function.
- ECR tag immutability prevents overwriting tags, and lifecycle policies expire old images.
- Environment variables are limited to 4 KB in total, so large configuration belongs in AppConfig or Parameter Store.
Layers count toward the 250 MB unzipped limit. Adding a layer does not give you extra space, it only helps you share and reuse code.
Common mistakes
Picking layers for a container image function. Layers are a .zip feature. With a container image, add the libraries to the image itself.
Relying on the latest tag. A deployed function does not follow a moving tag automatically, and nobody can tell which build is running. Use unique, ideally immutable, tags.
Putting secrets or environment specific values in the package. The same artifact should run in every environment, with configuration supplied from outside.
Check yourself
What is the unzipped size limit for a Lambda .zip package including layers?
250 MB, with a 50 MB limit for a direct zipped upload.
Which packaging method suits a 4 GB dependency?
A container image, which can be up to 10 GB and is stored in ECR.
How do you automatically remove old images from an ECR repository?
Create an ECR lifecycle policy with rules that expire images by age or count.
Topic 1 of 6 in Testing and Deployment
Test yourself on Testing and Deployment
The full AWS DVA-C03 question bank has 850 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.