Yes. A published Lambda version is an immutable snapshot of code, layers, runtime and most settings. Patching $LATEST does not change older versions. If an alias, trigger or resource policy still points at one, it keeps running the vulnerable code until you move it or delete it.
What immutable means here
AWS says that after you publish a version, its code, runtime, architecture, memory, layers and most other settings are immutable. You cannot change them without publishing a new version from $LATEST. Each version has its own qualified ARN, and Lambda never reuses version numbers.
Deploying new code overwrites $LATEST. It does not touch published versions. That is the point of versioning, and also the trap: a rollback target is also a place for vulnerable code to hide.
Where old versions stay reachable
- Aliases. A production alias may still point at version 12 while you tested the fix on 15.
- Event sources and triggers. Mappings and triggers can reference a qualified ARN with a version.
- Resource policies. Permissions can be granted on one version, so another service may invoke it directly.
- Provisioned concurrency. You can configure it on a published version, which keeps environments warm for that version.
AWS also notes that a runtime update in Auto mode applies to published versions too, but only the runtime. Your packaged dependencies and layers stay as they were.
How to find them
- List every version and alias for each function.
- For each alias, note which version or versions receive traffic.
- List event source mappings and triggers and check the ARNs they use.
- Check for provisioned concurrency on non latest versions.
- Compare each version's layer ARNs and package digest with the patched one.
AWS Trusted Advisor's deprecated runtime check lists both $LATEST and published versions, which is a quick way to find old versions on unsupported runtimes.
Clean up safely
| Step | Why |
|---|---|
| Shift the alias to the patched version | Traffic moves, rollback stays one command away |
| Update triggers to the alias, not a version number | They follow future changes |
| Keep one previous version for rollback | Gives you a safe retreat |
| Delete versions older than your rollback window | Removes vulnerable code you no longer need |
| Record the cleanup | Evidence for audits |
Code storage counts too. AWS says each function version and layer version consumes storage, with an account quota of 300 GB of unzipped code in Lambda managed storage, so pruning also keeps you under the limit.
Make it routine
Put alias targets and trigger ARNs in infrastructure code, so a deployment updates them together. Add a scheduled check that flags versions not invoked in a set period, and a rule that new triggers must target aliases.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring re checks assets over time. Old versions need the same repeated look, not a one time cleanup.
Quick check
Does publishing a new version patch the old one?
No. Each published version is a separate immutable snapshot. Old versions keep their original code and layers.
Should triggers point to a version number?
Usually an alias is easier to manage, because you move the alias when you ship a fix. AWS also suggests aliases to simplify event source and permission management.
Safeguard's asset discovery and continuous scanning can help you track what is deployed and flag vulnerable components. Try a free scan at gold.safeguard.sh/scan.
Sources
- Manage Lambda function versions
- AWS Lambda runtimes
- How Lambda manages runtime version updates
- Lambda quotas
Last reviewed: 19 October 2026.
