1
votes

I've got a static-hosting enable S3 bucket. There's also a cloudfront distribution that is being powered by that bucket.

I've added a CNAME entry to the cloudfront distribution for "mywebsite.com"

and when I go to load "mywebsite.com" in my browser, it redirects to http://my-bucket.s3-us-west-2.amazonaws.com/index.html

Why is this redirect happening? how do I stop that hostname from being rewritten?

Edit: here's the setup details after some suggested changes:

  • cloudfront - alternate domain: mysite.com
  • cloudfront - alternate domain: www.mysite.com
  • cloudfront - origin: my-bucket.s3-website-us-west-2.amazonaws.com
  • route53 - hosted zone: mysite.com
  • route53 - A record: 12345.cloudfront.net
  • route53 - CNAME: www.mysite.com --> mysite.com

and the effects of this setup:

  • Loading: mysite.com --> 301 redirects to my-bucket.s3-website-us-west-2.amazonaws.com
  • Loading: www.mysite.com --> 301 redirects to my-bucket.s3-website-us-west-2.amazonaws.com
  • Loading: my-bucket.s3-website-us-west-2.amazonaws.com --> 200 Success
  • Loading: d1h3yk3zemxpnb.cloudfront.net --> 301 redirects to my-bucket.s3-website-us-west-2.amazonaws.com
  • Loading: http://my-bucket.s3.amazonaws.com/ --> permissions error
2
Wait a day and see if it is still happening. I've heard that some redirects take a while to update.John Rotenstein
Did you add the domain name in cloud front in "Alternate Domain Names" ?Stephen
See updates aboveKristian
Was the issue fixed? Even I'm seeing a similar issue.Deepak S

2 Answers

4
votes

The issue here is a side effect of a misconfiguration. This specific behavior may go away within a few minutes or hours of bucket creation, but the underlying issue won't be resolved.

When configuring a static website hosting enabled bucket behind CloudFront, you don't want to select the bucket name from the list of buckets.

On the Create Distribution page, in the Origin Settings section, for Origin Domain Name, type the Amazon S3 static website hosting endpoint for your bucket. For example, example.com.s3-website-us-east-1.amazonaws.com.

Note

Be sure to specify the static website hosting endpoint, not the name of the bucket.

http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-cloudfront-walkthrough.html#create-distribution

Selecting the example.com.s3.amazonaws.com entry from the list, rather than typing in the bucket's website hosting endpoint, would be the most likely explanation of this behavior.

S3 updates the DNS for the global REST endpoint hierarchy *.s3.amazonaws.com with a record sending requests to the right region for the bucket within a short time after bucket creation, and CloudFront appears rely on this for sending the requests to the right place. Before that initial update is complete, S3 will return a redirect and CloudFront returns that redirect to the browser... but all of this indicates that you didn't use the static website hosting endpoint as the origin domain name.

0
votes

From AWS support https://forums.aws.amazon.com/thread.jspa?threadID=216814


This is an expected behavior when you create a new bucket. The following pages explains the concept: http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html

"Amazon S3 routes any virtual hosted–style requests to the US East (N. Virginia) region by default if you use the US East (N. Virginia) endpoint (s3.amazonaws.com), instead of the region-specific endpoint (for example, s3-eu-west-1.amazonaws.com). When you create a bucket, in any region, Amazon S3 updates DNS to reroute the request to the correct location, which might take time. In the meantime, the default rule applies and your virtual hosted–style request goes to the US East (N. Virginia) region, and Amazon S3 redirects it with HTTP 307 redirect to the correct region."

Please give some time to S3 until the domain name becomes ready (normally an hour or so). Also, please note, errors are cached in CloudFront by default. This means "307 Temporary Redirect" is cached for 300 seconds unless you change it: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html

In order to test your cloudfront again, please make sure the cache has been invalidated: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

Hope that helps.


The default cache policy has

Default TTL 86400

That is, 24h, so you may want to invalidate it rather than wait.

From https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html


If you use the AWS command line interface (CLI) for invalidating files and you specify a path that includes the * wildcard, you must use quotes (") around the path.

For example: aws cloudfront create-invalidation --distribution-id distribution_ID --paths "/*"


Another thing you can do if nothing of the above works and you are in development and just want to get something accessible is to change the reference or your bucket from

global — {bucket-name}.s3.amazonaws.com

to

regional — {bucket-name}.s3.{region}.amazonaws.com

As explained on the forum this will bypass the attempt to use the replicated buckets by going just to one, which will not fail and therefore you won't get a redirect.

You will see that easily with curl

$ curl -I http://blah.cloudfront.net/x.svg
HTTP/1.1 307 Temporary Redirect
Content-Type: application/xml
Connection: keep-alive
x-amz-bucket-region: eu-west-1


$ curl -I http://blah.cloudfront.net/x.svg
HTTP/1.1 200 OK
Content-Type: image/svg+xml
Content-Length: 657
Connection: keep-alive