Amazon Web Services (AWS) have released [email protected] as generally available, allowing customers to run Node.js Lambda functions “at the edge” across AWS point-of-presence locations globally, which can enable dynamic response to end users with very low latency.
With [email protected] developers upload Node.js code to AWS Lambda , Amazon’s “serverless” service, and Lambda automatically runs and scales code with high availability at an AWS location close to end users, which improves latency and reduces origin load. [email protected] code is triggered by events from Amazon CloudFront , a global content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to end users with low latency and high transfer speeds.
[email protected] is optimised for latency sensitive use cases where end users are distributed globally and (ideally) all the information required to make a decision is available at the CloudFront edge, within the function and the request. This allows developers to:
- Inspect cookies and transparently rewrite URLs in order to perform A/B testing.
- Return dynamic content generated at the edge, for example, redirect unauthenticated users to a login page that is created on-demand.
- Respond with specific objects to customise the website the user sees based on the User-Agent header.
- Add, drop, or modify headers (subject to the following restrictions ) to direct users to different cached objects.
- Modify or condense headers or URLs to improve cache utilisation.
- Make HTTP requests to other Internet resources and use the results to customise responses (although developers should take care to minimise additional latency from making these requests).
A [email protected] function can be triggered in response to four different CloudFront events:
- Viewer Request – This event occurs when an end user or a device on the Internet makes an HTTP(S) request to CloudFront, and the request arrives at the edge location closest to that user. The event contains the incoming HTTP request.
- Viewer Response – This event occurs when the CloudFront server at the edge is ready to respond to the end user or the device that made the request. The event contains the HTTP response.
- Origin Request – This event occurs when the CloudFront edge server does not already have the requested object in its cache, and the viewer request is ready to be sent to the backend origin (e.g. Amazon EC2, or Application Load Balancer, or Amazon S3).
- Origin Response – This event occurs when the CloudFront server at the edge receives a response from the backend origin.
The diagram below from the AWS [email protected] documentation provides a useful pictorial aid for locating event triggers during the request/response lifecycle:
- Runtime Environment – The runtime environment currently only supports functions written in Node.js, and provides each function with 128 MB of memory, and no builtin libraries or access to /tmp.
- Timeouts – Functions that handle Origin Request and Origin Response events must complete within 3 seconds. Functions that handle Viewer Request and Viewer Response events must complete within 1 second.
- Web Service Access – Functions that handle Origin Request and Origin Response events must complete within 3 seconds can access the AWS APIs and fetch content via HTTP. These requests are always made synchronously with request to the original request or response.
- Versioning – After code is updated in the Lambda Console, a new version must be published a fresh set of triggers configured. Developers will have wait for the replication to complete. Functions must always be referred to by a version number; $LATEST and aliases do not apply.
- Headers – consult the ” Headers Restrictions ” documentation to determine which headers are accessible, restricted, read-only and blacklisted.
There is no free tier for [email protected] at this time – function duration is calculated from the time code begins executing until it returns or otherwise terminates, and customers are charged $0.00005001 for every GB-second used. As [email protected] functions have a fixed 128MB of memory available per execution, the duration charge is $0.00000625125 for every 128MB-second used. Note that [email protected] functions are metered at a granularity of 50ms, and not the standard AWS Lambda granularity of 100ms.
Additional information on AWS [email protected] can be found Jeff Barr’s post ” [email protected] – Intelligent Processing of HTTP Requests at the Edge ” on the AWS Blog, the AWS [email protected] product documentation , and the developer guide .