AWS vs Google Cloud: catalogue depth against a cleaner pricing model

AWS and Azure have converged. AWS and Google Cloud have not, and the differences are structural rather than cosmetic. Three of them matter enough to change an architecture.

Billing behaves differently

AWS discounts require a decision. You buy a savings plan or a reserved instance, you commit for one or three years, and the discount follows. Do nothing and you pay list.

Google Cloud applies sustained use discounts automatically on eligible machine families as usage accumulates through the month. Do nothing and you still pay less than list for anything that runs continuously. Add per second billing after a one minute minimum, and short lived workloads are cheaper again.

The practical consequence: for a team that has not done any cost optimisation work, Google Cloud tends to be cheaper. For a team that has committed properly on AWS, the gap closes and can reverse. Compare your actual usage pattern, not the rate cards. The mechanics are in Google Cloud pricing explained.

Networking is designed differently

An AWS VPC belongs to one region. Spanning regions means creating several and connecting them with peering or Transit Gateway, which is a real piece of work with real cost.

A Google Cloud VPC is a global object with regional subnets. Instances in different regions share a network without any peering step, and the global load balancer sits behind a single anycast address rather than a per region endpoint.

If your application is genuinely multi region, this is a meaningful simplification. If it lives in one region, it changes nothing.

Machine shapes

AWS gives you a large fixed catalogue of instance types. Google Cloud gives you a smaller catalogue plus custom machine types, where you set vCPU and memory independently within family limits.

For workloads that sit between standard rungs, custom shapes remove the overpayment. A process needing 6 vCPUs and 44 GB of memory buys exactly that instead of the next size up on both axes. The naming schemes are covered in EC2 instance families and Compute Engine machine types.

Data and analytics

This is where Google Cloud’s heritage shows. BigQuery is a genuinely differentiated product: serverless, fast on large datasets, and priced on data scanned rather than on a cluster you keep running. Teams doing real analytical work frequently choose the platform for it alone.

AWS answers with Redshift, Athena and a wider set of building blocks. The AWS approach gives you more control and more assembly; the Google approach gives you less of both.

On machine learning, the split is similar. Google Cloud offers TPUs and a tightly integrated Vertex AI. AWS offers more instance variety, SageMaker and Bedrock as a managed model API, which is covered in Amazon Bedrock explained.

Where AWS still wins

• Catalogue breadth. If you need something unusual, AWS is more likely to have it as a managed service.
• Regions. A larger footprint, particularly outside the main markets.
• Ecosystem. More third party tooling supports AWS first, more engineers have used it, and more of the answer to your problem is already written down.
• Enterprise process. Marketplace, procurement and compliance machinery are more mature.

Where Google Cloud wins

• Cost without effort. Automatic discounts and per second billing reward doing nothing.
• Kubernetes. GKE is widely regarded as the most polished managed Kubernetes, which is reasonable given where the project came from.
• Analytics. BigQuery is a genuine reason to choose a platform.
• Networking simplicity for multi region designs.
• Console clarity. Subjective, but consistently reported.

Choosing

Pick Google Cloud if analytics is central, if you are running Kubernetes as the primary abstraction, if the application is genuinely multi region, or if nobody on the team will have time to run a cost optimisation programme.

Pick AWS if you need catalogue breadth, if you are hiring for existing skills, if a specific managed service only exists there, or if your organisation already has an AWS relationship worth preserving.

If neither is obviously right, the honest answer may be that you do not need either. For a small number of Linux servers, the providers in the Hetzner guide or the DigitalOcean guide deliver the same result with far less to learn.

For the other pairings, see AWS vs Azure and Azure vs Google Cloud.