watsonarw / https-static-site-cloudformation Goto Github PK

There is a current limitation with this template where all paths must be referenced by the full file name, and not the directory name.

e.g a site with the path /foowhere /foo/index.html exists, does not serve the index.htmlfile and instead responds with the error file.

This is due to a limitation with Cloudfront, and the workaround is to use the bucket's web facing url, and point Cloudfront at the web origin instead of as an S3 origin. See this stackoverflow question.

Amazon's recommended fix is to use Lambda@Edge to rewrite the path when it gets the file from S3.

The response should be cached by Cloudfront, and only invoke the lambda on cache misses.

Acceptance Criteria

1. Directories serve index.html with /
   Given I have a directory foo with an index.html file
   When I try to access the directory example.com/foo/ (with trailing /) via cloudfront
   Then I am served the foo/index.htmlfile

2. Directories serve index.html without /
   Given I have a directory foo with an index.html file
   When I try to access the directory example.com/foo (without trailing /) via cloudfront
   Then I am served the foo/index.htmlfile

3. Doesn't work without index.html
   Given I have a directory foo without an index.html file
   When I try to access the directory example.com/foo (without trailing /) via cloudfront
   Then I am served the error page

4. Named files don't work as directories
   Given I have a file foo.html
   When I try to access the example.com/foo via cloudfront
   Then I am served the error page

5. Named files don't work as directories with /
   Given I have a file foo.html
   When I try to access the example.com/foo/ via cloudfront
   Then I am served the error page

6. Named files continue to work as files
   Given I have a file foo.html
   When I try to access the example.com/foo.html via cloudfront
   Then I am served the /foo.html

Hey, this thing is awesome. I have a production site running based off of this template, and the only hiccup I encountered is that the cloudfront distribution generated points directly to the s3 bucket URL (http://bucketname.s3.amazonaws.com), not the bucket's 'web facing' url (e.g. http://bucketname.com.s3-website-us-east-1.amazonaws.com). For me, this allowed the home page to work, but all subpages were broken until I updated the origin URL.

I also had to add the naked domain to the distributions 'alternate domain names' to get it to redirect to www.

One other feature suggestion -- it might be useful to allow the user to specify a different bucket name than the URL. This was a pain point for me because I had the website hosted on another AWS account (just using s3) where the bucket name was the domain, and since you can't use an existing bucket name, I had to shut that one down first.

It's possible to access the S3 bucket directly, without cloudfront. Need to fix this and ensure access is only possible via the CDN.

Cloudformation now supports creating the OAI.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-cloudfrontoriginaccessidentity.html

We should be able to move the OAI creation into cloudfront