The market as it is
Ask which cloud is best and you will get an answer shaped by whoever is talking — the platform they learned first, the conference they last attended, the shirt they were given. It is close to asking which language is best: the honest reply is that they are more alike than their partisans admit, and the right one depends on who you already are.
Here is the shape of it, stripped of loyalty. Three providers dominate, and they are called hyperscalers because they operate at a scale an order of magnitude beyond anyone else. Amazon Web Services came first and is still the largest, holding roughly a third of the market. Microsoft Azure is second, around a quarter, and dominant in organisations that already run on Microsoft. Google Cloud is third, near a tenth, with a reputation earned in data, analytics and machine learning.1
- Hyperscaler
- A cloud provider operating a global fleet of datacentres at massive scale — AWS, Azure and Google Cloud. The scale is the point: it is what makes the elasticity of Class Two real rather than aspirational.
Two facts matter more than the rankings. First, all three sell the same core primitives — compute, storage, networking, identity, databases — because those primitives are what a cloud is. Second, market position is not a personal recommendation: AWS being largest does not make it right for Campux, any more than the most-spoken language is the right one to write your particular letter in. Fandom picks a winner; an engineer picks a fit.
The same dish, three menus
Most of what looks like difference between the clouds is vocabulary. A virtual machine is a virtual machine whether the invoice calls it EC2, a Virtual Machine, or a Compute Engine instance. Learn to read the table below in both directions and half of cross-cloud fluency is already yours.
| What it is | AWS | Azure | Google Cloud |
|---|---|---|---|
| Virtual machines | EC2 | Virtual Machines | Compute Engine |
| Object storage | S3 | Blob Storage | Cloud Storage |
| Serverless functions | Lambda | Azure Functions | Cloud Run functions |
| Managed Kubernetes | EKS | AKS | GKE |
| Virtual network | VPC | Virtual Network (VNet) | VPC |
| Managed relational DB | RDS / Aurora | Azure SQL Database | Cloud SQL |
| NoSQL / document DB | DynamoDB | Cosmos DB | Firestore / Bigtable |
| Content delivery (CDN) | CloudFront | Front Door | Cloud CDN |
| Identity & access | IAM | Microsoft Entra ID | Cloud IAM |
Use the table for what it is good for — "where would this live on the other cloud" — and distrust it for what it is not. It is a phrasebook, not a dictionary of exact synonyms. Amazon's RDS and Azure SQL Database occupy the same slot but differ in pricing, limits and features; the identity row is looser still, because Microsoft Entra ID is a full directory and identity provider while AWS and Google IAM are more narrowly about access to their own resources.2 The row tells you which shelf to look on. It does not promise the products are interchangeable.
Why Microsoft shops choose Azure
If the primitives are near-identical, why does any particular company land where it does? Rarely because of a feature comparison. Usually because of what the company already owns. For the large population of organisations already running on Microsoft, Azure wins on gravity, not on any single service being best.
The reasons are concrete and financial. A company already paying for Microsoft 365 and enterprise licensing often finds Azure folded into an agreement and a relationship it already manages — one vendor, one invoice, one support contract, one account team.3 Its staff already administer Windows and its identities already live in a Microsoft directory, so the learning curve and the identity integration are shorter than a move to a stranger's platform. None of this makes Azure technically superior. It makes it the path of least friction for a company shaped a particular way — and a great many enterprises, wherever Microsoft 365 already runs the desktops, are shaped exactly that way.
This is worth saying plainly because it is the honest answer to "why Azure" in an interview, and it is Campux's answer too. The right cloud is frequently the one your organisation is already halfway standing in.
What transfers, and what doesn't
The most valuable thing to understand about the three clouds is which of your skills survive a move between them. Get this right and you never fear a job posting again.
- Transfers cleanly
- The concepts. Shared responsibility, elasticity, the service and deployment models, identity and least privilege, networking fundamentals, cost discipline. These are the same on every cloud because they are properties of the idea, not the vendor.
- Transfers with effort
- Architecture patterns and services. You will find the counterpart quickly using the Table 1 habit, then spend a week learning where it differs — limits, defaults, pricing, the peculiar way each cloud does networking.
- Does not transfer
- Console muscle-memory. Which blade, which button, the exact CLI flag, the shape of a particular provider's IAM policy language. This is the shallowest layer, relearned in days, and the one beginners overvalue most.
Learn the concept; the console is disposable.
Notice the inversion beginners make: they treat the console they know as their expertise and the concepts as background. It is exactly backwards. The engineer who understands why a private network is segmented and how identity federates can walk onto any of the three clouds and be useful within a fortnight. The one who only knows where AWS hides a setting is stranded the moment the screen changes. One difference between the clouds worth holding as an example: a Google VPC is global, spanning every region at once, while an Azure VNet and an AWS VPC are regional — the same word, a genuinely different design, and precisely the kind of detail you look up rather than memorise.
Why this bootcamp is Azure
You are learning on Azure, and that is a deliberate choice rather than a limitation. Azure is the dominant cloud in exactly the enterprises that hire people to run it, its identity and governance model is a clear, teachable spine for the concepts this bootcamp is really about, and Campux — a Microsoft-shaped company — would genuinely choose it. Learning cloud engineering somewhere it is actually practised beats learning it in the abstract.
Why Campux chose Azure
Campux did not run a feature bake-off. It looked at what it already had. Staff email and productivity already ran on Microsoft 365 under E5 licensing — the SaaS you mapped in Class Four — so identity already lived in a Microsoft directory and the finance relationship already existed. Adding Azure meant one more line on an agreement it already signed, governed by one account team, secured with identities its people already carried.
The alternative was to bolt a second strategic vendor onto a six-person team: a new contract, a new identity boundary to bridge, a new console for everyone to learn, and the multi-vendor tax you priced in Class Five. For Campux the decision was not "which cloud is best" but "which cloud are we already half inside," and the answer was Azure. That is how most real cloud decisions are actually made — and being able to say so, without embarrassment, is a mark of someone who has seen one.
The one who does not need a phrasebook
A partner describes their stack in AWS terms — "it is on EC2 behind an ALB in a VPC." You translate on the fly: virtual machine, load balancer, virtual network. Because you can map the concepts across clouds, the conversation never stalls on vocabulary, and you become the person who can work with the shop next door without reaching for a phrasebook.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B. S3 is object storage, and its Azure counterpart is Blob Storage. D is the near-miss that catches the hasty: Azure Files is managed file shares — a different shape of storage for a different job. The point of the phrasebook is not just to find a storage service but the one on the same shelf. Object storage maps to object storage; get the category right and the name follows.
C. Managed Kubernetes is EKS on AWS, AKS on Azure, GKE on Google — the three-letter family is the giveaway. A is serverless functions, B is plain virtual machines, and D names real services that run containers without managing a Kubernetes cluster, which is a different category again. The lesson repeats: match the category first, and the trap answers stop being tempting.
Shared primitives, egress charges, and the core concepts. Those hold everywhere because they are properties of what a cloud is. The two false statements are the ones worth having wrong once: the global-network claim is true only of Google's VPC — Azure and AWS networks are regional — and the console/CLI claim is exactly the muscle-memory that does not transfer. If you selected either, you have found the belief this class is built to correct.
CROSS-CLOUD CHEAT SHEET — AWS to Azure
1. S3 -> Azure Blob Storage
2. EC2 -> Azure Virtual Machines
3. Lambda -> Azure Functions
4. DynamoDB -> Azure SQL Database
Line four. DynamoDB is a NoSQL, key-value store; its Azure counterpart is Cosmos DB, not Azure SQL Database, which is a managed relational engine. The mapping jumped shelves — from NoSQL to relational — which is the single most common cross-cloud translation error.
Consider the consequence. Plan a migration with that line intact and you size a relational database for a workload that expects key-value semantics, then discover mid-project that queries, indexing and data model do not fit — a redesign found late, when it is expensive. The phrasebook works only if you keep to the same category; DynamoDB to Azure SQL is a mistranslation that changes the meaning of the sentence.
The question is really whether you learned cloud or learned a console. Do not apologise for Azure and do not bluff AWS fluency you lack. Reframe: what the role needs is someone who understands shared responsibility, identity and least privilege, networking, elasticity and cost — and those are identical across providers. You learned them; you can demonstrate them.
Show the translation habit in action. Say it out loud: S3 is Blob Storage, EC2 is a Virtual Machine, Lambda is Functions, EKS is AKS. Naming the mapping fluently proves you see the primitive beneath the brand — which is exactly the competence the posting is fumbling to describe when it writes "AWS."
Close on the honest timeline. "The concepts transfer immediately; the AWS-specific console and quirks are a week or two, not a career." That answer converts a rejection into a conversation, and it happens to be true — which is why it survives the follow-up questions a bluff would not.
Separate the market fact from the Campux decision. AWS being largest is true and irrelevant to a six-person Microsoft shop — the biggest platform is not automatically the right one, any more than the most popular language is the right one for your particular letter. The manager has mistaken a popularity statistic for a recommendation.
Price the switch honestly. Campux chose Azure for reasons that have not changed: E5 licensing already paid for, identity already in a Microsoft directory, one vendor relationship. Switching now would abandon that gravity, restart the migration, retrain the team on a new console, and split the strategic relationship — real, immediate cost to chase a benefit that is a headline, not a need.
Reassure them on the thing they actually fear. Nothing is lost by staying: the concepts are identical across clouds, and the portable practices you are building — infrastructure as code, standard patterns — keep the door open if a genuine reason to move ever arrives. "Biggest" is not a reason; a concrete need would be, and we do not have one.
Five things worth carrying out of this class
- Three hyperscalers sell the same core primitives under different names. AWS leads, Azure is strong in enterprise, Google in data and AI.
- The translation table is a phrasebook, not a dictionary. It tells you which shelf to look on, not that the products are interchangeable.
- Companies choose a cloud by gravity — existing licensing, identity, vendor relationships — far more than by feature comparison.
- Concepts transfer instantly; patterns transfer with a week's effort; console muscle-memory does not transfer and barely matters.
- Learning on Azure is not a limitation. The concepts are the job, and they are the same wherever you practise them.
- The market-share figures move every quarter and are measured differently by every analyst; treat "about a third, a quarter, a tenth" as the durable shape rather than exact numbers. The direction — three hyperscalers well clear of the field, AWS first and Azure second — has held for years and is the part worth remembering. ↩
- The identity row is the loosest in the table. Microsoft Entra ID is a full directory and identity provider — the thing you sign in to — whereas AWS IAM and Google Cloud IAM are primarily about granting permissions to resources within their own clouds. They overlap enough to share a row and differ enough that you should never assume feature parity. Class Seven takes Entra ID apart properly. ↩
- Service names and packaging shift constantly — Google's function service was renamed to Cloud Run functions, Azure Active Directory became Microsoft Entra ID, licensing bundles are repackaged yearly. Learn the capability and the reasoning; verify the current name and the current bundle against the provider's own pages before you put either in a plan. ↩