CloudFront Functions or Lambda@Edge: where do dependencies fit?

CloudFront Functions limit function code and included libraries to 10 KB, so they are built for small, dependency-free logic. Lambda@Edge allows up to 50 MB and is the option AWS points to for code that depends on third-party libraries. Dependency security work at the CloudFront edge therefore lives mostly in Lambda@Edge.

The two options side by side

AWS publishes a comparison of the two, and it is worth reading before you design anything. These are the rows that matter for supply chain risk.

AWS describes CloudFront Functions as ideal for cache key normalization, header changes, redirects and rewrites, and token checks. It describes Lambda@Edge as the fit for functions that depend on third-party libraries, need network access, or need the request body.

What a 10 KB ceiling does to your risk

A package manager install of almost any real library will blow through 10 KB. In practice, a CloudFront function carries your own few dozen lines, and anything else you want has to be written inline. That has a side effect that is good for security: there is very little third-party code to go stale.

It also removes the usual remediation loop. There is no lockfile to update, no advisory to triage against a package tree. The review burden shifts to your own code, which should be small enough to read in one sitting.

The runtime is restricted as well. AWS notes that the CloudFront Functions environment does not support dynamic code evaluation and restricts access to the network, file system, environment variables and timers. A function that cannot reach the network has fewer ways to leak data, though it can still make a wrong allow or deny decision, so test the logic.

What changes when you pick Lambda@Edge

Lambda@Edge brings back the full dependency problem. You get npm or pip, a node_modules or site-packages tree, native modules, and everything that follows. AWS documents that Lambda@Edge does not support Lambda layers, so those dependencies have to travel inside the deployment package. Our post on layers, environment variables and containers at the edge covers the other unsupported features.

A reasonable rule for deciding between the two:

1. Write the logic as if it were a CloudFront function first.
2. If it needs a library, ask whether 20 lines of your own code would replace it.
3. If it still needs a library, an outbound call, or the request body, move to Lambda@Edge.
4. For the Lambda@Edge version, treat the package like any other deployable: lockfile, scan on every build, and a dated owner for updates.

Keep an inventory either way

Even a function with zero dependencies belongs in your inventory. Record which distributions use it, which event type it runs on (viewer request, viewer response, origin request or origin response), and who owns it. AWS notes that each event type on a cache behavior can have only one edge function association, and that you cannot combine CloudFront Functions and Lambda@Edge on viewer events. So the inventory also tells you which slots are taken.

Try it yourself

Open the dependency inventory demo and look at how a single package appears under several services. That is the view you want for a Lambda@Edge function with a real node_modules tree.

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

Where Safeguard fits

For the Lambda@Edge side, Safeguard's SBOM and dependency scanning can read the lockfile of the repo that builds the package and flag known vulnerable versions, with reachability analysis to show which findings your code actually calls. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• Differences between CloudFront Functions and Lambda@Edge, AWS documentation
• Restrictions on CloudFront Functions, AWS documentation
• Restrictions on all edge functions, AWS documentation
• Restrictions on Lambda@Edge, AWS documentation

Last reviewed: 19 October 2026.