[zbjornson]

I feel the opposite. Everything I've used in GCP, I've understood and appreciated the design decisions behind. Most things I've used in AWS, I've wondered why they shipped it that way. Examples:

* High-availability HSM KMS: trivial in GCP, super difficult in AWS.

* Object storage (GCS/S3): multi-region is trivial in GCP, somewhat harder in AWS. Archival is so much simpler in GCS than S3 Glacier.

* IAM: makes sense to me in GCP and is consistent across products, AWS policy editor has poor usability and feels inconsistent between products.

* Having per-region pages in the AWS console is a pain, easy to lose stuff. GCP is one global interface.

* Cloud functions/Lambda: CF Just Work with native dependencies. Lambda is painful in that regard.

GCP's auth lib is confusing though, I agree with you there. We stopped using it and all of their client libs a few years ago and wrote our own. However, that they force you to use service accounts is an excellent security decision.

[more_corn]

How about: Security groups Creating load balancers Creating and managing access to cloudsql vs rds Gcp internal request limits Gcp documentation is not task oriented. (How do I “X”) Getting effective support is impossible.

That looks like at least six important things that are significantly harder on GCP.

Don’t get me wrong, I like GCP. I just hate that they are failing in ways I think are so clear and simple to fix if they’d change their thinking. Oh also, critical components being alpha/beta and unsupported, but no alternative existing. (I’m think of the kubernetes monitoring thing who’s name I forget)

One thing I HAVE liked is cloudshell, being able to spawn an authenticated shell into any resource without having to figure out access from my location.

[hopefullywrong]

iam authenticated access to a cloudsql instance is exactly what I’m trying to do right now… and it’s not surprising why people give up and hard code credentials…