0
votes

I've been using node s3-cli library for a while to upload files into my S3 buckets. This worked for example:

s3-cli sync --delete-removed dist s3://domain-admin-dev

But when I run this

s3-cli sync --delete-removed dist s3://sudomain.domain.com

it returns this error:

Error: The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.

What should I do?

Note: I found some posts on the web talking about the S3 bucket not belonging to the right region, however the s3://sudomain.domain.com belongs to the same region as the s3://domain-admin-dev one. So it doesn't make sense for that to be the problem.

1
When I ran into this, the raw error response did contain the endpoint I needed. (If s3-cli doesn't show it to you, you may be able to see it by pointing your browser at the "wrong" location if subdomain.domain.com is a CNAME for some generic S3 domain, or by using another client.) Some S3/AWS clients accept an option like --endpoint to force requests to a certain endpoint.twotwotwo
"it doesn't make sense for that to be the problem" Actually, it makes perfect sense. https://bucket-name.s3.amazonaws.com is always routed by DNS to the correct region for that bucket. S3 provisions this automatically. https://bucket.with.dots.s3.amazonaws.com doesn't work because of how wildcard SSL certificates work, so if this utility reverts to the alternate form, https://s3.amazonaws.com/bucket.with.dots/ you will go to the wrong region unless the bucket is in us-east-1. Buckets with dots have to be addressed as https://s3.{aws-region}.amazonaws.com/bucket.with.dots/.Michael - sqlbot
@Michael-sqlbot your suggestion didn't work.. see answerabbood

1 Answers

2
votes

It turns out that this whole approach was wrong. I simply had to add a cloud front distribution (ie a CDN) and then link it's origin to the s3 bucket (the name of which I changed back from s3://sudomain.domain.com to s3://domain-admin-dev, thus making my cli command work just fine). I then created a CNAME record in my godaddy pointing the subdomain to the cloud front Origin.

The process is depicted here:

enter image description here

note: since cloud front is a cdn, the cache must be invalidated everytime it's updated.