IAM in AWS, Azure, and GCP — An Executive Overview

Identity and Access Management is the cornerstone of cloud security. In on-premises environments, identity was often managed through a single Active Directory domain. In the cloud, each major provider — AWS, Azure, and GCP — implements its own IAM system with distinct terminology, architecture, and capabilities. For executives overseeing multi-cloud or hybrid environments, understanding these differences is essential for informed decision-making and effective risk management.

This lesson provides a comparative overview of IAM across the three major cloud platforms, focusing on what matters for governance, compliance, and security posture rather than implementation details.

How Each Platform Approaches IAM

While all three platforms enforce the principle of granting access through policies attached to identities, the structure and naming conventions differ significantly:

• AWS IAM. AWS uses a flat identity model within each account. Users, groups, and roles are defined per account. Policies are JSON documents that specify allowed or denied actions on specific resources. AWS organisations use Service Control Policies to set guardrails across multiple accounts. Cross-account access is managed through role assumption — an identity in one account temporarily assumes a role in another.
• Azure Active Directory (Entra ID). Azure centralises identity in Entra ID (formerly Azure AD), which serves as the identity provider for all Azure services and Microsoft 365. Role-Based Access Control (RBAC) assigns permissions at the management group, subscription, resource group, or individual resource level. Conditional Access policies add context-aware controls based on device state, location, and risk level.
• Google Cloud IAM. GCP uses a resource hierarchy — organisation, folder, project — where IAM policies are inherited downward. Members (users, groups, service accounts) are granted roles that contain collections of permissions. GCP distinguishes between basic roles, predefined roles, and custom roles, encouraging organisations to move away from broad basic roles toward fine-grained predefined or custom roles.

What Executives Must Prioritise

Regardless of which platform your organisation uses, these IAM principles are universal:

• Least privilege. Every identity — human or machine — should have only the permissions required for its current function. Broad administrative roles should be restricted to emergency use.
• Centralised identity governance. In multi-cloud environments, consider federating identity through a single provider to reduce sprawl and simplify access reviews.
• Regular access reviews. Cloud permissions accumulate over time as projects start and stop. Quarterly access reviews ensure that stale permissions are removed.
• Separation of duties. No single identity should be able to both deploy infrastructure and approve its own changes. Platform-specific mechanisms exist to enforce this in each provider.

Action steps for your organisation:

• Map your current identity architecture across all cloud platforms in use
• Identify any accounts with standing administrative privileges and evaluate whether just-in-time access is feasible
• Establish a quarterly access review cadence that covers all cloud IAM configurations
• Evaluate whether a unified identity provider can simplify governance across multiple platforms