Final Troubleshooting: Persistent 403 Access Denied on S3 Static Hosting, even after all standard fixes

Based on your thorough troubleshooting, you're right to suspect an account-level restriction since you've already tried the standard fixes. Here are the most likely causes for your persistent 403 Access Denied errors:

1. Service Control Policies (SCPs): If your AWS account is part of an AWS Organization, there might be SCPs in place that restrict S3 public access regardless of your bucket settings. These organization-level policies override individual bucket configurations.

2. Permission Boundaries: If permission boundaries are applied to the IAM roles/users you're using, they could be limiting S3 actions even if your bucket policy allows them.

3. Account-Level Block Public Access Settings: Check if you have account-level S3 Block Public Access settings enabled. These settings override bucket-level settings and can prevent public access even if your bucket policy allows it.

4. S3 Object Ownership Settings: Verify your bucket's Object Ownership settings. If set to "Bucket owner enforced," ACLs are disabled and might affect access.

5. Regional Propagation Delay: After creating an S3 bucket, it can take up to 24 hours for the bucket name to propagate across all AWS regions. Since your bucket is in ap-northeast-1 (Tokyo), this could be causing temporary redirection issues.

6. Object-Level Permissions: Even if your bucket is public, individual objects might have different permissions. Ensure the objects themselves are accessible.

To isolate whether this is truly an account-level issue, you could try:

1. Creating a test CloudFormation stack using a template that sets up a basic S3 static website with CloudFront. If this works while your manual setup doesn't, it suggests a configuration issue rather than an account restriction.

2. Checking for enhanced access denied messages in your S3 console, which might provide more specific information about why access is being denied.

If you've exhausted all these options and still face the issue, contacting AWS Support would be your best next step, as they can check for account-specific restrictions that might not be visible to you. "Account and billing" inquiries are free of charge.
Sources
Persistent 403 Access Denied on S3 Static Hosting, even after all standard fixes | AWS re:Post
Troubleshoot access denied (403 Forbidden) errors in Amazon S3 - Amazon Simple Storage Service
CloudFront returns "AccessDenied" when connecting to S3 static website | AWS re:Post
S3/Cloudfront & OAC: Access denied when accessing path other than index site | AWS re:Post

I can confirm the 403 error occurs even when accessing the root / of the website endpoint, and the index.html file is definitely located in the root of the bucket. Therefore, I believe the issue is not related to incorrect file paths.

I have now enabled S3 server access logging for the bucket as suggested. Could you advise what specific error codes or messages I should look for in the logs that might indicate the reason for the access denial?

Given that both the minimal public S3 configuration and the CloudFront OAC setup result in a 403, I still strongly suspect there might be an account-level restriction overriding the bucket settings.

Any further insights based on this information would be greatly appreciated.

You’ve done an excellent job isolating the issue. The fact that even a fresh public bucket with static hosting enabled returns a 403 means this is not a simple configuration or CloudFront problem. Let’s go through a few deeper checks that often reveal the real cause.

1. Verify You’re Using the Website Endpoint, Not the REST API URL S3 static websites only work from the website endpoint format:

http://<bucket-name>.s3-website-<region>.amazonaws.com

If you try using the REST-style endpoint (https://<bucket-name>.s3.<region>.amazonaws.com), you’ll always get a 403, even for public buckets.

2. Check for Account-Level “Block Public Access” Go to S3 → Account settings → Block Public Access (Account Settings). Even if you’ve disabled it at the bucket level, an account-level block will override that and cause a 403. Make sure all four “Block public access” settings are turned off for testing.

3. Validate Object ACLs and Ownership Controls If Object Ownership is set to Bucket owner enforced, S3 will ignore object ACLs (including public-read). Check with:

aws s3api get-bucket-ownership-controls --bucket <bucket-name>

If it shows BucketOwnerEnforced, remove it:

aws s3api delete-bucket-ownership-controls --bucket <bucket-name>

Then set your file ACL again:

aws s3api put-object-acl --bucket <bucket-name> --key index.html --acl public-read

4. Review Organization SCPs and IAM Boundaries If your account is part of an AWS Organization, there might be an SCP denying public access to S3 or enforcing HTTPS-only conditions:

"Condition": { "Bool": { "aws:SecureTransport": "true" } }

or a deny for "s3:PutBucketPolicy". You can review SCPs in AWS Organizations → Policies → Service Control Policies.

5. Check VPC Endpoint Policies If requests are being routed through a VPC endpoint for S3, ensure its policy allows s3:GetObject for public traffic. A restrictive endpoint policy can override your bucket policy and trigger a 403.

6. Test with Curl and Review CloudTrail Try:

curl -I http://<bucket-name>.s3-website-<region>.amazonaws.com/index.html

Then check CloudTrail for the GetObject event — it often includes a message explaining the AccessDenied reason (for example, “PublicAccessBlock”).

7. Consider Region-Specific Limitations In newer accounts or certain regions, public static website hosting might be restricted by AWS compliance defaults. If everything above checks out, open a support case — AWS can confirm if a regional or account-level control is preventing public hosting.

Reference Docs: Amazon S3 Website Endpoints - https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html Block Public Access Settings - https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html

Since you have managed to setup the S3 bucket and CloudFront distribution and getting a 403 error, I don't think the issue is coming from SCP or any other account level settings. Instead, something is blocking access to objects in your bucket.

With your S3 bucket, are you encrypting the objects using customer managed keys? If so, you need to provide permissions for KMS.

{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
}

Reference: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html