aws-sdk-go: GetBucketLocation fails if region specified does not match the region the bucket is in.

Hi @matthew-andrews The S3 team got back with me and suggested the best API to use is HEAD bucket. GetBucketLocation uses a more complex permissions model where HeadBucket can be called by anyone. The bucket’s region will be returned as a X-Amz-Bucket-Region header.

The HEAD bucket request can be made regardless of request signing, so anonymous (unsigned) requests can be made requesting a bucket’s region.

I’m going to close this issue with this info. Please let us know if you have additional feedback, or issues.

After some discussion with AWS support I found out that the issue I was having with this behavior is the previously recommended solutions do NOT work when you are making cross account requests to HeadBucket and GetBucketLocation. A simple http HEAD does work and requires no credentials or cross account access in all cases for me. Here is my sample go code that I am now using:

func getBucketRegion(bucket string) (string, error) {
	url := fmt.Sprintf("https://%s.s3.amazonaws.com", bucket)
	res, err := http.Head(url)
	if err != nil {
		return "", err
	}
	return res.Header.Get("X-Amz-Bucket-Region"), nil
}

I’m not sure this issue should be closed. I can reproduce this still. If I have to set region to match the bucket location, what is the point of this API call at all? You can access the region from Config, and it must be set: https://docs.aws.amazon.com/sdk-for-go/api/aws/#Config. At this point the only useful purpose to the API call would be to check if the bucket is in the current region and iterate all regions creating a new Session for each region until you found the right one. Hopefully I’m missing something obvious, but for now I’m heading towards the HEAD workaround.

I’m not sure this issue should be closed. I can reproduce this still. If I have to set region to match the bucket location, what is the point of this API call at all? You can access the region from Config, and it must be set: https://docs.aws.amazon.com/sdk-for-go/api/aws/#Config. At this point the only useful purpose to the API call would be to check if the bucket is in the current region and iterate all regions creating a new Session for each region until you found the right one. Hopefully I’m missing something obvious, but for now I’m heading towards the HEAD workaround.

I agree, this should not have been closed. I have reproduced the problem just today when using this dependency:

	<dependency>
		<groupId>com.amazonaws</groupId>
		<artifactId>aws-java-sdk</artifactId>
		<version>1.11.747</version>
	</dependency>

Note: The suggested workaround above to use HeadBucket did not work for me using the Java API. It returned a 400 Bad Request when making the call on a bucket in a region different than the region used to create the AmazonS3 client.

A workaround which does work is to connect to each region in turn to determine which connection allows getBucketLocation to return without throwing an exception. The region which does not throw the exception is the region of the bucket. Pretty poor workaround but it does the job.

Hi @matthew-andrews We’s escalated this issue to the S3 Service team, and they are currently investigating. We’ll update once we have more information.

Hello @matthew-andrews, I’ve reached out to s3 to further investigate this issue. Please let us know if there is anything else we can do for you.