This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

In this article, I try to create a short mapping of key AWS IAM (Identity and Access Management) concepts to similar ones in Microsoft Azure.

If you see things that are wrong or incomplete, please leave a comment with what I should fix.

For a more general AWS and Azure comparison, please refer to the Azure for AWS Professionals document.

Looking for Google Cloud IAM to Azure mapping? Take a look here.

AWS Account

• Similar to Azure Subscription.
• 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 IAM

• Similar to the combination of Azure AD and Azure RBAC (role-based access control).
• 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).

AWS SSO

• Similar to Azure Active Directory (Azure AD).
• Provides central identity management that is external to a specific AWS Account or Azure Subscription.
• AWS SSO 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 Organizations and Organizational Units (OU)

• Similar to the combination of Azure AD and Azure Management Groups.
• Azure Subscriptions are grouped within Azure Management Groups similar to how AWS Organization Units group AWS Accounts.
• In Azure, there is no directly equivalent concept to the “master” or “management account” that is used as the parent account in AWS Organizations.

AWS Account Root User

• Similar to Azure Account Administrator.
• Each AWS Account has a root user with a globally unique name in email format (e.g., admin1@domain.com).
• AWS Account Root User is highly privileged and shouldn’t be used at all for day-to-day operations. Root user creates additional accounts — IAM Users described below — that are used instead.
• By default, the person who creates a new Azure Subscription becomes its administrator and can assign other users access to the subscription using Azure RBAC roles like Owner, Contributor, Reader, etc.

AWS IAM User

• Similar to Azure AD User and Service Principal (Application Registration).
• AWS IAM Users are scoped to one AWS Account (i.e., user id is unique only within that account).
• AWS IAM Users can be either a person (console login using username and password) or an application (access key id and secret).
• Azure AD User is an identity used by people who login using username, password, and ideally also multi-factor authentication (MFA).
• Same Azure AD User can be allowed to access many Azure Subscriptions.
• Azure AD Application Registration is like a “template” for the Service Principal, which is the actual instance of the application identity within a specific Azure AD tenant.
• Usually, Azure AD Service Principal has “secrets” (or certificates) making it similar to an IAM User with Access Key ID and Access Key Secret versus the secret-less IAM Role (described below).

AWS IAM Group

• Similar to Azure AD Group.
• Grouping of multiple identities like users and service principals.
• AWS IAM Group is specific to one AWS Account.
• Azure AD Group can be allowed access to multiple subscriptions.
• For better management, permissions should be assigned to groups instead of individual users.

AWS IAM Role

• Although there is no direct equivalent in Azure, there are two concepts that are similar: Azure User Assigned Managed Identity (although it cannot be assumed by “users” but can only be assigned to “resources”) and Azure AD Workload Identity Federation (i.e., which makes the Service Principal analogous to AWS IAM Federated Role type).
• 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 SSO (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.
• AWS IAM Federated Role concept is analogous to Azure AD Workload Identity Federation.
• Even though the word “Role” is used in both, AWS IAM Role is not the same as Azure RBAC “Role Definition” or “Role Assignment”, which are similar to AWS IAM Policy (described below).

AWS STS (Security Token Service)

• Similar to Azure AD authentication endpoints and Azure Instance Metadata Service identity endpoint.
• AWS STS provides applications with a way to “assume” an AWS IAM Role via API call like AssumeRole.
• AWS STS is used by applications running on AWS EC2 instances to get temporary access token.
• Azure VMs and other resources with an assigned managed identity can get the access token from the Azure Instance Metadata Service identity endpoint.
• Applications can also get the access token from Azure AD using the OAuth2 client_credentials flow using Service Principal credentials or can perform token exchange using a trusted JWT token via Azure AD Workload Identity Federation.

AWS IAM Policy

• Similar to the combination of Azure RBAC “Role Definition” and “Role Assignment”
• Collection of permissions consisting of allowed and not allowed actions assigned to an identity and resource.
• AWS IAM Policy language provides fine-grained control, with support for wildcards, over the Effect (Allow/Deny), Action/NotAction (specific service APIs), Resource, and Condition.
• Azure provides many built-in role definitions, including Owner/Contributor/Reader, and provides ability to define custom roles.
• Azure role definitions are “assigned” to specific identities (i.e., users, groups, or service principals) at a specific scope (i.e., management group, subscription, resource group, or resource).
• Azure role definitions and role assignments do not currently support wildcards.
• Azure Role Assignment Conditions are currently available only for storage data-plane operations, but not for general Azure RBAC on Azure resources.
• 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.

Thank you!

Please leave comments or questions below or on twitter.com/ArsenVlad

Originally published at https://arsenvlad.medium.com/mapping-aws-iam-concepts-to-similar-ones-in-azure-c31ed7906abb on April 1, 2022.