Amazon Web Services (AWS) have released Lambda@Edge 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 Lambda@Edge 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. Lambda@Edge 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.
Lambda@Edge 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 Lambda@Edge 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 Lambda@Edge documentation provides a useful pictorial aid for locating event triggers during the request/response lifecycle:
Lambda@Edge developers should be familiar with the standard AWS Lambda development paradigm, and also must develop code to work within the following constraints:
- 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 Lambda@Edge 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 Lambda@Edge functions have a fixed 128MB of memory available per execution, the duration charge is $0.00000625125 for every 128MB-second used. Note that Lambda@Edge functions are metered at a granularity of 50ms, and not the standard AWS Lambda granularity of 100ms.
Additional information on AWS Lambda@Edge can be found Jeff Barr’s post "Lambda@Edge – Intelligent Processing of HTTP Requests at the Edge" on the AWS Blog, the AWS Lambda@Edge product documentation, and the developer guide.