Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

URL for public Amazon S3 bucket

I have an Amazon S3 bucket that I make public with a policy like this

{     "Version": "2012-10-17",     "Statement": [         {             "Sid": "Allow Public Access to All Objects",             "Effect": "Allow",             "Principal": "*",             "Action": "s3:GetObject",             "Resource": "arn:aws:s3:::bucket/*"         }     ] } 

My bucket is now visible as http://bucket.s3-website-us-east-1.amazonaws.com/

I see others refer to their bucket as http://s3-us-east-1.amazonaws.com/bucket/

I would prefer the 2nd URL, but it gives an Access Denied.

How can I change my policy to allow the 2nd URL ?

like image 395
Gene Vincent Avatar asked Oct 28 '14 09:10

Gene Vincent


People also ask

How do I find my public S3 bucket URL?

Get an S3 Object's URL #Navigate to the AWS S3 console and click on your bucket's name. Use the search input to find the object if necessary. Click on the checkbox next to the object's name. Click on the Copy URL button.

What is public S3 URL?

An S3 bucket can be accessed through its URL. The URL format of a bucket is either of two options: http://s3.amazonaws.com/[bucket_name]/ http://[bucket_name].s3.amazonaws.com/ So, if someone wants to test the openness of a bucket, all they have to do is hit the bucket's URL from a web browser.

How do I access a public S3 bucket?

To allow public read access to an S3 bucket: Open the AWS S3 console and click on the bucket's name. Click on the Permissions tab. Find the Block public access (bucket settings) section, click on the Edit button, uncheck the checkboxes and click on Save changes.

What is base URL of S3 bucket?

By default, the base URL is set to s3.amazonaws.com.


1 Answers

The URL structure you're referring to is called the REST endpoint, as opposed to the Web Site Endpoint.


Note: Since this answer was originally written, S3 has rolled out dualstack support on REST endpoints, using new hostnames, while leaving the existing hostnames in place. This is now integrated into the information provided, below.


If your bucket is really in the us-east-1 region of AWS -- which the S3 documentation formerly referred to as the "US Standard" region, but was subsequently officially renamed to the "U.S. East (N. Virginia) Region" -- then http://s3-us-east-1.amazonaws.com/bucket/ is not the correct form for that endpoint, even though it looks like it should be. The correct format for that region is either http://s3.amazonaws.com/bucket/ or http://s3-external-1.amazonaws.com/bucket/

The format you're using is applicable to all the other S3 regions, but not US Standard US East (N. Virginia) [us-east-1].

S3 now also has dual-stack endpoint hostnames for the REST endpoints, and unlike the original endpoint hostnames, the names of these have a consistent format across regions, for example s3.dualstack.us-east-1.amazonaws.com. These endpoints support both IPv4 and IPv6 connectivity and DNS resolution, but are otherwise functionally equivalent to the existing REST endpoints.

If your permissions and configuration are set up such that the web site endpoint works, then the REST endpoint should work, too.

However... the two endpoints do not offer the same functionality.

Roughly speaking, the REST endpoint is better-suited for machine access and the web site endpoint is better suited for human access, since the web site endpoint offers friendly error messages, index documents, and redirects, while the REST endpoint doesn't. On the other hand, the REST endpoint offers HTTPS and support for signed URLs, while the web site endpoint doesn't.

Choose the correct type of endpoint (REST or web site) for your application:

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff


¹ s3-external-1.amazonaws.com has been referred to as the "Northern Virginia endpoint," in contrast to the "Global endpoint" s3.amazonaws.com. It was unofficially possible to get read-after-write consistency on new objects in this region if the "s3-external-1" hostname was used, because this would send you to a subset of possible physical endpoints that could provide that functionality. This behavior is now officially supported on this endpoint, so this is probably the better choice in many applications. Previously, s3-external-2 had been referred to as the "Pacific Northwest endpoint" for US-Standard, though it is now a CNAME in DNS for s3-external-1 so s3-external-2 appears to have no purpose except backwards-compatibility.

like image 191
Michael - sqlbot Avatar answered Oct 05 '22 07:10

Michael - sqlbot