Teams should consider many qualities when choosing a cloud provider like AWS, GCP (Google Cloud Platform) or Microsoft Azure. Product offerings, familiarity, pricing, and usability – among others.

Compared to AWS, Google Cloud Platform (GCP) is more usable for developers due to it’s core design approach surrounding resources, projects, APIs and Identities (IAM). This project-first approach avoids common bad practices like spaghetti namespaces, excessive permissions, and accidental exposure. Moreover, GCP includes much more advanced logging & alerting tools, comparable to Splunk and Data Dog, right out of the box.

AWS’s model for resources is Organization > Account > Region > Resource. GCP’s design is Organization > Project > Region > Resource . GCP’s project-first model encourages better resource isolation, by namespacing projects separately, and encouraging the separation of test & internal projects from production projects. This is preferred for newcomers and advanced users alike.

Another subtle design constraint on GCP is the POLP model for API enablement at the project level. On Google, when a project is started, only a bare minimum access to APIs is made available. Every new service used within a project requires the API to be activated deliberately. For example, the first use of Google Cloud Build activates the API. Disabling an API deletes all of the API’s resources within a project. This reduces the attack and bug surface area by minimizing the number of exposed APIs & services to a project.

Identity (IAM) is also project-scoped, which may be the strongest benefit of all. By combinging project-scoped API & Identity managent, permission breaches (either excessive grants or breached keys) are scoped to the immediate project. It’s very common for developers to grant expansive permissions scopes to resolve active issues, so this design naturally reduces the potential fallout.

IAM management on GCP is quite a lot more intuitive out of the box. Google’s generous set of templated roles with type-ahead UI’s, and permissions debugging tools are much more intuitive for product & systems developers who are not experts at devops / systems administration. Though AWS has caught up quite a bit with pre-defined roles, AWS’s approach favors complicated IAM syntax , which keeps their training programs well attended. GCP also encourages the use of service identities across all resource types, to reduce key breaches and excessive permissions.

Another huge GCP advantage is within logging, monitoring & alerting (the Logs Explorer, Metrics Explorer, Log Analytics Products). Nearly every service is activated with GCP Cloud Logging out of the box, which has the best query, metric definition and alerting interfaces available from the big cloud providers. The query UI has a sql-like syntax, and the log stream can be cloned to BigQuery for full SQL support. Log patterns can be upgraded to metrics, like counting web access logs into a web-hit-rate metric. Log patterns and log-metrics can both be used to trigger alerts. This level of service competes directly with expensive log frameworks like Splunk and Data Dog – yet GCP offers it at minimal cost with every service.

Last but not least, are expansive client SDK integrations. Whereas AWS leans on rest-API and third party SDKs, GCP’s client SDKs are more broad and consistent across their APIs.

GCP’s biggest weakness, like most Google Products, is really terrible marketing. I hope with better awareness, more developers will discover & appreciate the great benefits of GCP like resource & IAM management, advanced logging & alerting, and better API management, among other great advantages.