AWS buckets and regions

0 votes

The application is using carrierwave in conjunction with the carrierwave-aws gem. It hit snags when migrating rails versions (bumped up to 4.2), ruby versions (2.2.3) and redeployed to the same staging server.

The AWS bucket was initially created in the free tier, thus Oregon, us-west-2. However, I have found that all the S3 files have the property which links to eu-west-1. Admittedly I've been tinkering around and considered using the eu-west-1 region. However I do not recall making any config changes - not even sure it is allowed in the free tier...

So yes, I've had to configure my uploads initializer with:

config.asset_host = 'https://s3-eu-west-1.amazonaws.com/theapp' config.aws_credentials = { region: 'eu-west-1' }

Now the console for AWS is accessible with a URL that includes region=us-west-2

I do not understand how this got to be and am looking for suggestions.

Jul 30, 2018 in AWS by bug_seeker
• 15,350 points
33 views

1 answer to this question.

0 votes

In spite of appearances, and AWS account doesn't have a "home" (native) region.

The console defaults to us-west-2 (Oregon), and conventional wisdom suggests that this is a region where AWS has the most available/spare resources, lower operational costs, lower pricing for customers, and fewest constraints for growth, so that in the event a user does not have enough information at hand to actively select a region where they deploy services, Oregon will be used by default.

But for each account, no particular region has any special standing. If you switch regions in the console, the console will tend to open up to the same region next time.

Most AWS services -- EC2, SQS, SNS, RDS (to name a few) are strictly regional: the regions are independent and not connected together¹, in the interest of reliability and survivability. When you're in a given region in the console, you can only see EC2 resources in that region, SQS queues in that region, SNS topics in that region, etc. To see your resources in other regions, you switch regions in the console.

When making API requests to these services, you're using an endpoint in the region and your credentials also include the region.

Other services are global, with centralized administration -- examples here are CloudFront, IAM, and Route 53 hosted zones. When you make requests to these services, you always use the region "us-east-1" because that's the home location of those services' central, global administration. These tend to be services were a partitioning event (where one part of the global network is isolated from another). Administrative changes are replicated out around the world, but after the provisioning is replicated, the regional installations can operate autonomously without major service impacts. When you select these services in the console, you'll note that the region changes to "Global."

S3 is a hybrid that is different from essentially all of the others. When you select S3 in the console, you'll notice that the console region also changes to show "Global" and you can see all of your buckets, like other global services. S3 has independently operating regions, but a global namespace. The regions are logically connected and can communicate administrative messages among themselves and can transfer data across regions (but only when you do this deliberately -- otherwise, data remains in the region where you stored it).

Unlike the other global services, S3 does not have a single global endpoint that can handle every possible request.

Each time you create a bucket, you choose the region where you want to bucket to live. Subsequent requests related to that bucket have to be submitted to the bucket's region, and must have authorization credentials for the correct region.

If you submit a request to another S3 region's endpoint for that bucket, you'll receive an error telling you the correct region for the bucket.

< HTTP/1.1 301 Moved Permanently

< x-amz-bucket-region: us-east-1

< Server: AmazonS3

<Error>

<Code>

PermanentRedirect

</Code>

<Message>

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

</Message>

<Bucket>...</Bucket>

<Endpoint>

S3.amazonaws.com

</Endpoint>

<RequestId>...</RequestId>

<HostId>...</HostId>

</Error>

answered Jul 30, 2018 by Priyaj
• 56,920 points

Related Questions In AWS

+1 vote
3 answers

Log in to AWS using Access Key ID and Secret Access Key ID

Access keys consist of an access key ...READ MORE

answered Aug 17, 2018 in AWS by Priyaj
• 56,920 points
1,183 views
0 votes
1 answer
0 votes
1 answer
0 votes
1 answer
0 votes
1 answer
0 votes
2 answers

Receiving SMS from users and stores in AWS

As far as I know, receiving international ...READ MORE

answered Aug 21, 2018 in AWS by Priyaj
• 56,920 points
90 views
+1 vote
2 answers

Starting with an AWS Instance with API and AUTHPARAMS

The API is usually much easier to ...READ MORE

answered Apr 17, 2018 in AWS by Cloud gunner
• 4,280 points
486 views