Azure vs AWS vs GCP: the equivalents, service family by service family

You already know one cloud. This is the map that turns the other two into a rename sheet — and warns you about the places the map lies. One section per service family, with the traps named.

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 virtual network is a VPC is a VPC. Learn the primitive once and you have learned it three times. But three things do not map cleanly — the account and hierarchy model, the identity model, and the networking defaults — and those are exactly where a term-for-term cheat sheet gets you into trouble.

I have 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 is not memorizing the synonyms — it is knowing the handful of places where the words look like synonyms but the thing underneath is genuinely different. That is what costs people a weekend.

The one-screen translation table

Here is the glossary most comparison articles stretch into three thousand words. Screenshot it, then read past it, because the rows are not equal: some are true synonyms and a few are traps.

The synonyms are trivia you will stop looking up by week two. The three leaks below are the actual skill.

Accounts and hierarchy: the first leak

Every cheat sheet lines up subscription, account and project in one neat row. That row is the single most misleading line in cloud, because the three are the same on billing and completely different on isolation.

That isolation row is the whole trap. An AWS engineer creates accounts freely because the account is the blast-radius boundary; an Azure engineer who copies that habit ends up with dozens of subscriptions and an administrative mess, because in Azure the isolation is supposed to come from RBAC and policy rather than from the subscription count. Going the other way, an Azure engineer who treats an AWS account like a subscription will put production and development in one account and be surprised how little separates them.

The layer above: management groups, OUs and folders

The enforcement row matters more than the names. Azure Policy can do things — deny, but also audit, modify a resource, or deploy a missing one. A service control policy can only take permissions away, never grant them, so an AWS guardrail cannot remediate; it can only forbid. Design accordingly: on Azure you can auto-fix a missing tag, on AWS you can only refuse the deployment that lacks it.

The container that AWS does not have

This is the leak that hurts people crossing into AWS. There is no box to put an application in, so tagging discipline is not a nice-to-have — it is the only thing standing between you and an untraceable bill. And crossing the other way, a GCP engineer has to notice that a project is doing two jobs at once, acting as both the billing boundary and the resource container, which is why GCP estates end up with far more projects than an Azure estate has subscriptions.

Identity: the biggest lie the cheat sheets tell

They put "IAM" in one row across all three clouds. Underneath that word are three genuinely different machines, and this is the section worth reading twice.

The split in the first three rows is the thing to internalize. On Azure, who you are and what you may do are deliberately two systems: Entra ID authenticates, Azure RBAC authorizes, and you can hold an Entra identity with no Azure permissions at all. On AWS and GCP they are one service. That is why an Azure question about "IAM" is ambiguous until you say which half you mean, and why AWS engineers keep looking for the policy JSON that Azure does not have.

The non-human row is the other one that bites. An AWS engineer reaches for a role and assumes it; an Azure engineer attaches a managed identity to a resource and grants it a role; a GCP engineer creates a service account, which is both an identity and a resource you can grant others access to. Three different mental shapes for the same job.

Networking: same primitives, different defaults

Because AWS is the most common origin, here is the crib sheet in that direction specifically, with the thing to watch in each row.

Virtual machines

This family is the cleanest mapping of the lot — it really is mostly a rename sheet. The one habit worth carrying carefully is the billing distinction: an Azure VM that is stopped from inside the guest still reserves compute and still bills, and only a deallocated VM stops the compute meter. The equivalent surprise exists on the other clouds in different shapes, so check what "stopped" means before you rely on it to save money.

Managed Kubernetes

Kubernetes itself is the portable part; what differs is everything around it — how nodes are managed, how a pod gets a cloud identity, and who pays for the control plane. The identity row is where cross-cloud experience actually transfers least, because each provider solved "let this pod talk to that managed service" in its own way.

Functions

Two rows carry the real difference. Bindings are genuinely distinctive to Azure: you declare that a function reads from a queue and writes to a table, and the platform does the plumbing, where the other two have you call an SDK. And the function app is a grouping concept the others lack, which matters for cost and scale because the plan is attached to the app rather than to each function.

