Azure vs AWS vs GCP: what's the equivalent?
You already know one cloud. This is the map that turns the other two into a rename sheet — and warns you about the three places the map lies.
New to cloud? CAMPUX is a free, build-first course. Start here →
Most of what you know carries straight across. An Azure virtual machine is an AWS EC2 instance is a GCP Compute Engine instance; Blob Storage is S3 is Cloud Storage; a VNet is a VPC is a VPC. Learn the primitive once and you've learned it three times. But three things do not map cleanly — the account and hierarchy model, the identity/IAM model, and the networking defaults — and those are exactly where a term-for-term cheat sheet gets you into trouble. This guide gives you the honest mapping and flags every leak.
I've run production on all three and taught engineers crossing between them. The first move across always feels like a language wall: a different console, a launch wizard asking the same questions in a different order, three words for one thing. Then you notice most of the wall is synonyms. The useful skill isn't memorizing the synonyms — it's knowing the handful of places where the words look like synonyms but the thing underneath is genuinely different. That's what actually costs people a weekend.
We teach Azure first here, for a plain reason: the volume of enterprise "cloud engineer" postings that name a cloud leans Microsoft, and Azure slots into the Microsoft 365 and Entra ID identity most companies already run. So this guide is written Azure-first — "you know AWS or GCP, here's the Azure column" — but it reads fine in any direction.
The one-screen translation table
Here is the glossary most "vs" articles stretch into three thousand words. Screenshot it. Then read past it, because the rows are not all equal — some are true synonyms, and a few are traps we'll open up below.
| What it is | Azure | AWS | GCP |
|---|---|---|---|
| Billing / quota boundary | Subscription | Account | Project |
| Top of the org tree | Management group | Organization + OUs | Organization + folders |
| Resource container | Resource group | (none native) — tags / stacks | Project |
| Directory of users | Microsoft Entra ID | IAM Identity Center / IAM users | Cloud Identity |
| Authorization model | Azure RBAC (role at a scope) | IAM policies (JSON on principal) | Cloud IAM (role binding on resource) |
| Non-human identity | Managed identity / service principal | IAM role | Service account |
| Virtual machine | Virtual Machine | EC2 instance | Compute Engine instance |
| Managed Kubernetes | AKS | EKS | GKE |
| Functions (FaaS) | Azure Functions | Lambda | Cloud Functions / Cloud Run functions |
| Private network | Virtual network (VNet) | VPC | VPC network |
| Object storage | Blob Storage | S3 | Cloud Storage |
| Managed relational DB | Azure SQL / Flexible Server | RDS | Cloud SQL |
| Native infra-as-code | ARM / Bicep | CloudFormation | Deployment Manager (legacy) / Config Controller |
| Secrets store | Key Vault | Secrets Manager / SSM | Secret Manager |
| Global DNS | Azure DNS | Route 53 | Cloud DNS |
The synonyms are trivia you'll stop looking up by week two. The three leaks below are the actual skill.
The mental model: what a cloud is made of
Strip the brand names and every one of the big three is the same four layers stacked the same way. Get this shape in your head and the table above stops being a list to memorize and becomes a thing you can reconstruct.
- An org tree at the top — a place to group everything a company owns and push policy and billing rollups down. Azure: management groups. AWS: an organization with organizational units. GCP: an organization with folders.
- A billing-and-quota boundary in the middle — the unit the bill and the API limits attach to. Azure: the subscription. AWS: the account. GCP: the project. This row is the first big leak.
- A place to put resources — where the VMs and databases actually live. Azure gives you the resource group for this; AWS has no native equivalent and leans on tags; GCP folds it into the project. Second leak.
- An identity system deciding who can touch any of it — Azure separates the directory (Entra ID) from authorization (RBAC); AWS fuses them in IAM; GCP binds roles to members on resources. Third leak.
Everything else — compute, storage, networking, databases, functions — is a service you drop into that skeleton, and those services map cleanly. The skeleton is where the clouds actually disagree.
The three places the map lies
If you take one thing from this hub, take these. Every cheat sheet on the internet maps these rows 1:1 and every one of them is quietly wrong.
All three are a billing boundary, so the cheat sheets line them up. But they're used at wildly different scales. An Azure subscription is roomy — it holds many resource groups, and a company runs a handful of subscriptions. An AWS account is heavier and is the hard security boundary, so mature teams run many accounts under one organization. A GCP project bills like a subscription but functions like an Azure resource group, so companies run dozens or hundreds of them. Map on the role (billing boundary), never the count. Full breakdown →
Azure's resource group is a first-class container: resources live inside exactly one, you deploy, tag, lock, and delete at that level. GCP gets the same effect from the project. AWS has no native equivalent — its "Resource Groups" feature is just a saved tag query, not a container. So the AWS way to group things is a tagging discipline plus (optionally) a CloudFormation stack. Come from Azure expecting a folder for your app and you'll be confused for a day. Full breakdown →
Azure splits identity (Entra ID stores the users and groups) from authorization (RBAC assigns a role at a scope). AWS IAM does both in one service and attaches JSON policy documents to principals. GCP binds roles to members directly on a resource and runs almost everything through service accounts. Same three letters, three genuinely different wiring diagrams — the one row you cannot skim. Full breakdown →
Go deeper, one layer at a time
The rest of this hub is a spoke per layer of that skeleton, each written the same way: the honest mapping, then where it leaks. Start at the top of the tree and work down — the account and hierarchy pieces are the ones people get wrong, so they're first.
So which cloud should you actually learn?
If the primitives are near-identical and only three layers really differ, "which cloud is best" is the wrong question. There is no best cloud; there's the ecosystem your future employer already lives in. For most people reading this that points to Azure — not out of loyalty, but because that's where the enterprise job volume is, and because Azure plugs into the Microsoft identity those enterprises already run. Learn the ideas deeply on one cloud, keep this hub bookmarked, and the other two become a week of renaming plus the three gotchas above. That's the whole thesis: concepts first, brand names second.
Common questions
What is the AWS or GCP equivalent of an Azure subscription?
The closest single match is an AWS account or a GCP project: all three are a billing and quota boundary that holds resources. But the mapping leaks. An Azure subscription can hold many resource groups and you routinely run several subscriptions per company; an AWS account is heavier, so teams run many accounts under one organization; and a GCP project bills like a subscription but functions more like an Azure resource group, so most companies run dozens of them. Map on the role — billing boundary — not the word.
Is Azure RBAC the same as AWS IAM?
They solve the same problem — who can do what to which resource — but the models differ. Azure splits identity (Entra ID, which stores users and groups) from authorization (Azure RBAC, which assigns roles at a scope). AWS IAM does both inside one service and attaches JSON policies to users, groups, or roles. GCP Cloud IAM binds roles to members on a resource and leans hard on service accounts. The concept transfers; the wiring does not.
If I learn one cloud, can I use the other two?
Mostly yes for the primitives — VMs, object storage, private networks, load balancers, and functions are the same ideas with different names, and you can read them straight across in a week. What does not transfer for free is the account hierarchy, the identity and IAM model, and the networking defaults, which are genuinely different on each cloud. Learn one deeply and the second is renaming plus three real gotchas, not relearning.
Which cloud should I learn first?
For most people chasing a job, Azure — because the volume of enterprise "cloud engineer" postings that name a specific cloud leans Microsoft, and Azure slots into the Microsoft 365 and Entra ID identity most companies already run. The concepts you learn transfer to AWS and GCP as accents. Learn the ideas on one cloud, then this guide is how you carry them to the others.