Deploying front-end websites to S3 with CloudFront(ilhicas.com)
ilhicas.com
Deploying front-end websites to S3 with CloudFront
https://ilhicas.com/2020/02/15/Serving-Javascript-S3.html
32 comments
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
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.
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.
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.
Yes, https://netlify.com is great for this too and supports most static site generators.
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.
> 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.
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.
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.
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)
(Of course, you can rewrite the URL on the fly via Lambda@Edge but that's a PITA to maintain)
Here's a writeup on the details. https://medium.com/@chad.h.dalton/how-we-reduced-our-api-cal...
Wasn't aware of this, will definitely try it next time around. Thanks!
Just change the Access-Control-Allow-Origin header. Am I missing something?
What is the challenge setting up CORS on CloudFront?
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?
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...
Here's a SO post https://stackoverflow.com/questions/51218979/react-router-do...
/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'
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?
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.
We have multiple React sites deployed this way to S3/Cloudfront with react-router and experience no issues.
You can also use Lambda@Edge with CloudFront to do any kind of logic required, like redirects, rewrites, etc...
Most servers will route /login/index.html to /login
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.
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.
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.
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.
[deleted]
AWS Amplify is the service that works as you’ve described.
I just use s3_website. It works well if you have Java installed.
https://github.com/laurilehmijoki/s3_website
https://github.com/laurilehmijoki/s3_website
Netlify (http://netlify.com/) works great for static sites as well!