No. AWS lists layers, container images, arm64 functions and custom environment variables among the Lambda features that Lambda@Edge does not support. Dependencies must be bundled into the .zip package, and configuration cannot be passed through environment variables, which shapes how you patch and how you handle secrets.
What AWS says is unsupported
The restrictions page for Lambda@Edge lists these Lambda features as unsupported:
- Lambda layers
- Container images
- Functions that use the arm64 architecture
- Environment variables, except reserved ones that are supported automatically
- Provisioned concurrency
- VPC access
- More than 512 MB of ephemeral storage
- Runtime management configurations other than Auto
If you came from regular Lambda, that list removes several habits at once. Each one has a supply chain consequence.
No layers: bundle everything
On regular Lambda, a shared layer lets you patch a library in one place. On Lambda@Edge there is no layer, so each function carries its own copy of every dependency. A vulnerable package in three edge functions means three rebuilds.
The fix is process, not tooling. Keep one lockfile per function, build from it in CI, and scan the built artifact. If several edge functions share code, put it in an internal package with a version, so one bump and three rebuilds can be scripted. Our post on Lambda layers across accounts explains why regular Lambda is different.
No container images: no base image to rebuild
This sounds like a loss, but it removes a whole patching surface. You do not own an operating system image for an edge function. You own the zip contents and the choice of runtime.
No custom environment variables: where do settings go
Without environment variables, teams often hard-code settings into the bundle at build time. That works for non-sensitive values such as a header name or a redirect map. It is a poor home for secrets, because a value baked into a package is readable by anyone who can read the package, and it persists in every published version.
Safer patterns, as general practice:
- Keep secrets out of the bundle entirely.
- Fetch them at run time from a managed secrets service, and cache with a short lifetime.
- Give the execution role only the permission to read that one secret.
Check AWS's own guidance for the exact IAM setup, because Lambda@Edge roles must allow both the Lambda and the edge Lambda service principals to assume them.
Numbered versions only
AWS also states that Lambda@Edge needs a numbered version of the function, not $LATEST or an alias, and the function must be in US East (N. Virginia). So every dependency patch ends with a new numbered version and an updated CloudFront association. See how to ship a patched dependency to Lambda@Edge.
A short pre-deploy checklist
| Check | Why |
|---|---|
| Lockfile committed and used by the build | Reproducible dependency tree |
| Scan of the built zip, not just the repo | Catches what actually ships |
| No secrets in bundled config | Package contents are widely readable |
| Runtime is a current supported Node.js or Python | AWS says deprecated versions cannot be created or updated |
| Owner and distributions recorded | Someone must patch it |
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation work from the repo and build that produce the zip, so each edge function gets its own inventory. Autonomous remediation can open fix pull requests, and it is off by default with every category on Manual. A free scan is at gold.safeguard.sh/scan.
Quick check
Can I use a layer to share a library across edge functions?
No. AWS lists layers as unsupported for Lambda@Edge, so each function bundles its own copy.
Can I use an alias instead of a version number?
No. AWS says you must use a numbered version, not $LATEST or an alias.
Where should an API key for an edge function live?
Not in the bundle. Fetch it at run time from a secrets service with a narrow permission, as general practice.
Sources
Last reviewed: 19 October 2026.
