AWS Account stores identities in AWS IAM service that is part of that specific AWS Account.
Azure Subscription does not store identities within a specific subscription. Identities are stored centrally in the Azure Active Directory that can be used as the trusted source of identities by multiple Azure Subscriptions (see below).
All cloud resources (VMs, storage, databases) are deployed within specific Azure Subscriptions and AWS Accounts.
Resource quotas (e.g., total number of VM cores) and billing are managed at the level of Azure Subscription or AWS Account.
Azure Subscriptions provide an additional level of resource organization (similar to a “folder”) within a subscription called Azure Resource Groups.
AWS creates a separate (i.e., siloed) Identity and Access Management (IAM) store for each AWS Account.
Azure AD centrally stores the identities such as users, groups, and service principals. The same Azure AD is used by multiple Azure Subscriptions avoiding identity duplication and silos.
Azure Subscriptions contain Azure RBAC role assignments which connect the identities to a set of permissions (i.e., Azure role definition) at a specific hierarchical scope (i.e., management group, subscription, resource group, or resource).
Provides central identity management that is external to a specific AWS Account or Azure Subscription.
AWS IAM Identity Center is deployed by an AWS Account owner into the master account within AWS Organizations. Internally, it uses AWS IAM capabilities to centralize and automate the process of creating AWS IAM Roles in each of the member accounts in the organization.
Azure AD is not a resource that is deployed within an Azure Subscription. It is a global service that is used as the source of identities by Azure Subscriptions and lives above the subscriptions in the hierarchy of concepts.
AWS IAM Role icon is a “hat” since it represents the fact that the IAM Role can be temporarily assumed — like putting on a different hat.
AWS IAM Role is a type of “identity” that can be temporarily “assumed” by users or can be permanently assigned to “services”.
AWS IAM Role is used extensively in AWS for service-to-service access without storing secrets (Service Role), cross-account access (Delegated Role), and federation like SAML, OIDC, and AWS IAM Identity Center (Federated Role).
AWS IAM Service Role is analogous to Azure Managed Identity which can be assigned to VMs and other Azure resources to avoid explicitly creating and storing Service Principal secrets.
AWS IAM Delegated Role concept is not the directly same in Azure since Azure identities are stored centrally in Azure AD and not only in one specific subscription. This makes it possible to grant access to the same Azure AD user across multiple subscriptions. Access across Azure subscriptions that use separate Azure AD tenants is possible via Azure AD B2B guest accounts or multi-tenant application registrations / service principals.
When using AWS Organizations, there is a special type of policies called “Service Control Policies (SCP)” which are used to assign access to various hierarchy levels of the OUs or member accounts. These SCPs are a mask or filter to other AWS IAM Policy assignments lower in the hierarchy.
Even though the word “Policy” is used in both, AWS IAM Policy is not the same as “Azure Policy”. Azure Policy provides centralized governance and guardrails for cloud resource usage (e.g., which resource types can be created, in which regions, etc.) and is not directly related to Azure RBAC. However, since AWS policy language is expressive and fine-grained, AWS SCPs (Service control policies), can be used to create rules and guardrails that are similar to Azure Policy.