All Bridges/Azure to AWS Data Engineering Bridge/Security, IAM & Identity Governance
AZUREAWS Deep Dive
Security, IAM & Identity Governance

Microsoft Entra ID (Azure AD) & Azure RBAC AWS Identity and Access Management (IAM)

From Microsoft Entra ID & Managed Identities to AWS IAM Roles & Instance Profiles.

The 30-Second Mental Model Shift

In Azure, identity is centralized in Microsoft Entra ID, and permissions inherit hierarchically from Subscription down to Resource Group. In AWS, every AWS Account is an independent security boundary. Applications running in AWS do not use passwords; they assume an IAM Role with an attached JSON policy via AWS STS (Security Token Service). In AWS SDKs, the Boto3 credential chain automatically resolves credentials in order (Environment ➔ ~/.aws/credentials ➔ IAM Instance Profile), exactly like `DefaultAzureCredential()` in Azure!

1. Architectural Mechanism Comparison

AZURE (What You Know)
Source

Microsoft Entra ID (Azure AD) & Azure RBAC

Centralized tenant-based identity provider. RBAC roles (e.g. Storage Blob Data Contributor) are assigned at Management Group, Subscription, or Resource Group scopes. Managed Identities provide passwordless VM authentication.

Key Architecture Strengths:
  • System-Assigned & User-Assigned Managed Identities eliminate long-lived passwords.
  • Hierarchical scope inheritance: Root Tenant ➔ Subscription ➔ Resource Group ➔ Resource.
  • Unified enterprise Single Sign-On (SSO) integrated with Microsoft 365.
AWS (How It Works)
Mastery Target

AWS Identity and Access Management (IAM)

Account-centric authorization engine using JSON policy documents (`Effect`, `Action`, `Resource`, `Condition`). IAM Roles are assumed by EC2 instance profiles, ECS tasks, and Lambda functions via AWS STS temporary tokens.

Why AWS Built It This Way:
  • IAM Roles & Instance Profiles: Issue short-lived, auto-rotating 1-hour credentials via AWS Security Token Service (STS).
  • Fine-grained ABAC (Attribute-Based Access Control) using request tags (`aws:PrincipalTag`).
  • Service Control Policies (SCPs) in AWS Organizations enforce guardrails across hundreds of AWS accounts.

2. Interactive Terminology & Concept Bridge

Interactive Concept Bridge: Terminology & Architectural Mapping

Click any concept below to see how your AZURE knowledge directly maps into AWS.

Mapping Deep Dive
Similar Mechanism
⚡ Direct cognitive shortcut
AZURE (What You Know)

Microsoft Entra ID (Azure AD) Tenant

Global enterprise directory containing users, groups, and application registrations.

AWS (How It Works)

AWS Account / AWS Organizations

Root resource and administrative isolation boundary in AWS.

The Architectural Mental Shortcut:

In Azure, multiple subscriptions live under one Entra ID tenant. In AWS, enterprises manage multiple AWS Accounts under AWS Organizations.

3. Visual Architecture Pipeline (AWS Identity and Access Management (IAM))

IAM Mental Model: Policy = Principal (“Who”) + Role (“What”) + Resource (“Where”)

Click any section below or run the simulation to see how Google Cloud evaluates IAM policy bindings.

1. Principal (“Who”)
Bind
2. Role (“What”)
Apply
3. Resource (“Where”)
💡 Analogy: Like a job title or access pass (e.g. 'Warehouse Inspector Pass') that lists exactly which doors you are permitted to open.
Authorization
Component Inspector

2. The Role ('WHAT' they can do)

Predefined & Custom Roles (Collections of Exact Permissions)

A Role is a collection of fine-grained permissions (e.g. `storage.objects.get`, `bigquery.jobs.create`). Predefined roles are curated by Google, while Custom roles provide surgical least-privilege control.

Under the Hood:
  • Predefined roles (e.g. `roles/bigquery.dataViewer`) maintained and updated automatically by Google.
  • Custom roles let you bundle exact permissions to enforce strict least-privilege compliance.
  • Primitive roles (`Owner`, `Editor`, `Viewer`) are legacy anti-patterns to avoid in production.
Key Benchmark Metrics:
Role Types
Predefined & Custom
Least-privilege
Primitive Roles
Avoid in Prod
Overly broad

4. Side-by-Side Code, CLI & Terraform Translator

Side-by-Side Code & Syntax Translator

AZURE Syntax
// Azure RBAC Role Assignment via Azure CLI
// az role assignment create \
//   --assignee "sp-etl-app" \
//   --role "Storage Blob Data Contributor" \
//   --scope "/subscriptions/.../storageAccounts/adlsgen2lakehouse"
AWS Equivalent
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3LakehouseReadWrite",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-company-curated-lakehouse-2026",
        "arn:aws:s3:::my-company-curated-lakehouse-2026/*"
      ]
    }
  ]
}
Code Translation Notes:In Azure, you bind built-in RBAC roles; in AWS, you author fine-grained JSON policy documents specifying exact S3 actions and ARNs.

5. Paradigm Shift Gotchas: Traps to Avoid in AWS

Gotcha #1
high

The S3 Bucket ARN Missing Slash Trap (`arn:aws:s3:::bucket/*`)

The Trap:

In AWS IAM, `arn:aws:s3:::mybucket` applies to the bucket itself (`s3:ListBucket`), while `arn:aws:s3:::mybucket/*` applies to the objects inside (`s3:GetObject`). Omitting `/*` causes mysterious Access Denied errors when reading files.

How to Avoid It:

Always include BOTH the bucket ARN and the wildcard child ARN in your IAM policy Resource array.

Gotcha #2
high

Explicit Deny Overrides All Allows

The Trap:

In AWS IAM evaluation, an explicit Deny ALWAYS wins over any Allow statement across IAM policies, resource policies, permission boundaries, and SCPs.

How to Avoid It:

Use Deny statements sparingly, and always test policies using the AWS IAM Policy Simulator.

6. Test Your Mental Model

Quick Knowledge Check: Test Your AWS Mental Model

Solidify your cross-cloud understanding with instant feedback.

1What is the AWS equivalent of an Azure System-Assigned Managed Identity?
2In an AWS IAM policy for S3, why must you specify both `arn:aws:s3:::mybucket` AND `arn:aws:s3:::mybucket/*`?