Entra ID + Azure RBAC vs AWS IAM vs GCP Cloud IAM

The identity layer is 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.

New to cloud? CAMPUX is a free, build-first course. Start here →

All three clouds answer the same question — who can do what to which resource — but they wire it differently. Azure splits the job in two: Microsoft Entra ID is the directory that holds identities and does sign-in, and Azure RBAC is a separate system that assigns a role at a scope. AWS IAM fuses both jobs into one service and hands you JSON policy documents. GCP Cloud IAM binds a role to a member directly on a resource. Same idea, three architectures — this is the row you cannot skim.

Every "Azure vs AWS" table on the internet writes IAM once and moves on. It's the single most misleading cell in the whole grid, because the word papers over a real difference in shape. Someone comes from AWS, opens the Azure portal looking for the one place that holds both the users and their permissions, and can't find it — because Azure keeps those in two different places on purpose. Let's take the machine apart.

Two words worth pinning down first

Every one of these systems is doing two separate things, and the whole comparison gets easier once you name them. Authentication is proving who you are — signing in, MFA, the login. Authorization is deciding what you're allowed to do once you're in. Hold that split in your head, because the clouds disagree mainly on whether those two jobs live in one system or two.

Azure: a directory and an authorization system, kept apart

Azure is the one that surprises everyone, so start here. Azure deliberately separates the two jobs into two products.

Microsoft Entra ID is the directory. It stores your users, groups, and service principals; it does authentication — sign-in, MFA, Conditional Access. It lives at the tenant level, above your subscriptions, and it's the same directory your company's Microsoft 365 already uses. Entra knows who you are. It does not, by itself, decide what you can touch in Azure.

Azure RBAC is the authorization system, and it's separate. You take an identity from Entra, pick a role — Owner, Contributor, Reader, or a custom one — and assign it at a scope: a management group, a subscription, a resource group, or a single resource. That assignment inherits downward: a role at the subscription applies to every resource group and resource beneath it. So the mental model is three moving parts — who (Entra identity), what role, and where (scope) — snapped together into a role assignment.

That's why AWS folks get lost: they expect one place. On Azure you look in Entra for the user and in RBAC (on the resource's Access control blade) for the access. Two blades, two systems.

AWS: one service, JSON policies, no separate directory

AWS IAM does both jobs in a single service, scoped to one account. Your principals are IAM users, groups, and roles, and they live inside the account — there's no tenant-wide directory sitting above it the way Entra sits above subscriptions. (Real organizations don't hand out per-account IAM users to humans; they federate people in through IAM Identity Center, the service formerly called AWS SSO. But the primitive is still the in-account principal.)

Authorization on AWS is a JSON policy document. You write, or attach, statements that allow or deny specific actions on specific resources, and you hang that policy on a principal (identity-based) or on the resource itself (resource-based — an S3 bucket policy is the classic example). Evaluation is union-of-allows with explicit-deny-wins: if any attached policy denies an action, it's denied, full stop, regardless of what else allows it. Coming from Azure, the shock is how much you're reading and writing raw JSON instead of picking a named role.

GCP: bind a role to a member, on a resource

GCP Cloud IAM lands between the two. You take a member — a user, a group, or a service account — and you bind a role to it on a resource. Roles come in three flavors: primitive (the old broad Owner/Editor/Viewer), predefined (fine-grained, per-service), and custom. Bindings inherit down the resource tree: a role bound at the organization, a folder, or a project flows to everything beneath it, much like Azure's scope inheritance.

Human identity on GCP comes from Cloud Identity or Google Workspace. And the thing that defines GCP culture: service accounts are everywhere. Almost every workload identity — a VM, a Cloud Run service, a pipeline — is a service account, and a huge share of your IAM bindings are to service accounts rather than people.

Azure hands you a named role and a scope. AWS hands you a JSON document. GCP hands you a binding on a resource. Read "IAM" as a synonym and you'll spend a day looking for a place that doesn't exist.

The one row that's genuinely the same: machine identity

For workloads — the app that needs to read a database without a human logging in — the three clouds land in almost the same spot, just with different names. An Azure managed identity or service principal plays the same part as an AWS IAM role that a workload assumes, which plays the same part as a GCP service account. In all three, you're giving a piece of software its own identity and granting that access, so you never bake a password or key into code. If you learn this pattern once, it reads straight across. It's the human side of identity where the clouds diverge.

The concrete test: "read-only on the prod database"

Abstract mappings blur together, so here's the same real task on all three. You want to give a teammate read-only access to the production database, and nothing else.

• Azure: find the person in Entra (or the group they're in), go to the database's Access control (IAM) blade, and add a role assignment — the built-in Reader role, or a data-plane reader role like SQL DB Reader, scoped to that one database. No JSON. You picked a role and a scope, and that's the whole job.
• AWS: write or attach a JSON policy that allows the read actions (say the RDS describe actions, or the specific data-API reads) on that database's ARN and nothing else, then attach it to the user or, better, to a role they assume. You're authoring a document and reasoning about which actions count as "read."
• GCP: bind a predefined role — something like Cloud SQL Viewer — to the member on that project or instance. A binding, on a resource, done.

Same intent, three motions: assign-a-role-at-a-scope, write-a-policy-document, bind-a-role-on-a-resource. Notice the Azure and GCP versions are a couple of clicks and a role name; the AWS version is the one where you're most likely to over-grant by accident, because you're hand-listing actions.

If you're learning this cold, do it on Azure first. The Entra-versus-RBAC split forces you to see authentication and authorization as two different jobs, laid out as two different screens. Once that's concrete, AWS collapsing them into one service and GCP binding roles on resources both make sense fast — you already know what the two jobs are. That's the order we teach it, starting from what the cloud even is and building up through Entra and subscriptions, then RBAC and Azure Policy, then service principals and managed identity.

Common questions