Choosing a Cloud

In one line: For a new project the right answer is usually "don't pick a cloud yet — stay on a platform"; when you do need one, the decision is driven by your team's existing gravity (skills, employer, ecosystem) far more than by feature checklists, because all three hyperscalers can do essentially everything.

In plain English

People treat "which cloud?" as a momentous, hard-to-reverse decision and research it for weeks. It mostly isn't. AWS, GCP, and Azure are ~90% the same primitives with different names and consoles; any of them will run your app fine for years. The factors that actually decide it are boring and practical: what your team already knows, what your company already uses, where your enterprise customers require their data to live, and which has the one specialized service you need. And the bigger decision — the one that actually saves you money and time — is the earlier one: do you need a raw cloud at all yet, or should you stay on Vercel/Railway/Fly? This page is about making both calls without overthinking them.

First decision: do you even need a cloud yet?

Re-read the chapter intro and the cost crossover. The honest default for a new web app in 2026:

New web app?
   │
   ├─ Indie / startup / MVP / side project   → Platform (Vercel, Cloudflare, Railway, Fly)
   │                                            Don't touch a raw cloud.
   │
   ├─ Outgrew the platform (cost, a missing   → Now pick a cloud.
   │   capability, compliance, scale)
   │
   └─ Joining a company that already runs on  → Use whatever they use. The decision
       a cloud                                   is already made; learn that one.

Adopting a raw cloud "to be serious" or "to be ready to scale" is the most common premature-complexity mistake in this whole chapter — it's premature optimization at the infrastructure level. The platform premium buys you velocity; pay it until the math or a hard requirement says otherwise.

When you do choose: the factors that matter

In rough order of real-world weight:

1. Existing team skills. A team fluent in AWS ships reliably on AWS and slowly on GCP for the first six months. Competence you already have beats a marginally nicer service. This usually dominates.

2. Organizational gravity. Already a Microsoft/Office/Active Directory shop? Azure's integration is a genuine, money-and-time-saving advantage (SSO, identity, hybrid). Already deep in Google Workspace / BigQuery? GCP fits. The cloud that disappears into your existing tooling wins.

3. The one service you actually need. Sometimes a specific managed service tips it: BigQuery (GCP) for serious analytics, the broadest service catalog and maturity (AWS) for "we'll need something exotic eventually," best-in-class managed Kubernetes and developer ergonomics (GKE/Cloud Run on GCP), Microsoft-ecosystem and government/enterprise compliance (Azure).

4. Compliance & data residency. Enterprise/regulated customers may require a specific cloud, specific regions, or specific certifications (FedRAMP, certain healthcare/finance attestations). This can be a hard constraint that overrides everything else.

5. Pricing. Real but usually a wash at the start, and negotiable at scale (all three discount heavily for committed spend). Don't choose a cloud on sticker price; choose on fit, then optimize cost with FinOps.

The three, characterized honestly

	AWS	Google Cloud	Azure
Pick it when	You want the safe default, the widest catalog, the most hiring/docs/Stack Overflow answers	You're data/ML-heavy, value DX, or want the best serverless-container & Kubernetes experience	Your org lives in Microsoft/AD, or enterprise/gov compliance requires it
Strengths	Breadth, maturity, every service exists, huge talent pool	Cloud Run, GKE, BigQuery, clean project model, good ergonomics	Entra ID/AD integration, hybrid cloud, enterprise sales/compliance
Friction	Sprawling, baroque IAM, easy to get lost in 200+ services	Smaller ecosystem/community, fewer third-party integrations	Console/UX rough edges, AWS-centric tutorials don't map cleanly
Safe-default verdict	If you have no other signal, AWS is the lowest-regret choice	Strongest technical experience for greenfield, especially data/containers	Rarely chosen fresh unless Microsoft gravity is already present

Highlight: multi-cloud is a goal you should be suspicious of

"Let's be multi-cloud so we're not locked in" sounds prudent and is usually a trap for anyone who isn't a hyperscale company. Running well on one cloud is already a serious operational skill; running on two means you build to the lowest common denominator (no using the good managed services), double your tooling and on-call surface, and pay egress to move data between them. The lock-in you're avoiding is mostly theoretical; the complexity you're buying is immediate and real. Pick one cloud, use its managed services fully, and revisit multi-cloud only if a concrete requirement (a giant customer's mandate, true hyperscale resilience) forces it. This is boring technology applied to clouds.

How reversible is the choice, really?

More than the lock-in discourse implies, less than "it's nothing." Your application code is largely portable — a containerized app moves between clouds in days. What's sticky is the stuff you build around a cloud's proprietary services: deep DynamoDB modeling, a Step Functions workflow, BigQuery pipelines, IAM/networking expressed in that cloud's IaC. The more you lean into a cloud's unique managed services (which you should, for velocity), the more a migration costs.

The pragmatic stance, consistent with the rest of the guide: lean into one cloud's managed services for the velocity, accept the lock-in as a deliberate trade, and know that migration — if you ever need it — is a finite, weeks-to-months project, not a catastrophe. Designing for portability you'll probably never use is paying a daily tax to avoid a one-time bill.

Common mistakes

Where people commonly trip up

• Adopting a raw cloud for a project that should be on a platform. The biggest, most common error. Stay on Vercel/Railway/Fly until cost, capability, or compliance forces the move.
• Choosing a cloud on a feature checklist instead of team fit. All three can do ~everything; the cloud your team knows (or your org already uses) will out-ship the "technically best" one.
• Going multi-cloud for theoretical lock-in avoidance. You build to the lowest common denominator and double your operational surface to avoid a problem you don't have. Pick one.
• Refusing to use a cloud's good managed services to 'stay portable.' You give up the velocity that justified the cloud in the first place. Use the services; treat lock-in as a known, deliberate trade.
• Over-researching the choice. Weeks of comparison for a ~90%-identical decision. Default to AWS if you have no signal, GCP if you're greenfield/data-heavy, Azure if you're a Microsoft shop — then go build.

Chapter wrap-up

You now have the four deep concepts that make any cloud legible — compute models, VPC networking, IAM, and IaC — plus storage, managed data, serverless patterns, and the cost discipline to run it without surprises. The throughline of the whole chapter: the cloud is the powerful, operationally-heavy floor beneath the platforms you already know; step onto it deliberately, use its managed services fully, and keep least-privilege and infrastructure-as-code as non-negotiables.

Page checkpoint

Checkpoint Quiz

Did choosing a cloud stick?

Required

What's next

→ You've finished the cloud pillars. Take the Chapter 6 checkpoint, then continue to Chapter 7: SRE & Operations — keeping all of this alive and healthy in production.