AWS and Google Cloud: How the Two Models Differ
Both run enormous infrastructure. They differ in how accounts are structured, how permissions are expressed and how the catalogue is organised.
Comparisons between these two usually collapse into a verdict, which is not useful because both run vast, capable platforms. The differences that matter in daily work are structural.
The organising unit
In AWS the account is the boundary. Resources belong to an account, permissions are written within it, and separation between environments is usually achieved by using more accounts under an organisation.
In Google Cloud the project is the boundary, and projects sit under an organisation with folders. Creating a project is lightweight, so separation tends to happen at project level.
The practical consequence: an AWS engineer separating production from staging reaches for another account; a Google Cloud engineer reaches for another project. Google’s lighter unit makes fine-grained separation cheaper.
Billing attachment
Google Cloud’s billing account is a separate object that attaches to projects and can be detached. AWS keeps billing closer to the account itself, with organisations providing consolidated payment.
This is why a Google Cloud project can exist but be unable to run chargeable resources: the billing link is missing. That specific failure has no direct AWS equivalent.
Permissions
AWS IAM policies are JSON documents attached to users, groups and roles, expressed as allow and deny statements over actions and resources. They are extremely expressive and correspondingly detailed.
Google Cloud binds predefined or custom roles to principals at a point in the hierarchy, and those bindings inherit downwards. Granting at the folder level flows to everything beneath.
Neither is simpler overall. AWS gives finer control per statement; Google Cloud gives clearer inheritance.
Catalogue shape
AWS has the broader catalogue and typically the longer track record for a given service category. Google Cloud’s catalogue is smaller but strongly regarded in data analytics and machine learning, and its networking is frequently praised.
For ordinary compute, storage and networking, both are entirely capable and the decision rarely turns on capability.
What usually decides it in practice
- Existing team experience, which is worth more than any feature comparison.
- Specific managed services one platform does better for your workload.
- Region coverage where your users are.
- Available credit, which affects the first months rather than the long term.
Account options
Catalogue configurations reflect these differences. AWS listings distinguish vCPU capacity, credit balances and service readiness separately, as explained in reading AWS configurations. Google Cloud listings centre on credit tiers and upgrade status, reflecting a billing model where those are the meaningful variables.
Deeper background is in AWS account anatomy and Google Cloud accounts.
Side by side configurations and current prices for both providers are on the AWS vs Google Cloud page in the Cloud Matrix.
Cloud accounts on OldCloudShop
Ten providers, every configuration and the starting price for each.
Continue in the library
Other entries covering account structure, billing, security and provider infrastructure.