Specifying different error behaviors for different S3 origins on CloudFront

Question

Hello,
I have the following situation and I need help on how to proceed:

- I have a multi-page website in a private S3 bucket. It uses an OAI to allow a CloudFront distribution to distribute this website at `example.com`.

- I have a single-page application hosted in another private S3 bucket. It uses an OAI to allow the same CloudFront distribution to distribute the website at `example.com/app`. The CloudFront distribution contains an "Additional Behavior" which directs requests to the path `/app*` to the app's S3 bucket.

My problem lies in the fact that I need different error behaviors for both origins. The first origin, the S3 bucket containing the website, returns `404.html` on 404 Not Found. This is simple enough to do; I can specify the error response for the distribution to use this filepath. The problem is that the second origin, the SPA served at `example.com/app`, needs to return its `index.html` document on 404, since it is an SPA. I cannot specify error handling in CloudFront on a per-origin basis.

I have two known workarounds to this issue:
1. Use the static website feature on S3 for the SPA and specify its error document there.
2. Create a Lambda@Edge function to somehow customize the error handling behavior for URIs to `/app*`.

My understanding is that it is recommended to avoid the static website feature of S3 and instead use an OAI to CloudFront, so I'd prefer to implement option 2. I am having trouble writing the necessary function however, and I can't find any examples where someone has implemented something similar. Any guidance or help on this issue would be appreciated - either in terms of accomplishing the above or if there is a superior strategy altogether.

Answer

You can create a **Lambda@Edge** function that triggers on the "Origin Response" event. In the function, check if the response is a `404` and the request URI starts with `/app`; if so, modify the response to return your SPA's `index.html` with a `200` status code. Deploy this Lambda function to your CloudFront distribution, associating it with the cache behavior for your SPA.

As example of your **Lambda@Edge**:

```python
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const response = event.Records[0].cf.response;

if (response.status === '404' && request.uri.startsWith('/app')) {
        response.status = '200';
        response.statusDescription = 'OK';
        response.headers['content-type'] = [{ key: 'Content-Type', value: 'text/html' }];
        response.body = 'Your SPA index.html content goes here';
    }

callback(null, response);
};
```

**Key Sources:**
- [Lambda@Edge example functions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html)

Answer

For anyone stumbling upon this, here is how I ended up solving it:

Since my SPA origin should always serve index.html regardless of the path, instead of intercepting the response at error-time, I simply change the URI for all requests to the path to `/app/index.html`. That way, when CloudFront receives the path `/app/page1` or `/app/page2`, etc., they are all converted to `/app/index.html` under the hood. I implemented this using a simple Lambda@Edge function, like this:

export const handler = (event, context, callback) => {
        const request = event.Records[0].cf.request;
        request.uri = "/app/index.html"
        return callback(null, request);
    };

I then associated this function to both the `/app` and `/app/*` behavior in my CloudFront distribution.

My only lingering question is why a vanilla CloudFront function didn't work. I tried this:

function handler(event) {
        var request = event.request;
        var uri = request.uri;
    
        if (uri.startsWith("/app")) {
            request.uri = "/app/index.html"
        }
        return request
    }

But it would give me 404 errors when I tried to use it...

Specifying different error behaviors for different S3 origins on CloudFront

Relevant content