Content

• Introduction
• AWS Global Edge Network
• Cloudfront functions
  • Constraints
  • Use cases
  • Event triggers
• Lambda@Edge
  • Constraints
  • Use cases
  • Event triggers
• Conclusion

Introduction

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.

AWS Global Edge Network

Before we talk about the difference between the two services, it is also important to talk about at which “edge” these services run at.

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.

Cloudfront functions

Constraints

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.

The constraints:

• 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 Filesystem

• No access to request body

Use cases

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

• Access authorization

Event triggers

The event trigger for these functions only include: viewer request and viewer response.

The event triggers:

1. Viewer Request - Runs before request reaches Cloudfront (edge cache)

2. Viewer Response - Runs before Cloudfront fowards request to the client (edge cache)

💡Tip

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.

Lambda@Edge

Constraints

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.

The constraints:

• Viewer triggers (Request & Response) Constraints

  • Duration (max: 5 seconds)
  • Memory (max: 128 MB)
  • Package Size (max: 1 MB)

• Origin triggers (Request & Response) Constraints

  • Duration (max: 30 seconds)
  • Memory (max: 10 Gb)
  • Package Size (max: 50 MB)

Use cases

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)

• A/B Testing

• 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.

Event triggers

The event trigger for these functions only include: viewer (request & response) and origin (request & response).

The event triggers:

1. Viewer Request - Runs before request reaches Cloudfront (regional cache)

2. Origin Request - Runs before request gets forwarded to the origin (regional cache)

3. Origin Response - Runs before origin response is received by Cloudfront (regional cache)

4. Viewer Response - Runs before Cloudfront fowards request to the client (regional cache)

Conclusion

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 sums up the differences:

Source: Choosing between CloudFront Functions and Lambda@Edge

And... That’s all.

If you found this helpful or learned something new, please do share this article with a friend 🙏❤️ (Thanks!)

Also published here