Deploying front-end websites to S3 with CloudFront

https://ilhicas.com/2020/02/15/Serving-Javascript-S3.html

by ilhicas • 6 years ago

57 29 6 years ago

snazz2• 6 years ago

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.

guu• 6 years ago

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

judge2020• 6 years ago

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

snazz2• 6 years ago

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

wefarrell3• 6 years ago

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.

irjoe• 6 years ago

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.

wefarrell3• 6 years ago

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

hkchad• 6 years ago

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

saidmasoud• 6 years ago

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)

dragonwriter• 6 years ago

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.

zelly2• 6 years ago

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

wefarrell3• 6 years ago

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

avip• 6 years ago

What is the challenge setting up CORS on CloudFront?

cordite• 6 years ago

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?

maest• 6 years ago

/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'

procinct• 6 years ago

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

tfolbrecht• 6 years ago

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...

danielstocks• 6 years ago

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

kesor• 6 years ago

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

bett35132• 6 years ago

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.

bunsenhoneydew• 6 years ago

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.

cyberferret2• 6 years ago

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.

viklove• 6 years ago

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`.

cyberferret2• 6 years ago

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.

bett35132• 6 years ago

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

throw03172019• 6 years ago

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

https://github.com/laurilehmijoki/s3_website

veeralpatel979• 6 years ago

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

tobilg• 6 years ago

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

Deploying front-end websites to S3 with CloudFront

Related Stories