CloudFront Functions, du serverless pour applications edge

It’s over 10 years since AWS established its CloudFront content delivery network to accelerate transfer speeds and reduce latency on the global distribution of data, apps, videos, and APIs. This CDN (content delivery network) has nearly 230 points of presence – 215 peripheral locations and 13 regional intermediate caches – in 90 cities in 47 countries. The public cloud provider complements it with serverless functions to perform tasks at the edge of the network, which can be computationally intensive or much simpler to process.

For demanding operations (complex customizations for example), AWS already launched in 2017 the programmable serverless environment Lambda @ Edge. The functions developed with this service run in a regional cache located in the AWS Region closest to where the customer is serving their content. For simpler operations, such as HTTP / HTTPS requests that can be performed by functions with a very short lifespan, AWS is launching another serverless edge execution capability this week, CloudFront Functions. For this second category of use case, you need a flexible programming experience, with performance, scaling and cost criteria that allow these functions to be performed on every request, Danilo Poccia explains in a post. , Chief Evangelist at AWS.

When you need to use capabilities that CloudFront Functions does not provide, such as network access, you can still use Lambda @ Ege before and after the content is cached by CloudFront. (Credit: AWS)

A price divided by 16 compared to Lambda @ Edge

CloudFront Functions promotes itself as a scripting platform that allows you to run lightweight JavaScript code in one of CloudFront’s edge points of presence (over 218) for about 1 / 16th of the price that would be charged with Lambda @ Edge. Among the processes related to web requests that are typically eligible for this service, AWS cites the manipulation of cache keys (identifier of objects used to check whether they are already in the cache), URL rewriting and redirection (for example to redirect an unauthenticated user or for A / B testing purposes), the manipulation of http headers or, again, the access authorization (implementation of a control for the consultation of the content delivered by CloudFront, by validating JMAC or JWT tokens).

AWS explains that CloudFront Functions uses a process-based isolation model while that of serverless Lambda and Lambda @ Edge environments relies on virtual machines. “To do this, we had to apply certain restrictions such as avoiding network and file system access,” AWS said in its post. The functions run for less than a millisecond. In this way, they can process millions of requests per second, with virtually no noticeable impact on the overall performance of the CDN, the provider assures us.

A collection of code to start building functions

Like Lambda @ Edge, CloudFront Functions runs code in response to events generated by CloudFront. More specifically, the functions are triggered by a display request from the user. The service is accessed from the AWS console. In his post, Danilo Poccia gives an example of use consisting in personalizing the content of a website according to the countries where the users are located.

In a table, AWS presents the main differences between the two services including the language used, Node.js and Python for Lambda @ Edge, JavaScript for CloudFront Functions. (Credit: AWS)

CloudFront Functions is natively integrated with the CloudFront CDN. On GitHub, AWS offers a collection of code to get started building functions, in the CloudFront console, through the IDE or CLI and APIs. The functions can then be tested from a CloudFront distribution with an S3 bucket as the source. The use of CloudFront Functions is billed at $ 0.1 per million invocations.