You can also expect users to audit what they do with S3, which is something they should already be doing, and that does not force anyone to suddenly refactor their whole deployment workflow.
It makes absolutely no sense at all to argue that public access to S3 should be shut off and those who use it should start paying for CloudFront just because you feel that its too hard to check if your bucket is set to grant public access.
Also, there's already AWS Config for those who feel they need guardrails to enforce a specific configuration. AWS Config even let's you put together a Lambda to switch off public access to a bucket if some sloppy fingers indavertentlh set it on.
It boggles the mind how anyone could suggest with a straight face that your personal usecases should be automated away even though it screws over everyone else using it.
> It boggles the mind how anyone could suggest with a straight face that your personal usecases should be automated away even though it screws over everyone else using it.
Should the orgs that have exposed private data in S3 to the public internet have been using AWS Config and AWS CloudTrail and properly scoped IAM roles and eaten their broccoli and flossed their teeth every night? Yes, they should have. But they did not.
These problems continue to happen, even as AWS adds even more warning boxes that say "Do you really want to open this bucket/object to the public internet? Type 'SHOOT ME' to continue..."
In the grand scheme of things, I imagine that those data exfiltrations from corporate and government customers is a larger net negative for S3 than the positive of the fact that I can wire up my JAM stack static site to an S3 bucket and pay $0.0001 per month to host it on the public internet (rather than paying $0.0002 per month for S3 + CloudFront or S3 + Lambda).
In any case, I'm not the AWS general manager of S3, so there's no need to worry about my comments on this website affecting anyone's use of S3 :)
I fail to see how anyone could think that an intelligent answer to that issue would be "let's prevent everyone from serving static content from S3, specially those serving their sites exactly like it's advertised in the S3 how to guides", specially considering that solutions like AWS Config were simply ignored.
> These problems continue to happen
I want to continue to serve my sites from S3.
How is that my problem? Why should anyone else's oversight or even outright incompetence should stop me from using things right?
> In the grand scheme of things, I imagine that those data exfiltrations from corporate and government customers is a larger net negative for S3 (...)
Not my problem, and not S3's problem. Why are you pretending it is?
AWS is very clear in their shared responsibilities model. You, as the customer, need to have your shit together. If you do not, that's your problem. Not AWS's, and specially not mine.
Read the manual. Learn from your mistakes. Don't drag everyone else down just because you failed to read the freaking intro tutorials. And own up to your mistakes.
That's quite the rebuttal to an argument I didn't make.
I was neither supporting nor opposing the idea of disabling the ability to use S3 publicly. While I agree with the new default I would not support removal of the feature.
Have you seen what you have to do to make a bucket public nowadays? It's not as if you do it by accident (there's a couple of warnings etc)
Yes, buckets created with the API dont have public access blocked, so if someone that does not fully grasp cloud security is given access to create buckets ...
Luckily this is now fixed with the latest round of changes done by AWS.
most of the time it doesn't. Their free tier is very generous.
You get the first 2TB of traffic for free (vs 100GB of free traffic if you use only S3). traffic above this is also cheaper than the price you pay for traffic directly from S3
