AWS Lambda@edge. How to read HTML file from S3 and put content in response body

Question

Specifically, in an origin response triggered function (EX. With 404 Status), how can I read an HTML file stored in S3 and use its content for the response body?

(I would like to manually return a custom error page just as CloudFront does, but choosing it based on cookies).

NOTE: The HTML file in S3 is stored in the same bucket of my website. OAI Enabled.

Thank you very much!

Leatherwood

What have you tried so far? – Would

I've stored the whole HTML files content in constants inside the function itself, but I would like to access the files and load their content only when needed and be able to modify them without having to modify the lambda function. – Leatherwood

It would be nice to imitate CloudFront behaviour handling custom error pages, but it is not explained in the documentation. By testing, I'm pretty sure CloudFront dynamically loads the file and returns the custom error page in the body of the response. NOTE: In the case of a 404 Error, the bad URL doesn't change in the viewer side when the response is received. – Leatherwood

Answer 1

Lambda@Edge functions don't currently¹ have direct access to any body content from the origin.

You will need to grant your Lambda Execution Role the necessary privileges to read from the bucket, and then use s3.getObject() from the JavaScript SDK to fetch the object from the bucket, then use its body.

The SDK is already in the environment,² so you don't need to bundle it with your code. You can just require it, and create the S3 client globally, outside the handler, which saves time on subsequent invocations.

'use strict';
const AWS = require('aws-sdk');
const s3 = new AWS.S3({ region: 'us-east-2' }); // use the correct region for your bucket

exports.handler ...

Note that one of the perceived hassles of updating a Lambda@Edge function is that the Lambda console gives the impression that redeploying it is annoyingly complicated... but you don't have to use the Lambda console to do this. The wording of the "enable trigger and replicate" checkbox gives you the impression that it's doing something important, but it turns out... it isn't. Changing the version number in the CloudFront configurarion and saving changes accomplishes the same purpose.

After you create a new version of the function, you can simply go to the Cache Behavior in the CloudFront console and edit the trigger ARN to use the new version number, then save changes.

---

¹currently but I have submitted this as a feature request; this could potentially allow a response trigger to receive a copy of the response body and rewrite it. It would necessarily be limited to the maximum size of the Lambda API (or smaller, as generated responses are currently limited), and might not be applicable in this case, since I assume you may be fetching a language-specific response.

²already in the environment. If I remember right, long ago, Lambda@Edge didn't include the SDK, but it is always there, now.

Microsecond