Deploying front-end websites to S3 with CloudFront | Hacker News Reader

Deploying front-end websites to S3 with CloudFront

ilhicas.com

57 pointsilhicas29 comments

You should have a look at AWS Amplify Console https://aws.amazon.com/amplify/console/ It’s specifically designed to do most of this for you. I’ve been using it for static site work recently and it’s awesome. It also does plenty more and can be used for full stack dev but it’s great if you just need static site hosting and build pipelines. No need to have the build locally and uses gitops for build and auto generates environments based off branch name patterns.

If it's just a personal website, you might find it easier to use GitHub Pages (or GitLab's equivalent) and Cloudflare. Both are free for any reasonable personal website usage.

If you don't want to run a build of your static site generator on your computer and upload the result to GitHub every time you make a change, you can just use Jekyll and GitHub will build it for you. I think GitLab supports other static site generators as well. This technique is how https://www.snazz.xyz works.

Yes, https://netlify.com is great for this too and supports most static site generators.

CF is not necessary anymore for SSL since GH can issue LetsEncrypt certificates automatically. https://help.github.com/en/github/working-with-github-pages/...

True. I find that the other features (analytics, better DNS interface, caching) make it worthwhile for me. Also, the original article mentioned CloudFront.

I've always wondered why Amazon's own CodePipeline service could not deploy a commit of a HTML/CSS static sites straight to S3. They can deploy from CodeCommit straight to Elastic Beanstalk easily enough, but for years I have been asking for an S3 bucket as a destination which would make deploying our static website a piece of cake.

As it is, we have had to use BitBucket as the repo for our website, and we use the Pipelines feature on there to deploy to S3. Would be nice not to have to use a third party service to do something that AWS's own infrastructure makes unreasonably complex and difficult.

I'm not sure I understand this comment. I have a simple script (under 100 lines) using the aws sdk that pushes my assets to an s3 bucket where my site is hosted. I'm able to trigger it with an npm script with a command `npm run deploy`.

I've found lots of scripts online to do it, but the issue is that we shouldn't really resort to scripting for this. CodePipeline already has a nice interface where I can choose the Elastic Beanstalk environment where I wish to deploy the code. Zero scripting required. Why can't they have a drop down where I can specify S3, and the Bucket name to deploy to as well?

After all, they offer S3 as a service where we can deploy static sites, so why not in their pipeline service offer an S3 bucket as a valid destination for the code?

My BitBucket pipeline I described above has less than 10 lines of YAML to define which S3 bucket to push the committed changes to, so already, a 3rd party workaround is 10x less code than your 'AWS only' workaround. This shouldn't be the case.

AWS Amplify is the service that works as you’ve described.

Configuring CORS is probably the biggest pain about this approach and is necessary if you want to send data to and from an API. This guide should probably mention it or link another guide.

I've found a fairly workable solution is to have an origin for the API in CloudFront and a behaviour to route /api/* to that origin. Saves any CORS headaches. Obviously this won't work in all cases.

Wasn't aware of this, will definitely try it next time around. Thanks!

Here's a writeup on the details. https://medium.com/@chad.h.dalton/how-we-reduced-our-api-cal...

Just remember, the route prefix you use to define the CloudFront behavior will also be added to the request sent to the origin server. So in this case, all routes defined by the API must be prefixed with `/api/`. This makes it hard to refactor existing APIs with many routes and dependencies, but works great in a greenfield scenario.

(Of course, you can rewrite the URL on the fly via Lambda@Edge but that's a PITA to maintain)

> Configuring CORS is probably the biggest pain about this approach and is necessary if you want to send data to and from an API.

CORS is only needed for the API, not the website, and only if you don't control the API or don't make it so the API can be served (from the client's perspective) from the same origin, perhaps because it's fronted by the same Cloudfront distribution.

Just change the Access-Control-Allow-Origin header. Am I missing something?

Access-Control-Allow-Credentials too and it needs to be configured on both the client and the server.

If the API is not yours, why not set up a proxy on your domain (where you can change the origin header)? Envoy, nginx, etc.

What is the challenge setting up CORS on CloudFront?

If you want to do this with one command, check out https://github.com/tobilg/serverless-aws-static-websites or, if you want to host an API with Lambda as well, https://github.com/tobilg/aws-fullstack-website

Netlify (http://netlify.com/) works great for static sites as well!

A problem my team hits with micro projects with this is: virtual routes like `/login` doesn’t map to a file. What can be done about that?

/login makes me think your website isn't really static.

Regardless, you can use extensionless links with your static website if you rename the file from login.html to login, then change the file metadata to Content-Type: 'text/html'

Why would it not be static? It could be a static site making a request to an API to log in?

Like a SPA? You use a something like react router and set the S3 error page to your index. I've deployed many SPAs to AWS S3/ Cloudfront. You have to handle the 404 page in app

Here's a SO post https://stackoverflow.com/questions/51218979/react-router-do...

Most servers will route /login/index.html to /login

You can also use Lambda@Edge with CloudFront to do any kind of logic required, like redirects, rewrites, etc...

You can add an error behaviour in cloudfront that defaults the 404 behaviours to the index page. If you also add the index and error of the S3 config to the same index page it all works perfectly.

We have multiple React sites deployed this way to S3/Cloudfront with react-router and experience no issues.

I just use s3_website. It works well if you have Java installed.

https://github.com/laurilehmijoki/s3_website

Reply on news.ycombinator.com