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.
Trailing Slash
Note also that if your site links to its pages using URLs without a trailing slash such as /about, S3 will not serve the index page. Instead, you have to use the path /about/ for S3 to serve /about/index.html. That does not seem to be the case here, since S3 attempted to serve index.html. But thought I would mention it.
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.com instead 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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.