How do you share a Lambda layer across AWS accounts safely?

Grant lambda:GetLayerVersion on a specific layer version to a named account or to your AWS Organization, and repeat for each new version. Avoid granting access to every account. Remember that consumers run your layer code with their function permissions, so treat a shared layer as supply chain code.

How sharing works

AWS documents sharing as a statement in the layer version's resource based policy, added with add-layer-version-permission. You can grant a single account, all accounts, or an organization in AWS Organizations. Permissions apply to a single layer version, so you repeat the step whenever you publish a new version. To grant several accounts or organizations, add several statements.

Example for one account:

aws lambda add-layer-version-permission \
  --layer-name bash-runtime \
  --version-number 2 \
  --statement-id xaccount \
  --action lambda:GetLayerVersion \
  --principal 111122223333

Example for an organization, which uses a star principal narrowed by an organization condition:

aws lambda add-layer-version-permission \
  --layer-name my-layer \
  --version-number 3 \
  --statement-id engineering-org \
  --principal '*' \
  --action lambda:GetLayerVersion \
  --organization-id o-t194hfs8cz

Choose the narrowest grant that works

The organization example above is a star principal, but AWS pairs it with an aws:PrincipalOrgID condition, which is what limits it. If you ever write a star principal without that condition, you have made the layer available to everyone.

What the consumer is trusting

A layer is extracted to the /opt directory in the function's execution environment, and the code in it runs with the function's permissions. That is why publishing a layer carries responsibility:

• A vulnerability in your layer becomes a vulnerability in every consumer.
• Consumers need a way to learn about fixes, because their functions reference an exact version ARN.
• A consumer who only checks the version number may not know what is inside.

A publisher checklist

1. Scan the layer contents and keep a lockfile and SBOM for each version.
2. Publish release notes with dependency changes and fixes.
3. Share by organization when the audience is internal.
4. Announce deprecations and fixes through a channel consumers watch.
5. Do not delete a version consumers use without notice. AWS says functions that already use it keep running, but consumers can no longer update configuration to reference it in some storage modes.

A consumer checklist

1. Record the layer ARN and version in infrastructure code.
2. Ask for the SBOM or dependency list.
3. Test new versions on an alias before production.
4. Remember the five layers per function limit and the 250 MB total.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at what a dependency inventory shows. A layer publisher should be able to produce this view for every version.

Quick check

Safeguard's SBOM generation and dependency scanning can produce the dependency record a layer publisher should keep. Try a free scan at gold.safeguard.sh/scan.

Sources

• Granting Lambda layer access to other accounts
• Lambda layers overview
• Creating and deleting layers
• Lambda quotas

Last reviewed: 19 October 2026.