- Newest
- Most votes
- Most comments
I suggest you first try setting the bucket ownership control to BucketOwnerEnforced to disable ACLs for the bucket. Otherwise, it depends on the ownership and per-object ACLs of each object, which can vary, whether the bucket policy you've configured can permit access to objects. To be clear, this isn't necessarily your problem, but it does add complexity that happens at a per-object level and can only be guessed based on the declared configuration.
Another thing to check is that the bucket is not enabled for static website hosting. It isn't present in your configuration declaration but would prevent OAC from working if it's been enabled for the bucket outside the declared configuration you included.
My issue was.. as part of my migration from OAI to AOC i changed the type of s3 bucket. S3 wasn't anymore a Hosting static website s3 bucket, so it lost the ability to serve the index.html by default for the sub paths.
in order to fix this I have added a cloudfront function
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html.
Thanks to Leo.K for anyway trying really to troubleshoot the issue.
answered 2 years ago
Okay, so the reason you were getting error messages was simply that you were requesting nonexistent objects. When requesting a URL such as
https://example.com/folder/from S3 through CloudFront without custom edge functions or a path prefix defined, the object key requested from S3 will befolder/and notfolder/index.html, which I take it you were expecting and are now appending with the custom CloudFront function.Yes that's correct! I wasn't aware this function was required. In fact with the S3 bucket setting I had before migrating to AOC (the S3 was a hosting website type) it wasn't necessary !
When using OAI, you grant CloudFront access to your S3 bucket by associating the CloudFront distribution with an OAI. Then, the S3 bucket policy is configured to allow this OAI to retrieve objects. This method allows your S3 bucket to remain private while still serving content through CloudFront.
This is an old approach on access. More recent improvements knocked at the OAC. OAC allows CloudFront to sign requests to your S3 bucket, just like OAI, but with added security features and flexibility. It’s designed to allow CloudFront to access private S3 content without making the bucket public, and it provides more secure ways to manage requests and data encryption.
Hope this helps.
Hi Giovanni, thank you for the general explanation. Altho this is sharing useful concepts it is not really helping me to solve the issue. Hope you can suggest me something more practical to fix it. Thanks
Relevant content
asked 2 years ago
asked 2 years ago

Thanks Leo, regarding the problem is there anything you can help with? happy to share more if you need
I suggest you change
object_ownership = "BucketOwnerPreferred"in your code toobject_ownership = "BucketOwnerEnforced"and verify that static website hosting option shown on the properties tab of your bucket in the AWS console is disabled.About the bucket webstatic hosting, are you refering to this?
resource "aws_s3_bucket_website_configuration" "BUCKET_NAME_website_config" { bucket = aws_s3_bucket.BUCKET_NAME_bucket.id
index_document { suffix = "index.html" }
error_document { key = "404.html" } }
Also as mentioned in the question, the
/path works. So if the problem was one of those I should not work at all, no?EDIT: Ok I will check those
I have done what you suggested @leo, the issue is still there, did not solve it.
I removed
resource "aws_s3_bucket_website_configuration" "BUCKET_NAME_website_config" {
and changed ownership to BucketOwnerEnforced
Yes, you have to remove the
aws_s3_bucket_website_configurationelement entirely from your configuration. You won't have any need for it when using CloudFront to publish the site, but more importantly, it won't work together with OAC. You have to disable static website hosting for the S3 bucket.