Cloudfront Routing Priority

When you have both a Lambda@Edge function configured for origin response events and custom error pages set up in CloudFront, it's important to understand their execution order and priority.

The Lambda@Edge origin response function executes after CloudFront receives a response from your origin (in this case, S3) but before CloudFront caches the object. This happens regardless of whether the origin returns a successful response or an error code.

However, if your origin returns a 403 or 404 error, and you've configured custom error pages for these status codes, the custom error response configuration takes precedence after the Lambda@Edge function has executed. This means:

1. CloudFront receives the request for an invalid URL
2. CloudFront forwards the request to your S3 origin
3. S3 returns a 403 or 404 error
4. Your Lambda@Edge origin response function executes and can modify the response
5. After the Lambda function completes, CloudFront checks if there's a custom error page configuration for the status code
6. If configured, CloudFront serves the custom error page (/index.html) with a 200 status code instead of the original error

This sequence ensures that your single-page application (React) can handle client-side routing properly, as the index.html file will be served for routes that don't exist in S3 directly.

It's worth noting that when CloudFront serves a custom error page with a 200 status code, certain devices like firewalls and corporate proxies won't intercept the response, which is beneficial for single-page applications that handle routing on the client side.
Sources
CloudFront events that can trigger a Lambda@Edge function - Amazon CloudFront
Optimize CloudFront to serve single-page applications | AWS re:Post
Change response codes returned by CloudFront - Amazon CloudFront