Getting 403 (Forbidden) error when accessing static site from custom domain

1
votes

I'm setting up a static site on S3 and Cloudfront. I've setup SSL, etc. on Cloudfront and I can access the site using the *.cloudfront.net URL. However, when accessing from the custom domain, I get the 403 error. Does anyone know why? The bucket policy is as follows:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "2",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXXXXXX"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.mydomain.com/*"
        }
    ]
}

This should permit access from the custom domain mydomain.com, right?

For the sake of testing, I've tried setting "Principal": "*", but it still gives 403.

Any help appreciated.

3
amazon-web-servicesamazon-s3amazon-cloudfront
is www.mydomain.com the bucket name? Also bucket must not be in a website mode. Also, what endpoint did you use in CF disto setting for the bucket. It can't be website endpoint. – Marcin
What is your DNS setup here? Are you pointing your custom domain directly to S3 rather than via CloudFront? It might be that you have a default resource (e.g. index.html) setup on CloudFront that is not configured on S3. Try putting the full resource path into the address when using your custom domain. – F_SO_K
@Marcin All good now. Alternate Domain Names somehow couldn't be updated. I've had to create a new distribution. – John M.
@F_SO_K All good now. I've had to create a new distribution with the right CNAMEs. – John M.
Cool. Thanks for letting me know. – Marcin

3 Answers

0
votes

The issue is looks like caused by "Object is not publicly available for read".

By default S3 Buckets are set to "block all public access." So you need to check if it's disabled. enter image description here

And then You can configure your objects to be publicly available which can be done in 2 ways:

  1. Bucket Level Restriction via Policy
  2. Object Level Restriction (in case you have a use case that requires granular control)

Lastly if you have scripts that uploads those contents you can also utilize this scripts to append restriction policy on demand.

aws s3 cp /path/to/file s3://sample_bucket --acl public-read
0
votes

I've fixed it now. I've mistakenly left 'Alternate Domain Names' blank.

0
votes

I know this is an older question, but I figured I'd add on for future searchers: make sure that (as of mid-2021) your Cloudfront origins are configured to hit example.com.s3-website-us-east-1.amazonaws.com instead of example.com.s3.amazonaws.com once you set your S3 bucket up for static website hosting - I got tripped up because (again, as of mid-2021) the Cloudfront UI suggests the latter, incorrect S3 URLs as dropdown autocompletes and they're close enough that you might not figure out what's the subtle difference if you're trying to go from memory instead of following the docs.