Hide S3 and Cloudfront endpoints

You need to specify the target hostname and protocol in the routing rules. This forces the Location: to have the correct (desired) hostname.

The simplest approach for redirecting almost everything is creating a routing rule that matches 403 Forbidden (since S3 denies everything by default) and points where you want things to go.

<RoutingRules>
 <RoutingRule>
  <Condition>
    <HttpErrorCodeReturnedEquals>403</HttpErrorCodeReturnedEquals>
  </Condition>
  <Redirect>
   <Protocol>https</Protocol> 
   <HostName>target.example.com</HostName>
   <ReplaceKeyWith></ReplaceKeyWith>
  </Redirect>
 </RoutingRule>
</RoutingRules>

All requests should redirect to https://target.example.com/, unless the requested URL matches an existing object with the public-read ACL, or an index document.

If this doesn't behave as expected, you can also change it to match on 404, but don't do that. If 404 works, this means your bucket policy is too permissive, allowing unauthenticated users to list your bucket contents... so, don't change this -- fix your policy. Use 403 here.

However, curl and web browsers give the wrong content

Actually, they give the right content, in context. (Stick with me, here...)

The problem -- technically speaking -- is that you are actually wanting/expecting a response that would in fact be incorrect -- behavior that would be wrong if it actually worked the way you expected, based on the request being made.

Take a look at the request headers using curl -v. They may be connecting to an address retrieved by querying eu.example.com but check this request header:

> Host: www.example.com

The browser is actually getting exactly what it asked for.

This is why you can't assign the same alternate domain name to two CloudFront distributions. CloudFront -- like essentially all web servers -- uses the Host: header sent by the browser to understand what site the browser wants to see. Web servers can't see the DNS path that got you to them. The fact that you can do this while connecting to an IP address returned for a different site is no real surprise -- pick any CloudFront IP and forge a Host: header for a different site, and it is pretty likely to work, because there are good odds that the CloudFront equipment listening on that address can find the configuration within CloudFront and service the request.

This configuration cannot be done using only CloudFront and Route 53.

You need a proxy server in EC2 in the target region in the EU to act as a target for the eu domain in DNS, rewrite the Host: header, and forward the modified request to CloudFront.