AWS's shared responsibility model is clear. AWS is responsible for security of the cloud. The customer is responsible for the security in the cloud (i.e. the customer's resources). By the way, enterprise support customers do get access to well-architected reviews by AWS.
If you ask for help from AWS, AWS will provide it. It may not be free, but it's available.
Even if AWS were to start proactively auditing customer setups, how in the world is AWS supposed to know what a customer's usecase is? Nevermind the fact it's a breach of the customer's privacy to just go rooting around in the customer's account without permission.
But let's assume AWS is going to take responsibility for customers' configuration decisions and violate customers' privacy by proactively auditing their accounts. Would AWS auditing Twilio's configuration here work?
The default is for S3 buckets to be private. The customer has to take specific, affirmative steps to give s3 buckets public access. You really have to jump through hoops to make a bucket public accessible.
Since the Twilio chose to make their bucket public, AWS auditing Twilio's setup wouldn't be helpful. AWS would just assume the Twilio knows what they're doing. How is AWS supposed to know there is a misconfiguration? Because Twilio clearly decided to make their S3 bucket publicly available.
Not only do you have to jump through hoops to make it public, if you are worried can't you use Amazon Macie and have a separate org level view that alerts you to any public buckets?
I don't bother because it seems pretty clear what buckets are public.
That said, quick tip to make your life easier.
DON'T use S3 ACL's
DON'T use S3 policies.
If I was AWS and didn't have so many customers I'd probably just create one mental model (IAM policies probably) as the place to manage things and block the rest.
There are big signs on world-accessible buckets when you go into the S3 console. It's a fairly new thing but they are (slowly) trying to help auditing and finding these things I guess.
However I'm not sure if there are any built-in tools to find weird nested policies attached that could cause a similar permission to be granted to all..
What does AWS have to do with this? Sure, the technical debt of S3 being one of the first services is clear to see. But it was a world writable bucket. What is AWS going to do about that? Eventually, you have to know and care about what the hell you are doing.
