AWS recommends against layers for Go and Rust Lambda functions because their code ships as a compiled executable that already contains its dependencies. Putting dependencies in a layer forces extra loading during initialization, which AWS says can increase cold start times. The result for security is that each binary must be rebuilt to patch.
What AWS says
The Lambda layers documentation states that for Go and Rust, you provide function code as an executable that includes your compiled code and all of its dependencies. It adds that putting dependencies in a layer forces the function to manually load additional assemblies during initialization, which can increase cold start times, and recommends including dependencies with the deployment package.
What that means for patching
A compiled binary is a snapshot. Fixing a vulnerable crate or Go module means:
- Update the module version and the lockfile (go.sum or Cargo.lock).
- Rebuild the binary.
- Redeploy the function.
There is no shared layer to bump. If ten functions use the same vulnerable module, you rebuild ten binaries. The patching model is the same as for any statically linked program.
Binaries hide dependencies from simple scanners
A scanner that reads a manifest sees declared modules. A scanner that reads the binary needs to recognize embedded metadata. Both Go and Rust toolchains can embed build information, though what is available depends on build flags, so check what your toolchain records. Keep the lockfile with each release and generate the SBOM from the build, not from the running function.
A routine that works
| Step | Detail |
|---|---|
| Build in CI from the lockfile | Never from a developer laptop |
| Store the lockfile or SBOM with the artifact | So you can answer what is inside a given release later |
| Scan on every build and on a schedule | Advisories arrive after the build |
| Rebuild on fix | No layer to bump |
| Track which functions use which binary version | So nothing lags |
The cold start tradeoff, honestly
AWS states layers can increase cold start for these runtimes. It does not give a number in that passage, and the effect for your function depends on size and workload. If you care, measure with and without. Do not trade patchability for an unmeasured gain.
On the other side, bundling means every function pays for its own copy of shared code in package size. For compiled languages the cost is usually modest, but check.
Do not forget the base
A zip function in Go or Rust uses a runtime AWS provides. A container image function adds a base image you manage. AWS notes that OS-only base images are commonly used for compiled languages such as Go and Rust. If you go that way, read what changes with a non-AWS base image.
Try it yourself
Reachability matters more for compiled code, where a library may be linked in but never called. Open the demo to see how findings drop when only reachable paths count.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning reads your lockfiles and applies reachability analysis, which helps prioritise advisories in compiled modules. Fix pull requests from autonomous remediation are off by default, every category on Manual. Free scan: gold.safeguard.sh/scan.
Quick check
How do I patch a vulnerable crate in a Rust Lambda?
Update the crate and lockfile, rebuild the binary and redeploy. There is no shared layer to change.
Is the cold start penalty from layers large?
AWS says it can increase cold start but gives no figure in that passage. Measure your own function.
Sources
- Managing Lambda dependencies with layers, AWS documentation
- Create a Lambda function using a container image, AWS documentation
Last reviewed: 19 October 2026.
