Use the AWS CLI command aws lambda list-functions. Its output includes each function's runtime and its layers, and a version flag can include every published version. Run it in each Region you use, then join the results with build data to see which packages each function carries.
What the command returns
AWS's CLI reference describes list-functions as returning a list of functions with version-specific configuration. The fields that matter for inventory include the function name, Runtime, and a Layers list with each layer's ARN. The reference also notes that the operation is paginated, so multiple calls may be needed, and that you can set the function version option to ALL to include entries for all published versions of each function, in addition to the unpublished version.
It also says list-functions returns a subset of the function configuration fields. For additional fields, use get-function for a specific function or version.
A simple inventory workflow
- List the Regions where your accounts run Lambda. Do not assume one. Many estates have forgotten functions in a second Region.
- Run list-functions per Region, with pagination handled by the CLI default, and request all versions if you want to find old ones.
- Extract four columns: function name, runtime, layer ARNs and last modified time.
- Flag the obvious: runtimes AWS marks as deprecated, layers from outside your accounts, and functions untouched for a long time.
- Join with build data. The CLI tells you what is configured, not which npm or PyPI packages are inside the zip. That comes from your build SBOMs.
- Store the result with a date so you can see change over time.
What the CLI cannot tell you
| Question | Source |
|---|---|
| Which runtime is configured | list-functions |
| Which layer versions are attached | list-functions |
| Which libraries are inside the zip | Build lockfile or SBOM |
| Which libraries are inside a layer | The build that made the layer |
| Who owns the function | Your tags and your inventory |
The last row is the one that bites. Add an owner tag to every function as policy, and have your pipeline fail without it.
Include old versions on purpose
Published versions are immutable. AWS states that after publishing, a version's code, runtime, architecture, memory, layers and most settings cannot change. So an old version with an old dependency keeps that dependency. Listing all versions makes forgotten ones visible. The deeper issue is covered in old versions and aliases still run vulnerable code.
Turn the list into a routine
A one-off list is a snapshot. Run the same script on a schedule, keep the outputs, and diff them. New functions, new layers and changed runtimes appear as diffs. Pair it with an alert for any function whose runtime appears on AWS's deprecation list, which you can check against the runtime deprecation guide.
Try it yourself
The demo shows what the build-side half of the inventory looks like: packages mapped to the services that use them. Combine it with the CLI output to cover both halves.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's asset discovery and SBOM generation help build the inventory from the source and build side, which the CLI cannot see. Free scan: gold.safeguard.sh/scan.
Quick check
Does list-functions show every version of a function?
Not by default. AWS documents a function version option that you can set to ALL to include all published versions.
Will the CLI list my npm packages?
No. It shows configuration such as runtime and layers. Package lists come from your build lockfile or SBOM.
Sources
Last reviewed: 19 October 2026.
