Why S3 website redirect location is not followed by CloudFront?

I ran into this problem recently and I found a workaround that seemed to work.

I created a Cloudfront distribution with a custom origin pointing to the S3 static website hostname instead of the bucket hostname. In the OP's case, the desired origin would be.

mysite.s3-website-us-east-1.amazonaws.com

Hitting a Cloudfront distribution just using the bucket as the origin does not work because the bucket does not actually serve redirects. It only serves files and stores metadata.

Hope that helps.


Analysis

According to the documented Request and Response Behavior, and Supported HTTP Status Codes for Custom Origins, Amazon CloudFront doesn't follow Redirects, unfortunately:

[...] After you configure the redirect, the first time an end user submits a request for the object, CloudFront Front sends the request to the origin, and the origin responds with a redirect (for example, 302 Moved Temporarily). CloudFront caches the redirect and returns it to the end user. CloudFront does not follow the redirect. [emphasis mine]

Of course, you are using Amazon S3 rather than a custom origin, and a related section is notably absent from Request and Response Behavior for Amazon S3 Origins, but given Amazon S3 redirects have only been added fairly recently ( see Amazon S3 - Support for Website Redirects), it might just be missing there still.

Accordingly I venture the guess that you are not receiving an empty file with HTTP status code 200 OK, rather a HTTP status 301 Moved Permanently with no body at all - have you actually checked this with a browser or eventually only with a command line tool like e.g. cURL or HTTPie? The latter tools usually require an explicit parameter to follow redirects, so this might easily get unnoticed.

Potential Solution

If the analysis turns out to be correct, you'd need to configure the redirect to explicitly target CloudFront instead, again see Redirects:

You can configure your web server to redirect requests to one of the following locations:

  • The new URL of the object on the origin server. When the end user follows the redirect to the new URL, the end user bypasses CloudFront and goes straight to the origin. As a result, we recommend that you not redirect requests to the new URL of the object on the origin.

  • The new CloudFront URL for the object. When the end user submits the request that contains the new CloudFront URL, CloudFront gets the object from the new location on your origin, caches it at the edge location, and returns the object to the end user. Subsequent requests for the object will be served by the edge location. This avoids the latency and load associated with viewers requesting the object from the origin. However, every new request for the object will incur charges for two requests to CloudFront.