The same dish, three menus: the market as it actually is, what transfers between the big three, and why a Microsoft shop reaches for Azure.
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.
Price the same machine on three menus
The translation table becomes real the first time you price one machine three ways. You will configure the same modest server — 2 vCPUs, 8 GB of memory, Linux, pay-as-you-go — on each provider's public calculator, and walk away with three names and three numbers for one dish.
Open Azure's pricing calculator — search azure pricing calculator — and add a Virtual Machines estimate: Linux, pay-as-you-go, one instance, and a 2 vCPU / 8 GB size (the D2as v5 family fits at the time of writing). Note the monthly figure.
On screen: the size picker is the menu from Figure 1 — dozens of names for one question, "how much machine?" Write down the name you chose as well as the price; you will need both in step four.Do the same on AWS's calculator: create an EC2 estimate with a 2 vCPU / 8 GiB instance (m6a.large is the shape at the time of writing), Linux, on-demand.
On screen: same dish, different menu — "instance type" instead of "VM size," "on-demand" instead of "pay-as-you-go." The vocabulary shifts; the thing being priced does not.Finish on Google's calculator: add a Compute Engine estimate with an e2-standard-2 machine type (2 vCPUs / 8 GB), Linux, no commitment.
On screen: a third menu for the same primitive. Notice what all three calculators quietly agree on: the meter runs by the hour, and the region you pick moves the price.Write the three lines side by side — name and monthly price for each. You now hold the whole class in one row of your notebook: three names, three prices in the same neighbourhood, one rented server.
The lesson: if the numbers land within shouting distance of each other, you have just verified §1's claim that the primitives are commodities — and that the real differences between clouds live elsewhere: in gravity, identity and what your company already owns.
Calculator layouts, instance names and prices all drift — treat the specific sizes named here as directions, not gospel, and expect the numbers you get to differ from anyone else's by region and by month. The three-names-one-dish finding is the durable part.
Zoom out: the cloud you pick is a system you — and your hiring — inherit
You can compare the three big clouds without fandom. Now reason about what committing to one does to the whole organisation over years, because a cloud choice outlives the workload that prompted it.
Committing to one cloud deepens the team's fluency in it, which makes every next thing easier there and harder elsewhere, which deepens the commitment. Lock-in is not a trap someone springs — it is a loop you walk into by getting good.
Beyond the VMs, you couple to the cloud's identity, its networking model, and its managed services' quirks. The portable eighty percent — compute, storage, the concepts — hides a load-bearing twenty percent of proprietary glue that does not move.
The constraint on "we could switch" is rarely the technology — it is the retraining, the rewrites of the proprietary glue, and the muscle memory of the team. The switching cost is mostly human.
Choosing the cloud your existing estate already speaks — Azure for a Microsoft shop — buys integration and hiring almost for free, and quietly narrows the future to that ecosystem's roadmap. Both halves are real.
A "best tool per job, across clouds" strategy that is a tidy diagram at one team becomes an unstaffable matrix of skills, tools, and on-call at fifty — which is why it so often collapses back to "one cloud, run well".
The engineer who ships is asked "which cloud?" The engineer who gets promoted is asked "and what does the org inherit for the next five years?" — and has priced the human cost, not just the sticker.
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.
B. This is §3's gravity, applied: the licensing agreement already exists, the identities already live in a Microsoft directory, and the staff already administer Windows — the shortest path by every measure that costs money. A mistakes a market statistic for a recommendation. C sizes an estate to its newest team; the analytics workload may one day earn an exception, argued as a workload, never as the estate. D is Class Five's multi-cloud tax volunteered for — three consoles, three on-call rotations, one company. The skill being marked is separating the estate decision from the workload decision, and saying "gravity" out loud without embarrassment.
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. ↩