Yes, in most cases. AWS recommends including the SDK modules your code uses, along with their dependencies, in your deployment package or a layer. That gives you version control, avoids surprises when the runtime updates, and puts the SDK on your dependency list where scanners can see it.
What the runtime gives you
The Node.js, Python and Ruby runtimes include a version of the AWS SDK. Lambda periodically updates that version. AWS says to use the runtime included SDK only when you cannot include additional packages, for example when you write code in the console editor or inline in a CloudFormation template.
Four reasons to bundle
- Compatibility. AWS describes a case where a function uses package A from the runtime but package B from the deployment package. A future runtime update to A may need a newer B, and your older B takes precedence. Packaging both avoids that mismatch.
- Precedence is on your side. For Python, the AWS documentation says your deployment package takes precedence over runtime included libraries, and dependencies in layers also take precedence over the runtime copies.
- Visible inventory. A package in your manifest and lockfile shows up in SBOMs and scans. A library that lives inside the runtime image does not appear in your lockfile at all.
- A known version for testing. The version you test is the version that runs.
The cost
Bundling means you own updates. When the SDK or one of its dependencies gets a security fix, you rebuild and redeploy. The runtime included copy would have updated itself. That is the trade: stability and visibility in exchange for responsibility.
A Python warning from AWS is worth repeating. If you ship your own copy of an SDK dependency such as urllib3 without shipping the SDK itself, a runtime update can leave the two out of step. Ship the whole set together.
A simple decision guide
| Situation | Suggestion |
|---|---|
| Normal deployable function | Bundle the SDK modules you use |
| Console inline code or tiny CloudFormation snippet | Runtime copy is acceptable; keep the function trivial |
| Many functions sharing one SDK version | Put it in a layer and track the layer version |
| Go or Rust function | Dependencies are compiled into the executable; AWS recommends against layers for these |
| Need identical versions across regions | Use container images, as AWS suggests |
Keep bundles small and honest
Import only the clients you need rather than the whole SDK. The AWS performance guidance shows requiring a single service client instead of the entire SDK, which also trims initialization time and the number of packages you must track.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how direct and transitive packages are listed. Bundled SDK modules appear here, runtime copies do not.
Quick check
Is the bundled SDK slower to start?
It adds package size, which AWS lists as a factor in initialization time. Importing individual clients keeps that small.
Who patches the runtime included SDK?
Lambda updates it periodically as part of runtime updates, but AWS still recommends bundling for control and compatibility.
Safeguard's SBOM and dependency scanning can list the SDK packages in your function bundle and flag vulnerable versions. Try a free scan at gold.safeguard.sh/scan.
Sources
- AWS Lambda runtimes
- How Lambda manages runtime version updates
- Python deployment packages for Lambda
- Lambda layers
- Execution environment lifecycle and static initialization
Last reviewed: 19 October 2026.
