CloudFront Functions vs. Lambda@Edge: what's the difference?

AWS announced CloudFront KeyValueStore yesterday which enhances the capabilities of CloudFront Functions. In case you're not familiar, here's a quick summary of what CloudFront Functions do:

Amazon CloudFront allows you to securely deliver static and dynamic content with low latency and high transfer speeds. With CloudFront Functions, you can perform latency-sensitive customizations for millions of requests per second. For example, you can use CloudFront Functions to modify headers, normalize cache keys, rewrite URLs, or authorize requests.

You may also be familiar with Lambda@Edge which is a similar service that allows you to run Lambda functions at the edge of the AWS network. To quote the AWS docs:

Lambda@Edge is a feature of Amazon CloudFront that lets you run code closer to users of your application, which improves performance and reduces latency. With Lambda@Edge, you don't have to provision or manage infrastructure in multiple locations around the world. You pay only for the compute time you consume - there is no charge when your code is not running.

Reading those two descriptions you may be wondering - what's the difference between those two services? Let's take a look!

• Programming language: Lambda@Edge supports Node.js and Python. CloudFront Functions support JavaScript only. Not really a problem for me personally (I'm a JavaScript developer) but it's worth mentioning.

• Execution Location: Lambda@Edge functions are executed in 13 CloudFront Regional Edge Caches, whereas CloudFront Functions are executed in 225+ CloudFront Edge Locations. This means that CloudFront Functions are may be executed closer to the end user, which means lower latency.

• Trigger points:

CloudFront Functions can be triggered by the following events:

• When CloudFront receives a request from a viewer (viewer request)
• Before CloudFront returns the response to the viewer (viewer response)

Lambda@Edge function can be triggered when:

• CloudFront receives a request from a viewer (viewer request)

• Before CloudFront returns the response to the viewer (viewer response)

• CloudFront forwards a request to your origin (origin request)

• After CloudFront receives the response from the origin and before it caches the object in the response (origin response)

• Maximum execution time: CloudFront Functions need to finish under a millisecond (so if your code is as slow as mine, you should consider using Lambda@Edge). Lambda@Edge functions can run for up to 5 seconds for viewer request and viewer response triggers, and up to 30 seconds for origin request and origin response triggers.

• Network access: CloudFront Functions can't access the network. Lambda@Edge functions can access the network.

• HTTP manipulation: CloudFront Functions can only manipulate HTTP headers. If you need to remove or replace the body of an HTTP request or response, use Lambda@Edge instead.

• Filesystem access: CloudFront Functions don't have access to filesystem (which makes sense, especially given the 1ms limit). Lambda@Edge functions can access the filesystem.

• Scale: CloudFront Functions can scale to 10,000,000 requests per second or more. Lambda@Edge functions can scale up to 10,000 requests per second per Region.

• Memory: CloudFront Functions have 2MB of memory available. Lambda@Edge functions have 128MB - 3GB of memory available.

• Maximum function size: CloudFront Functions need to be tiny - they can't be larger than 10KB. Lambda@Edge functions can be up to 1MB in size (for viewer request and viewer response triggers) and 50MB in size (for origin request and origin response triggers).

Use cases

CloudFront Functions

• Cache key normalization – You can transform HTTP request attributes (headers, query strings, cookies, and even the URL path) to create an optimal cache key, which can improve your cache hit ratio.

• Header manipulation – You can insert, modify, or delete HTTP headers in the request or response. For example, you can add a True-Client-IP header to every request.

• URL redirects or rewrites – You can redirect viewers to other pages based on information in the request, or rewrite all requests from one path to another.

• Request authorization – You can validate hashed authorization tokens, such as JSON web tokens (JWT), by inspecting authorization headers or other request metadata.

Lambda@Edge

• Functions that take several milliseconds or more to complete.

• Functions that require adjustable CPU or memory.

• Functions that depend on third-party libraries (including the AWS SDK, for integration with other AWS services).

• Functions that require network access to use external services for processing.

• Functions that require file system access or access to the body of HTTP requests.