Published on: Sun Dec 18 2022
When I was looking into these two services: Cloudfront functions and Lambda@Edge, I had the question of what’s the difference between the two ?
In this guide, we’ll break that down, and talk about when you’d might want to lean on one over the other.
Both of these services run at an “edge” location.
At a high level, Cloudfront functions are more suitable for simple request transformations (changing headers, url, etc). That was what it was designed for.
On the other hand, Lamda@Edge were designed for more compute intensive work loads at the edge. Ones that may require access to a file system or network.
Let’s go through the difference in more detail.
Before we talk about the difference between the two services, it is also important to talk about at which “edge” these services run at.
Illustration of the AWS Edge locations map (Source: AWS Global Edge Network)
Within the AWS Global edge network, there are ~13 regional edge locations (orange circles), and over 218+ Cloudfront edge locations (blue and purple circles). More locations are continuously being added.
Lambda@Edge runs in one of these 13 regional edge locations, and Cloudfront functions runs at one of these 218+ Cloudfront edge locations.
Basically, Cloudfront functions allows you to run logic even closer to the users.
The gist of it is that Cloudfront functions are very scalable but it does come with a lot of drawbacks.
The biggest one is the constraints which really limits their application to a very narrow subset.
Duration (timeout: within milliseconds)
Memory (max: 2MB Memory)
Package Size (max: 10 KB)
Limited features in runtime (Javscript - ECMAScript 5.1 compliant)
No network access
No access to request body
In general, the use cases of the cloudfront functions are very limited.
This is because they were designed for “lightweight” applications, and not for every use case.
Some examples include:
HTTP header manipulation and transformation
URL rewrite and redirects
Cache key manipulations
The event trigger for these functions only include: viewer request and viewer response.
Illustration of Cloudfront Event triggers
The event triggers:
Viewer Request - Runs before request reaches Cloudfront (edge cache)
Viewer Response - Runs before Cloudfront fowards request to the client (edge cache)
When might you use one over the other ? Well, it depends if you want to make changes to the request or response.
If you’d like to make changes to the request, use the Viewer Request trigger, and if you’d like to change the response, use the Viewer Response.
In comparison to the Cloudfront function, Lambda@Edge has more capabilities.
It has access to network, file system, the request body and modern runtimes (ie Node.js 12.x+ and Python).
That being said, it does have its constraints.
Let’s take a look at what those are.
Viewer triggers (Request & Response) Constraints
Origin triggers (Request & Response) Constraints
As mentioned, the use cases of Lambda@edge are expanded due to there being more capabilities available.
These use cases may include:
Rendering HTML (at regional edge)
Adding event to Amazon kinesis (for tracking)
Use cases requiring access to file system, network and packages (ie AWS SDK)
And many more
So, these are typically more compute intensive applications. Those work loads are more suite to run in Lambda@edge.
The event trigger for these functions only include: viewer (request & response) and origin (request & response).
Illustration of Lambda@Edge Event triggers
The event triggers:
Viewer Request - Runs before request reaches Cloudfront (regional cache)
Origin Request - Runs before request gets forwarded to the origin (regional cache)
Origin Response - Runs before origin response is received by Cloudfront (regional cache)
Viewer Response - Runs before Cloudfront fowards request to the client (regional cache)
So, to summarize, choose Cloudfront functions for simple workloads (ie URL rewrite & redirects and header manipulations) and Lambda@Edge functions for compute intensive workloads (rendering html or making a call to a DB or API).
Here is a table that sum’s up the differences:
And... That’s all.
If you found this helpful or learned something new, please do share this article with a friend or co-worker 🙏❤️ (Thanks!)
Then consider signing up to get notified when new content arrives!