Why does AWS recommend against public S3 buckets?

Question

"We highly recommend that you never grant any kind of public access to your S3 bucket."

I have set a very granular public policy (s3:GetObject) for one bucket that I use to host a website. Route53 explicitly supports aliasing a bucket for this purpose. Is this warning just redundant, or am I doing something wrong?

Solution 1

Yes, if you know what you're doing (edit: and everyone else with access to it does, too...), you can ignore this warning.

It exists because even large organizations who should know better have accidentally placed private data into public buckets. Amazon will also send you heads-up emails if you leave buckets public in addition to the in-console warnings.

Accenture, Verizon, Viacom, Illinois voter information and military information has all been found inadvertently left open to everyone online due to IT bods misconfiguring their S3 silos.

If you are absolutely, 100% certain that everything in the bucket should be public and that no one's going to accidentally put private data in it - a static HTML site's a good example - then by all means, leave it public.

Solution 2

The privacy issue featured in ceejayoz's answer is not the only problem.
Reading objects from an S3 bucket has a price. You will be billed by AWS for each download from this bucket. And if you have a lot of traffic (or if someone who wants to hurt your business starts to heavily download files all day long) it will quickly become expensive.

If you want files from your bucket to be publicly accessible, you should create a Cloudfront Distribution that points to and is granted access to the S3 bucket.

Now, you can use the Cloudfront Distribution's domain name to serve your files without granting any S3 access to the public.
In this configuration, you pay for Cloudfront's data usage instead of S3's. And at higher volumes it's a lot cheaper.

Comments

[Admin]

@MichaelHampton It will show this in the S3 console, without much additional context. businessinsights.bitdefender.com/…

[Admin]

Related - can AWS see into a private bucket or does it have to be public for AWS to access files inside?

[Admin]

@Criggie AWS being their support team? Or something else?

[Admin]

@ceejayoz yes the AWS support team.

[Admin]

I'd imagine at a certain level of support they might poke around inside, although S3 supports encryption with a non-Amazon key. Their processes should ensure it's not done without explicit permission, I'd think.

[Shadur]

In practice, you're virtually never 100% certain, so best practice is to don't.

[Reactgular]

It was just a few months ago where either the FBI or CIA left private data that was supposed to be secure on a public S3. I'll see if I can find a link to the news article.

[Reactgular]

See here: gizmodo.com/…

[chrylis -cautiouslyoptimistic-]

CloudFlare also works, and is likely to be cheaper still.

[bad_keypoints]

Good sire, can you guide me how to specifically allow only my website and Android app to be able to access my bucket's objects? Basically I don't want people scraping my bucket contents. But my website and app should be able to load them.

[machineghost]

@bad_keypoints what you describe is (basically) impossible in S3. There is no way your website can tell the difference between someone scraping and a regular visitor. Technically you could write server-side logic to look at how much your user is consuming, and stop them at a certain point ... but such logic would be a PITA, and you'd have to use a real host (eg. EC2 instead of S3) if you wanted to. In short, if to worry about scrapers you need a far more advanced back-end (and it won't be a 10)% solution)... or you can just not worry.

[Bruno Reis]

"you pay for Cloudfront's data usage instead of S3's. And at higher volumes it's a lot cheaper." -- HUGE caveat here is that the request pricing on CloudFront is considerably more expensive than S3's, so the attacker could just send ton of requests (and even cancel them, to not have to actually receive the data and not need a lot of bandwidth themselves).