On pricing, all three meter roughly the same way — invocations plus resource-seconds, with a free grant — and the numbers move often enough that quoting them here would age badly. Price your own shape in each provider's calculator. For a small project the honest answer is that the bill will be near zero on any of them and the choice should turn on which ecosystem your other services live in.

Object storage

The storage account is the leak here. On AWS and GCP a bucket is a top-level thing you create directly; on Azure the container lives inside a storage account, and the account is where redundancy, network rules, firewall settings and the endpoint name are configured. Engineers arriving from S3 routinely miss that a decision they think they are making per bucket is actually made once per account.

Infrastructure as code

So which do you learn?

One, deeply, and then the others are a translation exercise rather than a new subject. The tables above are the whole reason: the primitives are the same and only the vocabulary and a few structural decisions differ. Learn what a private network, an identity, a role assignment, an object store and a deployment template are, and the second cloud costs you a fortnight rather than a year.

If you have no reason to prefer one, the volume of enterprise postings that name a cloud leans Microsoft, and Azure slots into the identity most companies already run. But the honest answer is to learn whichever your target employers run, because depth in the one they use beats a shallow tour of all three every time.

Questions people also ask

What is the AWS equivalent of an Azure subscription?

An AWS account, on billing and quota — but the two behave differently in practice. An AWS account is also the strong isolation boundary, which is why AWS estates have many accounts, while Azure expects isolation to come from RBAC and policy inside a smaller number of subscriptions. Copying the AWS habit into Azure produces an administrative mess, and copying the Azure habit into AWS produces production and development sharing a wall that is not there.

What is the Azure equivalent of a VPC?

A virtual network. The primitives map closely — subnets, route tables, peering, VPN and a dedicated private link all have direct counterparts. The differences to watch are that Azure subnets span availability zones, that there is no internet-gateway object, that the network security group does the job of both a security group and a network ACL with priority-numbered allow and deny rules, and that peering is non-transitive so hub-and-spoke needs user-defined routes.

Is IAM the same on Azure, AWS and GCP?

No, and this is the biggest thing the cheat sheets get wrong. Azure deliberately splits identity from authorization: Entra ID says who you are and Azure RBAC says what you may do, as two systems. AWS and GCP combine both in one service. Azure grants access by assigning a named role at a scope, AWS by attaching a JSON policy to a principal, and GCP by binding a role to a member on a resource.

Does AWS have resource groups like Azure?

Not as a real container. Azure resource groups and GCP projects are first-class objects that resources live inside and that delete their contents when removed. AWS has no equivalent box, so grouping is done with tags and deployment stacks. That makes tagging discipline mandatory rather than optional on AWS, because tags are the only lever for both access conditions and cost attribution.

What is the GCP equivalent of CloudFormation?

Infrastructure Manager, which runs Terraform as a managed service. The older answer, Deployment Manager, is deprecated: support was discontinued on 1 April 2026 and new users were blocked from enabling it on 30 June 2026. Any comparison still naming Deployment Manager as the native tool predates that change.

What is the difference between Azure Functions and AWS Lambda?

Mostly grouping and wiring. Azure Functions live inside a function app that holds several functions and carries the hosting plan, while each Lambda stands alone. Azure also has bindings, which declare inputs and outputs so the platform handles the plumbing, where Lambda has you call the SDK in your code. Both meter invocations and resource-seconds with a free grant, so for a small project the bill is near zero either way and ecosystem fit should decide it.

Which is easier, AKS, EKS or GKE?

GKE is generally the most automated, AKS the most straightforward for Microsoft-centric teams, and EKS the most flexible with the most setup. Kubernetes itself is the portable part; what differs is node management, who pays for the control plane, and how a pod gets a cloud identity — and that last one is where cross-cloud experience transfers least, because each provider solved it differently.

Should I learn Azure, AWS or GCP first?

Whichever your target employers run, and then only one until you are deep. The primitives are shared, so the second cloud is a translation exercise measured in weeks rather than a new subject. If you have no signal either way, enterprise postings that name a cloud lean Microsoft and Azure fits the identity stack most companies already run.