createRequestOriginGroup with originOverrides.hostHeader always causes 502 "invalid value for origin rewrite" regardless of value

Question

Environment: CloudFront Functions JavaScript Runtime cloudfront-js-2.0. Feature used: createRequestOriginGroup() with originOverrides.hostHeader. Origin setup: Primary is S3, Secondary is ALB (HTTP only, custom port, no TLS).

Background / Intent:

I have a CloudFront distribution with a default behavior (*) using an Origin Group. The primary origin is an S3 bucket, and the secondary origin (failover) is an ALB pointing to an EC2 backend.

The problem is with the Origin Request Policy. If I set it to "All Viewers", S3 receives the CloudFront domain (e.g. myDomain.cloudfront.net) as the Host header, which causes S3 to return 403, triggering failover to ALB on every request. The primary origin is effectively broken. If I set it to "All Viewers Except Host", S3 works correctly, but now ALB receives its own domain (e.g. my-alb.us-east-2.elb.amazonaws.com) as the Host header instead of the CloudFront domain. My backend application requires the CloudFront domain as the Host header for routing logic.

So I tried using originOverrides.hostHeader in createRequestOriginGroup() to override the Host header sent to the ALB origin specifically, while keeping "All Viewers Except Host" as the Origin Request Policy so that S3 continues to work.

Problem:

Any use of originOverrides.hostHeader causes a 502 error immediately. This happens with any value set for hostHeader, including the CloudFront domain, the ALB domain, or a completely unrelated domain like www.example.com.

Full 502 error: "502 ERROR - The request could not be satisfied. The CloudFront function returned an invalid value for origin rewrite. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation. Generated by cloudfront (CloudFront). Request ID: {Request ID}"

Minimal reproduction:

import cf from 'cloudfront';

async function handler(event) {
        cf.createRequestOriginGroup({
            "originIds": [
                { "originId": "my-s3-origin" },
                {
                    "originId": "my-alb-origin",
                    "originOverrides": {
                        "hostHeader": "myDomain.cloudfront.net"  // any value causes the same 502
                    }
                }
            ],
            "failoverCriteria": {
                "statusCodes": [403, 404, 500, 502, 503]
            }
        });

return event.request;
    }

I've tried multiple values for hostHeader: my CloudFront domain, the ALB domain, and unrelated domains like www.example.com. All of them cause the same 502.

What I've confirmed:

1. Removing originOverrides entirely results in no 502 and works fine.
2. Any hostHeader value always causes a 502.
3. The ALB origin protocol is HTTP only with no TLS or certificate involved, so SSL mismatch is not the cause.
4. Both originId values exactly match the Origin names in the distribution.
5. The runtime is cloudfront-js-2.0.
6. createRequestOriginGroup() without originOverrides works fine.

It appears that simply having originOverrides with hostHeader is enough to trigger the 502, regardless of the value.

Question:

Is originOverrides.hostHeader in createRequestOriginGroup() currently supported and working? If not, what is the recommended workaround to make the ALB backend receive a specific Host header (e.g. the CloudFront domain) while keeping "All Viewers Except Host" as the Origin Request Policy so that the S3 primary origin continues to function correctly?

Thanks in advance for any help or insight!

Florian Turnwald · Answer

The behavior you are seeing is expected: with "All Viewers Except Host", because CloudFront always overrides the Host header with the origin's domain name to ensure the request reaches the correct endpoint (especially critical for S3).

The 502 error when using `originOverrides.hostHeader` suggests a conflict between the Origin Request Policy and the Function runtime's attempt to modify a protected header for a specific origin in a group. So, CloudFront Functions currently lacks the "Origin Request" context that Lambda@Edge has (which triggers after the origin is selected). As far as I know, using a custom header is the only way to satisfy S3's requirement while providing the necessary routing data to your ALB without hitting the 502 validation error in `createRequestOriginGroup`.

Since you want to stay within CloudFront Functions and avoid a 502, you should shift the routing logic from the Host header to a custom header:
- Keep Policy: Maintain "All Viewers Except Host" so S3 continues to work.
- Pass CloudFront Domain: In your Origin Request Policy, ensure the original Host (your CloudFront domain) is forwarded as a custom header, e.g., `X-Forwarded-Host`.
- Update Backend: Update your ALB/EC2 application logic to use the value of `X-Forwarded-Host` for routing instead of the Host header.

re:Post Agent · Answer

Based on the error message "The CloudFront function returned an invalid value for origin rewrite," this indicates that CloudFront Functions is rejecting the way the host header is being set through the originOverrides parameter.

The issue you're encountering appears to be related to how CloudFront Functions validates header rewrites. When using CloudFront Functions, there are restrictions on which headers can be modified and how they can be set. The error suggests that the originOverrides.hostHeader approach may be triggering a validation error within the CloudFront Functions runtime.

For your specific use case, here's a recommended workaround:

Instead of using originOverrides.hostHeader in createRequestOriginGroup(), you can manually set the host header in your CloudFront Function based on which origin will be used. Since you need different host header values for S3 versus ALB, you can conditionally set the host header in the request object before returning it:

```javascript
import cf from 'cloudfront';

async function handler(event) {
const request = event.request;

cf.createRequestOriginGroup({
"originIds": [
{ "originId": "my-s3-origin" },
{ "originId": "my-alb-origin" }
],
"failoverCriteria": {
"statusCodes": [403, 404, 500, 502, 503]
}
});

// Manually set the host header for the ALB failover case
// This will be used when failover occurs
request.headers['host'] = { value: 'myDomain.cloudfront.net' };

return request;
}
```

However, this approach has a limitation: the same host header will be sent to both origins. To work around this while keeping S3 functional, you may need to reconsider your architecture:

1. Use separate cache behaviors with different origin request policies for different URL patterns
2. Configure your S3 bucket to accept the CloudFront domain as a valid host header
3. Use Lambda@Edge instead of CloudFront Functions, which provides more flexibility in origin selection and header manipulation
4. Consider using two separate distributions or cache behaviors to handle S3 and ALB origins independently

The originOverrides feature in createRequestOriginGroup() may have limitations or validation rules that aren't fully documented, and your experience suggests it may not be working as expected in the current runtime version.  
**Sources**  
[Troubleshoot CloudFront function URI rewrite issues | AWS re:Post](https://repost.aws/knowledge-center/cloudfront-uri-rewrite)  
[HTTP 502 status code (Bad Gateway) - Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html)

createRequestOriginGroup with originOverrides.hostHeader always causes 502 "invalid value for origin rewrite" regardless of value

Add your answer

Relevant content