Anyone leaving a VPS or starting a project from scratch usually gets stuck on the same question: AWS, Azure or Google Cloud? The problem is not a lack of information, it is too much of it — none of the official docs answer the question that actually matters: which one should I pick, for my case, right now.
This is not another "what is AWS" explainer. It's a decision framework, a side-by-side comparison by scenario, and the mistakes that cost the most.
Why this decision gets stuck
All three clouds solve the same problems in different ways, with different names for similar services. That creates two traps: picking the best-known brand without evaluating the real use case, or trying to study all three in depth and never actually deciding.
Neither works well. The right choice depends on three factors, in this order of priority:
What your team already knows.
The type of workload you're running (static site, API, database, containers).
How much operational complexity you're willing to take on.
What each cloud actually is, in practice
AWS — the oldest, with the largest service catalog. Practical advantage: the most tutorials, the most Stack Overflow answers, the most people who already solved your exact problem. Downside: the sheer number of options makes it easier to pick the wrong service for a simple case.
Azure — strong for companies already on the Microsoft stack (Active Directory, Office 365, .NET). Managed services like App Service tend to be more straightforward for teams that just want something running without dealing with infrastructure.
Google Cloud — historically strongest in data and AI, but Cloud Run is today one of the simplest ways across all three clouds to get an API live without managing a machine or a cluster.
Side-by-side comparison by scenario
Hosting a static site (landing page, docs, SPA frontend):
AWS: S3 + CloudFront + Route 53 — the most documented combination, but three separate services to configure.
Azure: Static Web Apps — hosting, CDN and CI/CD bundled into one service.
GCP: Cloud Storage + Cloud CDN — similar setup to AWS, fewer ready-made examples.
Running an API without managing a server:
AWS: App Runner (simpler) or ECS with Fargate (more control, more configuration).
Azure: Container Apps — direct equivalent of Cloud Run.
GCP: Cloud Run — arguably the most direct path to a running container behind a public URL.
Managed database:
AWS: RDS (relational) or DynamoDB (NoSQL, high scale).
Azure: Azure SQL Database or Cosmos DB.
GCP: Cloud SQL or Firestore.
In all three, start relational unless you have a concrete technical reason to go NoSQL — that reason is an access pattern, not "it scales better."
A practical decision framework
Does your team already know one of the three? If so, start there. The learning cost of a new cloud rarely pays off for a small project.
What do you need to run right now? Static site, stateless API, or something already on Docker Compose changes the answer.
Do you have someone dedicated to infrastructure? Without that, default to the most managed option (Cloud Run, Container Apps, App Runner) over running your own Kubernetes cluster.
Is there an external requirement? A client, partner or compliance policy that already mandates a cloud settles the question.
If none of these point anywhere, the practical answer is usually: start with AWS, because it has the most documented ready-made solution for whatever comes up next. That's not a claim of technical superiority — it's the path of least friction.
Cost: how to compare without fooling yourself
Reference prices change constantly, so this article doesn't list fixed numbers — always confirm the current value in each cloud's official pricing calculator.
No cloud is always cheaper. It depends on the service, region, and usage volume.
The biggest source of surprise bills is usually data egress, not compute — anyone coming from a VPS with "included" bandwidth gets caught off guard by this.
Free tiers differ: some are time-limited (12 months), others are always-free up to a cap.
Set up a billing alert before any test, even a small one.
Common mistakes
Choosing the "most famous" cloud without considering what the team already knows.
Provisioning managed Kubernetes for a project that fits in a single serverless container.
Ignoring egress cost when migrating from a VPS.
Deciding on compute price alone, without simulating the full scenario.
Starting multi-cloud for a small project — added complexity with no real benefit at that stage.
Checklist before choosing
List what you need to run right now.
Check which cloud the team already knows, even partially.
Set up a billing alert before any test.
Test the simplest managed service available before jumping to Kubernetes.
Simulate the full cost, including egress, in the official calculator.
Document the reason for the choice.
Originally published on RM Porto Tech, where I write about practical backend, cloud and DevOps decisions for small teams.
Top comments (0)