A few months ago, during my Flatiron days, I decided to create a guide to deploying your app to Heroku: https://dev.to/sofiajonsson/deploying-your-app-to-heroku-ob6 Heroku is a great free platform, but what you're not paying for is a quick and responsive website.
I'm in the process of uploading my portfolio site through Amazon Web Services (AWS) using S3 and route 53 and have run into an issue getting my static endpoint to display the uploaded application. I have spent hours browsing blog posts and StackOverflow and there's something I'm not understanding.
Instead of seeing my site I get a 404 NoSuchKey error:
The YouTube tutorial I've been following suggests setting my endpoint to index.html, but that's not working and I'm assuming it's because the file is nested within one of my other React.js files? I also tried with index.js as that would make more sense, but ran into the same issue. When I tried to provide a direct location such as "src/index.js"or "public/index.html" I would get the following error:
From what I've gathered, AWS is great for hosting static sites and suggests using vanilla JS, so could that be the problem?
I'm curious to hear about your experiences uploading to AWS using S3 and route 53 and any tips or tricks you might have. I'm going to keep working on this and hopefully follow up with an outlined post in case anyone else runs into this issue.
Oldest comments (3)
I use S3 for a personal vue project and my portfolio site. My vue app was having a similar issue and changing both the index document and the error document on the s3 bucket to index.html fixed it.
The error seems to indicate that the index file is not present. I'm sure you've checked, but just in case: did you setup the bucket as a "website" bucket? Are the files present in the bucket and publicly readable (but not writable)? I assume you did a drag-n-drop through the AWS Console. For routine deployments, you may want to look at the AWS CLI. We run
aws s3 sync ...to copy our static assets up. As part of those commands we also set caching headers so that browsers will actually see new versions of the front-end app when we upload them.After that, we put a AWS CloudFront distribution (aka a CDN) in front of S3. However, CloudFront may not serve index.html from sub-folders by default -- it will only serve it for the root of the site. That's the behavior if you just select the S3 bucket as your origin. You have to instead paste your bucket URL into the origin field. Then it will treat the S3 bucket as though it is just a web server. And it will properly serve index.html out of subfolders as well as the root. In this way we can use a single bucket to serve different front-end apps.
Then we setup a Route 53 ALIAS DNS record to point to the CloudFront distribution, so people can go to
mydomain.cominstead of the CF distro's default URL. (ALIAS is a non-standard, AWS-specific DNS type that you have to use when pointing to other AWS services. Since services are provisioned/dynamic, they don't have a stable IP, so this is AWS's solution to that problem.)Then we use Certificate Manager to create a SSL (or rather TLS) cert for the domain. When it is already hosted in Route 53, it will offer to setup the domain verification DNS entries for you. Once the cert is verified (takes a few minutes), you can instruct CloudFront to use it. So your site supports encrypted browsing.
Those are all the traps I can think of that we fell into when hosting the static assets for our front-end apps.
I'm sure this isn't the point of the exercise, but I found netlify to be easier even than heroku for front-end stuff, and the free tier is plenty fast. Sorry for the non-answer.