Deep Dive into AWS IAM: A Practical Guide to Permission Design and Zero Trust, Compared with GCP IAM and Azure AD / Entra ID

Introduction (Key Takeaways Up Front)

In this guide we’ll walk through AWS Identity and Access Management (IAM) and compare it with GCP IAM (Cloud IAM) and Azure AD / Microsoft Entra ID + Azure RBAC to build a solid mental model for “users, permissions, and authentication in the cloud”.

Here’s the one-sentence summary:

• AWS – A JSON-based authorization engine combining IAM users, roles, policies, and SCPs.
• GCP – A role-based model (Cloud IAM) using principal + role + resource plus Org Policy for guardrails.
• Azure – Entra ID for identity, with Azure RBAC / Azure Policy to tightly bind identities to resources.

Across all three, the real game is designing:

1. A clean separation between human users and systems.
2. A role-centric model where you grant temporary permissions via roles, not long-lived keys.
3. Operational rules that preserve least privilege over time.
4. Guardrails at higher levels (organizations, folders, management groups) that assume multi-account / multi-cloud.
5. An architectural stance that moves from “protected networks” to “protected identities” (Zero Trust thinking).

This guide is written for:

• IT / corporate infra teams moving to the cloud
• SaaS / business app developers
• SREs and platform / infra engineers
• Security / governance teams
• Startup tech leads / CTOs

By the end, you should have a reusable “permission design mindset” that starts with AWS IAM but transfers directly to GCP IAM and Azure AD / Entra ID + Azure RBAC.

1. What IAM Actually Does: Roles and Responsibility Boundaries

Loosely translated, IAM is the service where you define “who can do what, on which resource”.

• Who (Principal) – Humans, apps, microservices, batch jobs, other clouds, partners…
• What (Resource) – S3 buckets, EC2 instances, RDS, Lambda, VPC, CloudWatch – any AWS resource.
• How far (Action / Scope) – s3:GetObject only, ec2:Describe* only, deny rds:*, etc., at API action level.

IAM expresses these rules with JSON policies (allow/deny statements) and evaluates them on each request to decide “Allow” or “Deny”.

1.1 Quick Component Mapping

AWS IAM

• Identities: IAM users, IAM roles, IAM groups
• Policies: AWS managed policies, customer managed, inline policies, SCPs, permission boundaries

GCP IAM (Cloud IAM)

• principal (user / service account) + role (attached to principal) + resource

Azure (Entra ID + Azure RBAC)

• Identities: users, service principals, managed identities
• Permissions: roles (built-in / custom) assigned to a scope (subscription / resource group / resource)

In all three clouds, you end up combining:

Principal + Role/Policy + Resource

The syntax differs, but the conceptual model is the same.

2. Separate Humans, Systems, and External Identities

The first step in IAM design is to list “who actually touches the cloud”.

2.1 Human Identities

Typical human persona:

• Administrators (platform / security teams)
• Developers (app engineers, data engineers, ML engineers, etc.)
• Operators (monitoring, NOC / operations teams)
• Executives / auditors (read-only, dashboards, exports)

On AWS, the recommended pattern is not “log in with IAM users”, but rather:

External IdP + IAM roles

Example:

• Manage employees in Entra ID / Okta / Google Workspace
• Use SSO into AWS
• Users then assume IAM roles via console or CLI

Similar flow in each cloud:

• GCP – Users in Cloud Identity / Workspace log in to the console; Cloud IAM roles grant project/folder/org permissions.
• Azure – Users in Entra ID log into the portal; Azure RBAC roles grant access at subscription / resource group / resource scope.

2.2 System Identities

Non-human actors also need identities and permissions:

• Applications (EC2 APIs, ECS/EKS workloads, Lambda functions)
• Batch / ETL jobs
• Clients in other clouds or on-prem talking to AWS
• SaaS platforms accessing your AWS environment

In AWS, these are almost always expressed as IAM roles:

• EC2 – instance profiles (roles)
• ECS/EKS – task or pod roles
• Lambda – execution roles

You bind “which program uses which role” at deployment.

Analogous concepts:

