AWS IAM vs Azure Entra ID vs Google Cloud IAM
All three answer the same question: who can do what, on which resources. They split the work differently. AWS IAM handles identities and permissions in one service. Google Cloud IAM binds roles to principals on a resource hierarchy. Azure separates the identity directory (Entra ID) from resource permissions (Azure RBAC), so Entra ID alone is not the equivalent of AWS IAM.
What is the difference between AWS IAM, Azure Entra ID and Google Cloud IAM?
- AWS IAM defines identities (users, groups, roles) and JSON policies that allow or deny actions on resources. An explicit deny always wins.
- Azure Entra ID is the identity directory: sign-in, single sign-on, MFA and Conditional Access. What identities can do to Azure resources is decided by Azure RBAC role assignments.
- Google Cloud IAM grants a role to a principal on a resource, and grants inherit downward from organization to folders to projects to resources.
How do they compare side by side?
| Aspect | AWS IAM | Azure Entra ID + RBAC | Google Cloud IAM |
|---|---|---|---|
| What it is | AWS IAM: the service that authenticates identities and authorizes access to AWS resources. | Entra ID: the cloud identity directory (users, groups, apps, sign-in). Azure RBAC is the separate system that authorizes access to Azure resources. | Google Cloud IAM: authorizes access to Google Cloud resources. Human identities come from Google Accounts, Cloud Identity or Workspace. |
| Permission model | JSON policy documents with Allow/Deny, actions, resources and conditions, attached to identities or resources. | Role assignments: principal + role + scope. Access is additive across assignments. | Allow policies binding principal + role + resource. A role is a bundle of permissions. |
| Hierarchy and inheritance | Organization, organizational units, accounts. Service control policies cap what accounts can do; permissions are not inherited downward the way roles are in GCP and Azure. | Tenant, management groups, subscriptions, resource groups, resources. Role assignments inherit downward. | Organization, folders, projects, resources. Allow policies inherit downward. |
| Explicit deny | Yes. An explicit Deny always overrides any Allow. | Not something you write in normal RBAC; you limit access by scope and role choice. | Supported through deny policies, evaluated before allow policies. |
| Machine identity | IAM roles (instance profiles for EC2, execution roles for Lambda) issuing temporary credentials through STS. | Managed identities (system-assigned or user-assigned) and service principals. | Service accounts, attached to VMs, Cloud Run and Cloud Functions, or impersonated by other principals. |
| Avoiding long-lived keys | Prefer roles and temporary credentials over IAM user access keys. | Prefer managed identities or federated credentials over client secrets. | Avoid service account keys; use attached service accounts, impersonation or Workload Identity Federation. |
| Sign-in controls | MFA, and policy conditions (for example require MFA or restrict by IP). Workforce SSO via IAM Identity Center. | Conditional Access (require MFA, block locations, require compliant devices, risk-based rules). | 2-Step Verification and context-aware access through Google identity products. |
How do machine identities work in each cloud?
Workloads should never carry a password. Each cloud gives a running service its own identity and hands it short-lived credentials:
- AWS: attach an IAM role to an EC2 instance or Lambda function, and the SDK picks up temporary credentials automatically.
- Azure: give the app a managed identity, then grant it an RBAC role such as Storage Blob Data Reader on the storage account.
- Google Cloud: attach a service account to the VM or Cloud Run service and grant it only the roles it needs.
For CI/CD such as GitHub Actions, all three support federation over OIDC so the pipeline needs no stored secret.
Which should you learn for your certification?
- AWS Cloud Practitioner and Solutions Architect Associate: IAM users, roles, policies and least privilege.
- AZ-900 and AZ-104: Entra ID, Azure RBAC, Conditional Access and managed identities.
- Google Cloud Associate Cloud Engineer: IAM roles, service accounts and the resource hierarchy.
Go deeper on each
Frequently asked questions
Is Azure Entra ID the same as AWS IAM?
No. Entra ID is an identity directory and sign-in service (users, groups, single sign-on, MFA, Conditional Access). The closest match to AWS IAM permissions is Azure RBAC, which controls what an identity can do to Azure resources. AWS IAM combines both jobs in one service.
What is the Google Cloud equivalent of an AWS IAM role?
A service account. Like an IAM role, it is an identity for workloads such as VMs and Cloud Run services that receives short-lived credentials without you managing keys. Another principal can also impersonate it with the right permission.
What is the Azure equivalent of an AWS IAM role?
A managed identity. An Azure service such as App Service or a VM gets an identity, and you grant it an RBAC role on the resources it needs, so no connection strings or keys live in your code.
How does permission inheritance differ between the three clouds?
Google Cloud and Azure both inherit permissions downward through their hierarchies (organization, folders and projects in Google Cloud; management groups, subscriptions and resource groups in Azure). AWS accounts are a hard boundary, with service control policies limiting the maximum permissions inside them.
Which one should I learn first for a cloud certification?
Learn the one your exam covers. AWS Cloud Practitioner and Solutions Architect Associate lean on IAM users, roles and policies. AZ-900 and AZ-104 cover Entra ID, RBAC and managed identities. Google Cloud Associate Cloud Engineer covers IAM roles and service accounts.