AWS: Cloudfront functions versus Lambda@Edge
Tags: aws, cloud, webdev
Published: 2022-12-21 19:24:10

---
title: "AWS: Cloudfront functions versus Lambda@Edge"
published: true
description: What’s the difference between Cloudfront functions and Lambda@Edge ?
tags: aws, cloud, webdev
cover_image: https://jerrychang.ca/images/og-cloudfront-functions-versus-lambda-at-edge.png
# Use a ratio of 100:42 for best results.
# published_at: 2022-12-21 19:15 +0000
---

## Content 

- [Introduction](#introduction)
- [AWS Global Edge Network](#aws-global-edge-network)
- [Cloudfront functions](#cloudfront-functions)
  - [Constraints](#constraints)
  - [Use cases](#use-cases)
  - [Event triggers](#event-triggers)
- [Lambda@Edge](#lambdaedge)
  - [Constraints](#constraints-1)
  - [Use cases](#use-cases-1)
  - [Event triggers](#event-triggers-1)
- [Conclusion](#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.

![Image Illustration of the AWS Edge locations map](https://www.jerrychang.ca/images/aws-edge-functions-comparison-global-network.png)

**Source:** [AWS Global Edge Network](https://aws.amazon.com/cloudfront/features/?whats-new-cloudfront.sort-by=item.additionalFields.postDateTime&whats-new-cloudfront.sort-order=desc#edge-locations)


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.

![Image Illustration of Cloudfront Event triggers](https://www.jerrychang.ca/images/aws-edge-functions-comparison-cloudfront-event-trigger.png)

**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).

![Image Illustration of Lambda@Edge Event triggers](https://www.jerrychang.ca/images/aws-edge-functions-comparison-lambda-edge-event-trigger.png)

**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:**

![Image Illustration of Lambda@Edge Event triggers](https://www.jerrychang.ca/images/aws-edge-functions-comparison-table.png)

**Source:** [Choosing between CloudFront Functions and Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions.html)

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](https://www.jerrychang.ca/writing/cloudfront-functions-versus-lambda-at-edge)