• GCP – service accounts
• Azure – service principals and managed identities

2.3 External Identities (Federation)

External sources of identity include:

• Your corporate IdP
• Partner organizations
• Third-party SaaS

These are federated via SAML / OIDC / web identity federation / IAM Identity Center (AWS SSO) into temporary role credentials:

External identity → STS-issued temporary credentials → IAM role

This eliminates the need for long-lived static secrets on the AWS side.

3. Reading and Writing Policies: Getting Comfortable with JSON

At heart, an IAM policy is:

IF certain conditions are met, THEN Allow / Deny specific actions on specific resources.

3.1 The Simplest Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"]
    }
  ]
}

Key building blocks:

• Effect – Allow or Deny
• Action – API actions (optionally with wildcards like s3:*)
• Resource – ARNs of resources the rule applies to

The mental model for evaluation:

1. Everything starts as “Implicit Deny”.
2. If any applicable policy says Allow, the request becomes potentially allowed.
3. If any policy says Deny, the final result is Deny wins.

GCP IAM:

• You bind roles like roles/storage.objectViewer to a principal on a resource scope (project/folder/org).
• Evaluation is similar: effective permission = union of roles, constrained by org policies / denies.

Azure RBAC:

• You assign roles to identities at scopes (management group / subscription / resource group / resource).
• Denies / policies at higher scopes restrict what can ultimately be allowed.

3.2 Identity Policies, Resource Policies, SCPs, and Permission Boundaries (AWS)

AWS has four policy types, each for a distinct purpose:

1. Identity-based policies

   • Attached to IAM users, roles, or groups.
   • This is what you most often author and review.

2. Resource-based policies

   • Attached directly to resources (S3 bucket policies, SQS queue policies, KMS key policies, etc.).
   • Used heavily for cross-account access and selectively exposing resources.

3. SCP (Service Control Policy)

   • Part of AWS Organizations.
   • Defines a maximum permission boundary for accounts or OUs.
   • E.g. “No iam:* in this OU” or “No use of regions outside eu-west-* in this OU”.
   • Roughly analogous to GCP Org Policy or Azure Policy with management group-level denies.

4. Permission boundaries

   • Per-identity upper limits: “This user/role can never be granted more than X”.

Together they give you multi-layer guardrails:

• Day-to-day permissions – identity-based policies
• How shared resources are exposed – resource policies
• Org-wide security rules – SCPs / org policies
• Per-user hard caps – permission boundaries

4. Practical Design Patterns: Role-Centric, Least Privilege, Temporary Credentials

Let’s look at patterns you’ll actually use.

4.1 Admin, Developer, and Read-Only Roles

Across multiple accounts, standardising role names and permission sets makes operations radically easier.

Typical layout:

• OrganizationAdminRole

  • Very powerful; can manage accounts / org / SCPs.
  • Restricted to a tiny set of people with strict controls.

• PlatformAdminRole

  • Manages shared infra: VPCs, IAM, CloudWatch, security services.

• AppDeveloperRole

  • Manages EC2/ECS/EKS/Lambda/S3/etc. within their project.
  • No IAM / org / billing / security-guardrail powers.

• ReadOnlyRole

  • Organization-wide read-only access for investigation, audit, and troubleshooting.

In GCP, you ideally don’t rely only on roles/owner, roles/editor, roles/viewer. You define custom roles with similar scopes.

In Azure, you likewise go beyond the basic Owner, Contributor, Reader trio and define custom roles per work profile.

4.2 Humans via IdP → Roles, Systems via Roles → Services

Pattern:

• Humans

  • Auth at IdP (Entra ID / Okta / Workspace / etc.).
  • Use AWS IAM Identity Center as your SSO entry point.
  • Users pick / assume roles per account (admin, dev, read-only).

• Systems

  • EC2/ECS/EKS/Lambda configured with execution roles.
  • Code never sees long-lived keys; it uses STS-issued temporary credentials via instance metadata, identity tokens, etc.

The core principle:

Avoid long-lived access keys for individuals and hosts.
Push everything towards temporary, role-based credentials.

