AWS CloudFront redirecting to S3 bucket

amazon-web-services amazon-s3 amazon-cloudfront

39,106

Solution 1

I found the issue. It is with cloudfront configuration. This blog helped me.

While defining the origin I have directly selected S3 bucket. We should enter the domain of the S3 bucket like telekha-test-www.s3-website.ap-south-1.amazonaws.com

Solution 2

Quick Solution

Use the regional domain name of your S3 bucket to configure the CloudFront distribution's origin, e.g.: {bucket-name}.s3.{region}.amazonaws.com.

Explanation

According to the discussion on AWS Developer Forums: Cloudfront domain redirects to S3 Origin URL, it takes time for DNS records to be created and propagated for newly created S3 buckets. The issue is not visible for buckets created in US East (N. Virginia) region, because this region is the default one (fallback).

Each S3 bucket has two domain names, one global and one regional, i.e:

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

If you configure your CloudFront distribution to use the global domain name, you will probably encounter this issue, due to the fact that DNS configuration takes time.

However, you could use the regional domain name in your origin configuration to escape this DNS issue in the first place.

CloudFormation Template

If you are using CloudFormation, you can use the RegionalDomainName output attribute of the AWS::S3::Bucket resource:

S3Bucket:
  Type: AWS::S3::Bucket

CloudFrontDistribution:
  Type: AWS::CloudFront::Distribution
  Properties:
    DistributionConfig:
      Origins:
        - DomainName: !GetAtt S3Bucket.RegionalDomainName

More information

As well, I would highly recommend to read this blog post on the future of S3 different path formats:

Amazon S3 Path Deprecation Plan – The Rest of the Story

Solution 3

The first thing to check if you think you are seeing this is to run the curl command below. If it returns HTTP/1.1 307 Temporary Redirect, then you are seeing this issue.

$ curl -I https://YOUR_CF_DOMAINNAME.cloudfront.net/

HTTP/1.1 307 Temporary Redirect
Content-Type: application/xml
Content-Length: 0
Connection: keep-alive
x-amz-bucket-region: ap-southeast-2
Location: http://yourS3bucketname.s3-ap-southeast-2.amazonaws.com/
Date: Wed, 12 Jul 2017 00:20:27 GMT
Server: AmazonS3
Age: 1775
X-Cache: Hit from cloudfront
Via: 1.1 someid.cloudfront.net (CloudFront)
X-Amz-Cf-Id: someguid==

The best description I found of this issue is:

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. ~ michael-sqlbot

Given this issue is actually due to the internal DNS propagation of the S3 bucket name (which is not 100% clear, but seems highly likely) that occurs when you configure the bucket in S3, then it should be possible to avoid this issue by configuring a public web site in S3 prior to configuring the Cloudfront distro, and per the doco, configure the S3 public web name as the cloudfront origin rather than the s3 bucketname.

For reference, I have both S3 bucket names and S3 website names configured as Cloudfront origins and I can say that they do both work! (eventually?)

References:

Solution 4

Turns out this is just a timing issue which fixes itself after a while if everything is configured correctly. More information can be found in this AWS forum thread.

Current accepted answer here and linked blog article suggest enabling static website for your S3 bucket and then changing CF origin to point to that static website. This solution does solve the redirect problem but with the side effect that you website is now available using both CF URL or your custom CNAME as well as using S3 URL.

View more solutions

39,106

Rajneesh

Updated on July 08, 2022

Comments

Rajneesh almost 2 years
I have created a CloudFront distribution to serve the static website. S3 is origin server. Now if we access CloudFront URL, it redirects to S3 location.

d2s18t7gwlicql.cloudfront.net or test.telekha.in

In the browser it is showing https://telekha-test-www.s3.ap-south-1.amazonaws.com/index.html#/dashboard

I am expecting https://test.telekha.in/#/dashboard

If I access https://test.telekha.in through curl it returns my index.html document

If I access http://test.telekha.in through curl it returns
```
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
```
But in browser both HTTP and HTTPS are redirecting to https://telekha-test-www.s3.ap-south-1.amazonaws.com/index.html#/

Please let me know how to resolve this issue.
Kiril over 6 years

Configuring origin with S3 URL will make content available using both S3 and CF URLs which might be undesirable.
Andy Hayden almost 6 years

The temporary fix, if you are hosting assets, is to make the bucket temporarily public, that way the redirected files are actually served up. This issue lasted less than 3 hours for me (now it's 200 OK).
openwonk about 5 years

I noticed that this issue was fixed when I switch origin to static site instead of bucket URL.
ggdx over 3 years

I gave up, made my self a coffee and came back, presto. Yep, timing, didn't take into account propagation times.
GG. over 3 years

@AndyHayden Exactly what happened for me too, waited about 3 hours before the issue solves itself. Thanks for the hint. Should be the actual answer.
Simon Hutchison over 3 years

If you are looking for a temporary fix, remove the local region from the CF origin URL. E.g. Set CF origin to yourS3bucketname.s3.amazonaws.com
Gambo over 3 years

This helped me out! Thx!
Rob Hodges about 3 years

I spent ages looking at my policies and scratching my head, restarting the distribution etc but just changing it to the region my bucket was in (London) solved it immediately. Thank you!
Gavin Sharp almost 3 years

While this might work around the original issue, using the S3 REST API endpoint (instead of the S3 website endpoint) is a valid choice (each have their trade-offs: docs.aws.amazon.com/AmazonS3/latest/userguide/…)
Eric almost 3 years

You saved my day!