No. AWS periodically publishes updated base images for Lambda, but a container function keeps running the image you built. AWS says that to use an updated base image you must rebuild your container image and update the function code. Nothing changes until you redeploy.
What AWS states
The container image documentation says AWS periodically provides updates to the AWS base images for Lambda. If your Dockerfile names the image in the FROM line, your Docker client pulls the latest version of that image when you build. To use it, you must rebuild and update the function code.
It also notes that Node.js 20, Python 3.12, Java 21, .NET 8, Ruby 3.3 and later base images are based on the Amazon Linux 2023 minimal container image, and earlier ones use Amazon Linux 2. Check the current page for the list.
The gap this creates
| Event | Effect on a running function |
|---|---|
| AWS publishes a new base image | None |
| You run a new build | New image in your registry |
| You update the function to the new image | Function runs the new code |
A function nobody touches can sit on an old base for months. That is a normal state for a quiet internal function, and it is how known-vulnerable OS packages stay in production.
A rebuild routine
- List container functions and the image digest each uses.
- Set a cadence. A scheduled rebuild, say weekly or monthly, is a policy choice. Pick one and write it down.
- Automate the build. A scheduled pipeline that builds from the same source and runs the same tests keeps the cost low.
- Scan before deploy. Fail the pipeline on findings above your threshold.
- Deploy with a version. Publish a new numbered version so you can roll back.
- Record the result: image digest, scan date, deployed version.
Rebuild on advisories too
A calendar is not enough. When an advisory affects an OS package or language runtime in your image, rebuild out of cycle. The question to ask is whether the vulnerable component is in your image and reachable by your code, which an image scan plus reachability can answer.
Watch the tag you use
If you pin FROM to a floating tag, builds change over time, which is helpful for patching and bad for repeatability. If you pin to a digest, builds are repeatable and never improve on their own. A common compromise: pin a digest, and let a bot or scheduled job propose digest updates through a pull request that CI tests.
What AWS does not do for you
AWS's managed runtime path for .zip functions has its own update mechanics, covered in Lambda runtime update modes. Container functions do not use that path. You own the rebuild.
Try it yourself
Open the container image scan demo and scan the sample image. Note which findings come from the base layer and would disappear after a rebuild.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans container images and watches them continuously, so a new advisory against a base layer shows up without waiting for the next scheduled build. Autonomous remediation is off by default with every category on Manual. Free scan: gold.safeguard.sh/scan.
Quick check
If my Dockerfile uses FROM with an AWS tag, is my function current?
Only at build time. The function runs the image you built until you rebuild and update it.
How often should I rebuild?
AWS does not set a schedule. Choose a cadence, such as weekly or monthly, and also rebuild when an advisory affects your image.
Sources
Last reviewed: 19 October 2026.