That’s fundamental Zero Trust behaviour.

4.3 Example: Read-Only Role Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeAndList",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3ReadOnlyLogs",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-org-logs-*/*"
    }
  ]
}

Attach this to a dedicated audit/investigation role and you have a safe way to inspect infra without risk of accidental changes.

5. IAM in a Multi-Account, Multi-Cloud World

5.1 Multi-Account (AWS Organizations)

In AWS, the standard pattern is:

• Use AWS Organizations to group accounts.
• Use OUs (organizational units) to structure them logically.
• Apply SCPs on OUs.
• Harmonise IAM roles across accounts.

Example OU layout:

• security OU – central logging account, security tooling accounts.
• shared-services OU – shared VPC, IAM Identity Center, etc.
• workloads OU – prod / staging / dev accounts for applications.

GCP’s equivalent is Organization → Folder → Project.
Azure’s is Tenant (Entra ID) → Management Group → Subscription → Resource Group.

5.2 Identity Strategy for Multi-Cloud

Goal: one source of truth for human identities (e.g., Entra ID).

Pattern:

• Put all human identities in one IdP.
• Each cloud trusts that IdP and maps IdP groups/claims to roles/role assignments.
• MFA, password policies, conditional access, and lifecycle (joiners/movers/leavers) live in the IdP.

Benefits:

• For onboarding / offboarding, IdP changes immediately propagate to all clouds.
• Governance, audit, and certification can all point to one place as the identity source.

6. Zero Trust and IAM: Protecting by “Who” Rather Than “Where”

Legacy thinking: “Inside the network is safe, outside is dangerous.”

Zero Trust thinking:

1. There is no fully “inside” – treat every request as untrusted.
2. For every access, verify who is asking, for what resource, under what conditions.
3. Default to least privilege, short-lived tokens, and MFA.
4. Centralize and monitor logs to detect and respond to abnormal behaviour quickly.

AWS IAM supports this model through:

• IAM roles + STS tokens (short-lived)
• IAM Identity Center integrated with IdPs
• Policy conditions (e.g. aws:MultiFactorAuthPresent == true)

You can write policies like:

“Allow this high-risk operation only when the request is MFA-authenticated and comes from specific device or network conditions.”

GCP and Azure support similar approaches, combining IAM roles with conditional access, device posture, and other signals.

7. How Operations Actually Make or Break IAM

7.1 House Rules That Scale

Concrete rules you can adopt as standards:

• Never give human users AWS access keys by default.
• If you must issue access keys, document issuance and rotation policies (expiry, rotation frequency, storage).
• Admin roles must require MFA and have short session durations.
• Minimise use of the built-in AdministratorAccess managed policy; reserve it for a small number of tightly controlled roles.
• For each project, provide a standard trio of roles: Ops, Dev, Read-only.
• Split IAM policies by service / function (e.g. S3-only policies, EC2-only policies) rather than one giant catch-all.

7.2 Design Checklist (Things to Decide in the First Week)

1. Source of truth for identities – Entra ID / Google Workspace / on-prem AD / etc.
2. Account structure – AWS Organizations / GCP org structure / Azure management groups and subscriptions.
3. Naming conventions – for roles and policies, e.g. {org}-{env}-{role-purpose}.
4. Standard role sets – Admin / Developer / Read-only / Automation / Audit.
5. Long-lived secret management – policies for access keys, service account keys, client secrets.
6. MFA and password policies – who must have MFA, at what assurance level.
7. Org guardrails – SCPs, GCP Org Policies, Azure Policies.
8. Audit logs – CloudTrail, Cloud Logging, Azure Activity Logs aggregation, retention, and alerting.
9. Access review cadence – periodic (e.g., quarterly) review of roles and memberships.
10. Runbooks – how to respond to access errors, how to grant and revoke emergency elevated access.

8. Case Studies: Three Common Real-World Scenarios

8.1 Small Startup, Mostly AWS

Context

• Small team, AWS is primary; some GCP/Azure use starting to appear.

Actions

• Choose Entra ID or Google Workspace as IdP; SSO into AWS via IAM Identity Center.
• Define just three roles in AWS: Admin / Dev / ReadOnly.
• Allow long-lived access keys only for CI or specific integrations, stored in Secrets Manager.

Outcome

• When people join or leave, you change the IdP and their access to all clouds adjusts automatically.
• You get a lean but safe permission design that supports future growth.

8.2 Large Enterprise, Many Accounts

Context

• Multiple departments, many AWS accounts, GCP and Azure also used per division.

Actions

• Use AWS Organizations with OUs for security, shared-services, workloads.
• Apply SCPs to enforce “no root logins”, “don’t stop CloudTrail”, “only approved regions” etc.
• Centralise identity in Entra ID and connect GCP, Azure, and AWS for SSO.

Outcome

• Each department can move at its own pace while global rules and monitoring still apply.
• Incident response and forensics can answer “who did what, where, and when” across clouds.

8.3 Multi-Tenant SaaS on AWS

Context

• A SaaS platform hosts multiple tenants in a single AWS account.

Actions

• Do not create an IAM role per tenant – that doesn’t scale.
• Implement tenant-level access control in the application using tenant IDs.
• Give the app a minimal IAM role limited to its S3 prefixes, tables, queues, etc.

Outcome

• IAM stays relatively simple; tenant isolation is enforced at the app layer.
• When you expand to GCP/Azure, you can reuse the same app-level tenancy model.

9. Target Outcomes by Reader Type

9.1 IT / Governance / Corporate Infra

Goal

• A unified identity platform that manages employees, contractors, and partners under consistent policies across clouds.

What you gain here

• A cross-cloud understanding of AWS IAM, GCP IAM, and Azure RBAC.
• Concrete guidance on what should be governed centrally vs what can be delegated.

9.2 App Developers, SREs, Infra Engineers

Goal

• When you launch a new service, you instinctively start from role design, not “just give me admin”.

What you gain here

• The pattern “Humans via IdP + roles; systems via roles + temporary credentials”.
• Policy examples you can adapt directly to your own project.

9.3 Security and Audit Teams

Goal

• Be able to confidently answer “Who had what, when, and where?” for any incident.

What you gain here

• An overview of SCPs, permission boundaries, logs, and access reviews.
• A path towards Zero Trust / Zero Standing Privilege (no one holds permanent admin power).

9.4 Startup CTOs and Tech Leads

Goal

• Even with a tiny team, set up “grown-up” access control from day one so it doesn’t collapse at scale.

What you gain here

• A minimalist but robust starter kit:
  • Standard roles
  • IdP-based SSO
  • MFA
  • Central logs
  • Org-level guardrails

10. Three Things You Can Do Today

1. List all “human” and “system” identities

   • Admins, devs, operators, batch jobs, apps, external SaaS, etc.

2. Declare the principle:

   • Humans = IdP + role
   • Systems = role only
   • Phase out handing out access keys where possible.

3. Define a minimal set of standard roles

   • Start with Admin / Developer / ReadOnly.
   • Implement them as custom policies and share the definitions with your team.

11. Conclusion: IAM Is the Foundation Underneath Every Cloud Service

IAM might look “unexciting” in the service list, but in reality it underpins every other AWS service:

• S3 / EC2 / RDS / Lambda
• VPC / CloudFront
• CloudWatch / Security tools
• And everything else you spin up.

Designing “Who, What, How far” carefully means:

• Human identities are centralised in the IdP, permissions granted via roles.
• Systems receive only roles and temporary credentials.
• Org-level guardrails (SCP/Policy) restrict what’s possible even if someone misconfigures a role.
• Logs and periodic reviews form an ongoing health check for your permissions.

Once you have this loop in place, your cloud can grow in scale and across providers while your mental model stays the same.

In upcoming topics, you’d naturally move on to closely related services like AWS Organizations (account management and SCPs) or more app-centric layers like Amazon ECS/EKS – again comparing them with GCP (GKE/Cloud Run) and Azure (AKS/App Service).

Step by step, you’ll be building not just individual services, but a resilient, secure cloud foundation that’s much harder to break accidentally.