cloudfront: Pass viewer host to origin response

To pass viewer host information from a Viewer Request to an Origin Response in CloudFront, you're encountering a fundamental limitation in how CloudFront processes requests and responses.

The issue is that the Origin Response function doesn't have direct access to the headers or query strings that were set in the Viewer Request phase. This is because the Origin Response function only sees the response from the origin and limited request information.

However, there are a few approaches you can take to solve this problem:

1. Use CloudFront-Viewer-Country header: CloudFront automatically adds headers like CloudFront-Viewer-Country that can be used in your Origin Response function. To access these headers, you need to explicitly include them in your cache policy or origin request policy.

2. Modify the request path or URI: In your Viewer Request function, you could modify the request path to include information about the domain. For example, you could rewrite the request for "/index.html" to "/index.html?domain=example.com". Your origin would still serve the same index.html file, but your Origin Response function could extract the domain information from the request URI.

3. Use Origin Request instead of Origin Response: An Origin Request function has access to the full request including any modifications made by the Viewer Request function. You could use an Origin Request function to modify the request to the origin based on the host header, and then have the origin return different content based on those modifications.

4. Store domain information in a cookie: Set a cookie in the Viewer Request function with the domain information, and then access that cookie in the Origin Response function.

Remember that to make CloudFront request headers available in your edge functions, you need to explicitly include them in your cache policy or origin request policy for the specific behavior.

For your specific use case of modifying index.html based on the domain, the most straightforward approach would be to use an Origin Request function to modify the request to your origin (e.g., by adding a custom header or query parameter) and then have your origin serve a dynamic version of index.html based on that information.
Sources
Lambda@Edge example functions - Amazon CloudFront
How do I make CloudFront request headers available in my edge compute functions? | AWS re:Post
OriginRequestPolicy - Amazon CloudFront

You mentioned several buckets as an undesired alternative, so I'm assuming the files you want to modify are and should remain stored in one S3 bucket.

A reasonably cost-efficient and technically performant option that satisfies the condition would be to use S3 Object Lambda to put S3 in charge of serving the modified content to CloudFront. You would use a CloudFront function associated with viewer requests to add the host header as custom header or query string parameter. The S3 Object Lambda Access Point configured for your S3 bucket would call Lambda to serve customised content based on the custom header or query string.

Setting up S3 Object Lambda for use with CloudFront is explained in this blog post: https://aws.amazon.com/blogs/aws/new-use-amazon-s3-object-lambda-with-amazon-cloudfront-to-tailor-content-for-end-users/. There are more details in this S3 documentation section: https://docs.aws.amazon.com/AmazonS3/latest/userguide/transforming-objects.html.

To inject the Host header value as a custom header or query string parameter, you would use the updateRequestOrigin() helper method in the CloudFront function. It's documented here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/helper-functions-origin-modification.html.

Note that you have to set CloudFront to include the custom header (or query string parameter, if you prefer) in the cache key. Otherwise, the initial custtom response will be correct but subsequent requests served from the cache will cached content for the first request, ignoring the Host header. The cache key settings are documented in more detail here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-key-understand-cache-policy.html#cache-key-understand-cache-policy-settings

Key benefits of this design include costs and performance. Viewer request functions have to be executed for every request for the CF cache distribution, even when the content is returned from the cache, and CF functions are several times less expensive to run than Lambda@Edge functions. Performance-wise, CloudFront functions are executed locally at every CF edge location and complete in less than 1 millisecond. Lambda@Edge functions, on the other hand, can only be executed at the CloudFront's 13 Regional Edge Cache (REC) locations globally, which can divert requests thousands of kilometres/miles away from the shortest path between your users' closest CF edge locations and the S3 bucket's region, increasing the latency of every single request, even when content is cached.

With the suggested design, the CF function runs in under 1 ms locally at every CF edge location. If content matching the modified request is found in the local cache, the CF edge server serves it from there. The only additional cost from this customisation would be the CF function call, and it's the most cost-effective alternative for running custom code in CloudFront.

If the content is not present in the cache of the local CF edge location (and if CF Origin Shield isn't enabled), it will get sent from the CF edge location directly to the S3 Object Lambda Access Point in the bucket's region, without an additional detour to a REC location to run Lambda. When the request arrives at the S3 Object Lambda Access Point, S3 calls your Lambda function local to the region. The function reads the original, unmodified index.html from your bucket, make the modifications you want, and return the result to the CloudFront edge location (or REC in the case Origin Shield is enabled) where it will be cached according to your chosen cache policy.

You can choose the Arm64 processor architecture for your Lambda function used with S3 Object Lambda to optimise its costs and performance even slightly further. Choosing the Arm64 architecture from the start is a good practice and doesn't require any specific considerations for a simple function like in this case. Choosing the processor architecture for Lambda is documented here: https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html