The big-3 mental model: AWS, GCP & Azure

Newcomers burn a lot of energy on the wrong question: "Which cloud should I learn — AWS, Google, or Azure?" The liberating answer is that it barely matters at the level that counts, because the three are roughly 90% the same idea wearing three different brand names. Once you grasp that, you can learn cloud rather than learning one vendor, and your skills become portable. This lesson hands you that mental model.

Meet the three giants

There are three dominant general-purpose cloud providers, collectively "the big three":

• AWS — Amazon Web Services. The oldest and largest, launched in 2006. It has the most services and the widest adoption, so it's the most common to encounter in industry. Its naming is famously idiosyncratic (lots of un-guessable product names).
• GCP — Google Cloud Platform. Known for strong data, analytics, networking, and Kubernetes heritage (Google created Kubernetes). Generally cleaner, more descriptive naming.
• Azure — Microsoft Azure. Deeply integrated with the Microsoft enterprise world (Windows, Active Directory, Office). Very strong in large enterprises that already run Microsoft software.

There are capable others (Oracle Cloud, IBM, and developer-focused platforms like Cloudflare, DigitalOcean, Fly.io, and Vercel), but the big three define the shape of the industry, and what you learn about them transfers to the rest.

The 90% that's identical: shared primitives

Strip away the marketing and all three offer the same handful of primitives — the building blocks from this guide's core idea. Each just gives them a different brand name. The single most useful table in cloud engineering is the translation table:

Concept (the durable thing)	AWS	Google Cloud	Azure
Virtual machine (compute)	EC2	Compute Engine	Virtual Machines
Object storage	S3	Cloud Storage	Blob Storage
Managed relational DB	RDS	Cloud SQL	Azure SQL / DB
Serverless functions	Lambda	Cloud Functions	Azure Functions
Managed Kubernetes	EKS	GKE	AKS
Virtual private network	VPC	VPC	Virtual Network
Identity & access	IAM	IAM	Entra ID / RBAC
Container registry	ECR	Artifact Registry	ACR

Read that table the right way and a profound simplification appears: the left column is what you actually learn; the other three columns are vocabulary. "Object storage" is a durable concept — a place to store files, addressed by name, that you'll meet in Chapter 2. AWS calls its version S3, Google calls it Cloud Storage, Azure calls it Blob Storage, but they do the same job in the same way. Learn object storage once and you can use all three with a glossary.

:::tip This is the entire philosophy of this guide We teach the concept (the left column) and show it across providers where it helps. That's why a single guide can make you effective on any of the three: the transferable knowledge lives in the concepts, not the brand names. A "Kubernetes engineer" is valuable on EKS, GKE, and AKS, because Kubernetes is the concept and the three are just hosts for it. :::

The 10% that actually differs

The differences are real but they live at the edges, and they're mostly the wrong thing for a beginner to obsess over:

• Naming and console layout. Mostly cosmetic — the translation table above handles it.
• The exact IAM/permissions model. Each provider's identity system has its own structure and quirks; this is the area where porting between clouds takes genuine effort (covered in Chapter 2).
• Premium / specialized services. Each has standout strengths — Google's data and ML tooling, AWS's sheer breadth, Azure's Microsoft-ecosystem integration. These matter when you're choosing a provider for a specific need.
• Pricing details and free tiers. All dated, all constantly changing; never memorize them.

None of these change the core skills. They're what you look up once you've picked a provider for a real project.

So which one should you actually learn?

A practical answer, in priority order:

1. If a job, team, or project already uses one — learn that one. The best cloud to learn is the one you'll actually use. Don't overthink it.
2. If you're choosing fresh for general career value — AWS is the safe default purely because it's the most widely used, so the skills are the most in-demand. (This is a dated market fact, true in 2026, not a law of nature.)
3. Either way, learn the concepts deeply and treat the provider as the place you practice them. A person who deeply understands compute, storage, networking, IAM, and IaC can move to any cloud in weeks. A person who memorized AWS button locations cannot.

:::note Don't try to learn all three at once Concepts are shared, but fluency in a provider's console, CLI quirks, and IAM model takes focused time. Pick one provider to be hands-on with, learn the universal concepts through it, and rely on the translation table to read the other two. Breadth across all three comes naturally later — and is rarely needed before then. :::

Why it matters

The big three — AWS, GCP, and Azure — are about 90% the same set of primitives (compute, storage, databases, networking, identity) wearing different brand names; the translation table turns their vocabularies into one shared concept set. The real 10% of difference lives in naming, the precise IAM model, premium services, and (ever-changing) pricing — edges you look up, not foundations you memorize. So the winning strategy is learn the concept once, pick one provider to practice on, and let the table translate the rest. Your value as a cloud engineer comes from understanding the durable primitives, which is exactly what the next chapter builds out in depth.

That completes the foundations: you know what the cloud is, who's responsible, where it lives, how you control it, and that the three providers are one idea in three accents. A short checkpoint follows to lock it in — then Chapter 2 opens up the core services themselves.

Where this leads: every service in Core Services (Chapter 2) is taught as a concept first, then mapped across these three providers using exactly this table.

Next: Chapter 1 checkpoint →