> It lets you do anything, including create, remove, read, update both objects and buckets. You can also change permissions on the buckets using the bucket policies.
So if you don't want that, don't write it? I don't see how AWS forces anyone to make that infrastructure decision in any specific case. And its not default. You have to go out of your way to do that.
> Because they do kind of use the same security process - IAM permissions. And not just DBs and S3 - all of AWS uses IAM in some way or another. But it's all just different enough to make it damned hard to create any kind of standard.
So? The standard is running your own services and using any of the standard networking options. They are handling provisioning and networking so naturally they need an abstraction for security of network clients they are connecting for you.
> Some permissions can be fine tuned, some can not. Some can rely on conditionals, some can not. Some can be overridden at the object level, some can not. Some use roles, some users, some policies.
So? permissions, conditionals, asset policies aren't new or complicated and well within what you'd deal with in any tech stack in existence. Same goes for roles, policies, and users... Do those abstractions really seem that complicated? And in which stack do they not exist?
> Understanding the differences - what works when - is what makes it all so hard to understand. And when it changes, all that knowledge is useless (or worse, dangerously incomplete) again.
Thats fine, but arguably not better than any other service provider. You could also say those things about any software service out there - especially if its intended for consumption by engineers. Documenting APIs isn't a solved problem for anyone.