Many applications need the lowest latency possible, but still want to execute some form of logic. While Content Delivery Networks (CDNs) are traditionally static, it's becoming increasingly common to run code at the edge of the network, closest to the user.
Doesn't AWS Already Have Lambda@Edge?
CloudFront Functions isn't the first or only way to run your custom code at the edge of a CDN. AWS has had Lambda@Edge for a while now, which lets you run any Lambda function on a CDN edge, albeit for three times the cost.
This cost prohibits a lot of simple transformation functions from being very viable to run at the edge. In many cases, you don't need to do more than a simple string manipulation or basic request/response. These can be executed instead by short-lived, basic functions.
Hence the need for CloudFront Functions. They're only able to run lightweight JavaScript code, but they run at all CloudFront CDN edge nodes for 1/6 of the price of Lambda@Edge. In fact, that's even cheaper than Lambda itself is.
Since it's only lightweight JS, the uses for it are a lot narrower. But, there are still quite a few operations that it's good for, such as:
- Header manipulation
- URL redirects or rewrites
- Request authorization
- Cache key normalization
You have two options for when to run CloudFront Functions: either before or after CloudFront fetches the response from the CDN. If you're modifying URLs or validating authentication tokens, you may want to run before. If you're just modifying outgoing headers, it may not matter.
One thing it can't do is manipulate content from the origin server before it is cached, i.e. on the Origin Response; you can only run functions on viewer request, or viewer response. For anything else, you'll need to use Lambda@Edge.
Functions should run for a maximum execution time of less than 1 millisecond. This ensures performance is good even across millions of requests. CloudFront functions use a new process-based isolation model with limited filesystem and network access, which should be a performance improvement over Lambda's traditional VM solution.
In exchange for 1/6 of the cost, you get a total package size of 10 KB, and 2MB of memory. Use it wisely.
Using CloudFront Functions
To start, you will of course need to be using a CloudFront CDN. If you're not, and want to get started with one, you can read our guide to setting one up.
From the CloudFront Console, click on "Functions" in the sidebar and create a new function:
Give it a name, and you will then be brought to a screen where you can build, test, publish, and deploy the function.
Of course, the code you write will vary wildly depending on your goals. For this tutorial, I'll simply make a completely useless function that changes every status code to 404 and turns off the website, because that's easy to test.
Make sure to click "Save" after writing code, before moving on to the next step, testing. You're given a few sample test events based on different event types, for which you can choose the URL and request headers the client is sending.
It will fetch a response from the CDN like it would in production. This should make it easy to test any function before going live with it.
Then, on the next page, click "publish" to save your changes to the production version of the function. This doesn't apply it to the CDN automatically though; you will need to associate it with a CloudFront distribution, or multiple distributions.
You will of course want to test that the production version is working properly. Head over to your CDN and you should see the function being applied. In this case, the function is doing its job of making my example website entirely unusable.
If it's not working, you may want to consider adding
console.log()
statements, which will get sent directly to AWS CloudWatch. This is the only available form of logging, besides basic metrics, as the functions are very lightweight. For more info, you can read AWS's guide on logging in CloudFront Functions.