Yes it sucks and the documentation sucks even more. I think azure and whatever you call the google cloud configuration site are both so complicated because they're best for giant corporations with thousands of employees and many many roles in the organization with different privileges. However if you're just a single developer setting up something simple it's hellish.
It would be nice if they provided a simple setup configuration option for simple setups.
Quite honestly a single person working at a micro scale is not the target market for the hyperscalers. You're better served not going for managed services (and buying unmanaged services on the big clouds also doesn't make sense without needing the entire ecosystem around it).
Not from my experience. I've worked with all three of them. If one can stick with the web UI to provision permissions and the permissions required are simple/straightforward, Google Cloud (again, this is my personal opinion, so please take it with a grain of salt) is the most usable among the three.
BUT all three of them (AWS, Azure and GCP) have pros and cons, so you just have to spend a good amount of time learning their quirks.
AWS IAM isn't well designed, policy attachments all over the place making it near impossible to figure out what set of permissions you might actually have
As hair-splitting, its IAM can be well designed but the management tooling/observability can be lacking.
In my mind, "not well designed" would be "I cannot represent my security need in this policy language" versus the more common opinion "AWS IAM is a black box" means "I cannot understand why I am getting a 403"
GCP's IAM is, in this premise, not well designed because I cannot express ReadOnlyAccess in their policy language without having a constantly updating policy job, because they do not have wildcards in the Action as does AWS. Contrast `Action: ["s3:Get*"]` which would cheerfully include access to a future GetBucketV7 verb to GCP's "storage.buckets.get" which must always be specified, in full, and when storage2.buckets.get comes out, it's my job to find all references and patch them
There is similar issue with AWS. AWS provides a "ReadOnlyAccess" managed policy that has additional privileges that you probably don't want folks to have (e.g. can read S3 bucket content, not just see bucket names/key names). They recognized this and created a more limited "ViewOnlyAccess" that doesn't have access to content.
There's another common fix, which is to apply a permission boundary to IAM roles. This allows the use of generic policies like "ReadOnlyAccess" but can then be further downscoped to resources by tag (or other similar ABAC schemes)
You should not be using any of their managed policies, but creating your own. Using their own managed policies is a strong misunderstanding of how to use IAM.
(I used to work for AWS and am long Amazon stock. In no way do I speak for Amazon)
With Amazon, you are genuinely the customer. AWS may do many things in a bizarre or byzantine way, but it is constantly trying to be there for the developer in ways that many competitors in my opinion are not.
It is, without any question. Even of you work at a Microsoft shop, the benefits you get from vertical integration isn't that clear. Azure requires a far greater cognitive load to handle and to make matters worse ultimately experiences far more outages.
It would be nice if they provided a simple setup configuration option for simple setups.