Choosing among AWS, GCP, and Azure — what actually differs

Everything covered so far in this domain — regions and availability zones, object/block/file storage, VMs/containers/serverless, on-demand/reserved/spot pricing — exists, in some form, on every major cloud provider. What differs between them is mostly the specific product names, some genuine feature/pricing differences, and the ecosystem each has built around its core services. Learning the underlying concepts first (which is exactly what this domain is for) means the specific provider becomes a vocabulary problem, not a from-scratch relearning exercise.

AWS is, by most measures, the largest cloud provider by market share and the most commonly required in job postings for general backend/infrastructure roles — which is the practical reason the domain immediately following this one goes deep specifically on AWS's services, console, and CLI, rather than trying to teach three providers' specifics simultaneously (which would triple the surface area without tripling the value, given how much genuinely transfers once you understand one provider well). The concepts in this domain — the ones covered so far, plus the patterns in the lessons ahead (queues, secrets management, auto-scaling, observability, cost control) — are written to be useful regardless of which specific provider you end up using; the dedicated AWS domain is where those concepts turn into hands-on knowledge of one real, extremely common provider's actual tools.

The equivalence map above is a starting point, not a claim that every row is functionally identical:

None of this means one provider is simply "better" in the abstract — the right choice depends on what a specific team already knows, what a specific employer or client already uses, and which specific services actually matter most for a specific workload.

The map is most useful in two situations: reading documentation or a job posting that assumes familiarity with a provider you haven't used yet (translate the unfamiliar product name to the concept you already know), or evaluating a genuine multi-cloud or migration scenario (understanding what maps to what before assuming a lift-and-shift is straightforward — some services have no clean equivalent on another provider, which is itself useful to know before committing to a migration plan).