AWS IAM in Detail: Users, Roles, Policies, Federation, SCPs, and Permission Boundaries

Who is allowed to perform what action on which AWS resource, and under what conditions?

IAM can appear complicated because AWS provides several overlapping authorization mechanisms:
users, groups, roles, identity policies, resource policies, permissions boundaries, Service Control
Policies, trust policies, federation, and temporary credentials.

The easiest way to understand IAM is to begin with the basic authorization flow.

Identity
   |
   v
Authentication
   |
   v
Authorization
   |
   v
AWS Resource

When an AWS API request occurs, AWS evaluates the principal making the request, the requested
action, the target resource, applicable policies, and the context surrounding the request.

1. The Basic AWS IAM Model

Consider an application running on an EC2 instance that needs to read an object from an S3 bucket.

Application
    |
    v
EC2 Instance
    |
    | assumes
    v
IAM Role
    |
    | permissions policy
    v
Allow: s3:GetObject
    |
    v
S3 Bucket

The core concepts involved are:

2. IAM Users

An IAM user is a persistent identity created within an AWS account.

AWS Account
|
|-- IAM User: Alice
|-- IAM User: Bob
|-- IAM User: AutomationUser

An IAM user may have:

• A console password
• Access keys
• Permissions assigned through policies
• Membership in IAM groups

Historically, companies commonly created an IAM user for every employee.
Modern AWS security architecture generally favors federated identities and temporary
credentials instead.

Employee
   |
   v
Corporate Identity Provider
   |
   | SAML / Federation
   v
IAM Identity Center
   |
   v
AWS Account
   |
   v
IAM Role

This reduces the number of long-lived AWS credentials that an organization must manage.

3. IAM Groups

An IAM group is simply a collection of IAM users.

Developers Group
      |
      |-- Alice
      |-- Bob
      |-- Charlie

Policies can be attached to the group so that all members inherit those permissions.

Developers
    |
    v
DeveloperPolicy
    |
    |-- S3 Read
    |-- CloudWatch Read
    |-- Lambda Deployment

One important distinction is:

Roles can be assumed. Groups cannot.

Groups are primarily an administrative mechanism for managing IAM users.

4. IAM Roles

IAM roles are among the most important concepts in AWS security architecture.

A role is an AWS identity with permissions but normally without long-term credentials.
Instead, another principal assumes the role and receives temporary credentials.

Principal
    |
    | AssumeRole
    v
IAM Role
    |
    v
AWS STS
    |
    v
Temporary Credentials

AWS Security Token Service (STS) can return credentials containing:

• Access Key ID
• Secret Access Key
• Session Token
• Expiration time

Roles can be assumed by many different types of principals.

IAM Role
   ^
   |
   |-- IAM User
   |-- EC2
   |-- Lambda
   |-- ECS Task
   |-- Another AWS Account
   |-- Federated User
   |-- OIDC Identity
   |-- SAML Identity

5. Trust Policies vs. Permissions Policies

An IAM role has two very different authorization concepts.

Trust Policy

A trust policy answers:

Who is allowed to assume this role?

For example:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "ec2.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
  }]
}

This tells AWS that EC2 is trusted to assume the role.

Permissions Policy

The permissions policy answers:

What can the role do after it has been assumed?

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

Together:

EC2
 |
 | allowed by Trust Policy
 v
IAM Role
 |
 | allowed by Permissions Policy
 v
S3

6. IAM Policies

IAM policies are JSON documents that describe permissions.

A typical policy statement contains:

Effect
   +
Action
   +
Resource
   +
Condition (optional)

For example:

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

7. Allow, Deny, and Implicit Deny

IAM policy statements use two Effect values:

• Allow
• Deny

AWS begins with the concept of implicit deny.
If no applicable policy allows the action, the request is denied.

Implicit Deny
     |
     v
Explicit Allow?
     |
    Yes
     |
     v
Potentially Allowed
     |
     v
Explicit Deny?
  /       \
Yes       No
 |         |
DENY     ALLOW

An applicable explicit Deny generally overrides an Allow.

8. IAM Actions

An IAM action corresponds to an AWS API operation.

Examples include:

s3:GetObject
s3:PutObject

ec2:StartInstances
ec2:StopInstances

kms:Decrypt

secretsmanager:GetSecretValue

lambda:InvokeFunction

Wildcards are possible:

"Action": "s3:*"

This allows every S3 action covered by the policy.

An even broader permission is:

"Action": "*"

This should be used cautiously because it can dramatically increase the blast radius of a compromised identity.

9. Resources and ARNs

AWS policies identify resources through Amazon Resource Names (ARNs).

For example:

arn:aws:s3:::financial-data

An object inside that bucket might be:

arn:aws:s3:::financial-data/reports/report.pdf

A policy can therefore restrict access to a specific path:

"Resource": "arn:aws:s3:::financial-data/reports/*"

This enables very granular authorization.

10. IAM Conditions

Conditions make IAM policies significantly more powerful.

Instead of simply saying:

Alice may access S3.

you can create a policy that effectively says:

Alice may access S3 only when certain security conditions are satisfied.

Allow s3:GetObject

IF

MFA = true
AND
Source network = approved
AND
Resource tag = Production

IAM conditions can evaluate attributes such as:

• Source IP address
• VPC
• VPC endpoint
• MFA state
• Principal ARN
• Principal tags
• Resource tags
• AWS Region
• AWS Organization ID
• TLS usage
• Request tags

This makes IAM an important component of Zero Trust architecture.

11. Identity-Based Policies

Identity-based policies are attached to:

• IAM users
• IAM groups
• IAM roles

IAM Role
   |
   v
Identity Policy
   |
   v
Allow s3:GetObject

The policy tells AWS what actions that identity is allowed to perform.

12. Resource-Based Policies

Some AWS resources support policies attached directly to the resource.

Examples include:

• S3 bucket policies
• KMS key policies
• SQS queue policies
• SNS topic policies
• Secrets Manager resource policies
• API Gateway resource policies

IAM Role
    |
    v
S3 Bucket
    |
    v
Bucket Policy

Resource-based policies are particularly important for cross-account architectures.

13. Identity Policy vs. Resource Policy

Suppose an application in Account A needs to access an S3 bucket in Account B.

Account A                         Account B

Application
    |
    v
IAM Role  ---------------------> S3 Bucket
    |                               |
Identity Policy                 Bucket Policy

The role may have permission to call:

s3:GetObject

while the bucket policy permits a specific principal:

arn:aws:iam::111111111111:role/AppRole

The identity policy represents authorization from the caller side, while the resource policy
represents authorization from the resource side.

14. AWS-Managed and Customer-Managed Policies

AWS-Managed Policies

AWS creates and maintains these policies.

Examples include:

ReadOnlyAccess
AmazonS3ReadOnlyAccess

They are convenient but may occasionally be broader than a particular workload requires.

Customer-Managed Policies

Customer-managed policies are created and maintained by your organization.

For example:

ProductionS3InvoiceReadOnly

These policies can be designed specifically around least-privilege requirements.

15. Inline Policies

An inline policy is embedded directly inside a single IAM user, group, or role.

IAM Role
   |
   |-- Managed Policy
   |
   |-- Inline Policy

Inline policies have a one-to-one relationship with the identity.
Managed policies are usually easier to centrally maintain and reuse.

16. Permissions Boundaries

Permissions boundaries are frequently misunderstood.

A permissions boundary does not grant permissions.
Instead, it establishes the maximum identity-based permissions an IAM user or role may receive.

Suppose a role policy says:

Allow:

s3:*
ec2:*
lambda:*

but its permissions boundary only permits:

s3:*
lambda:*

The EC2 permissions are outside the boundary and therefore cannot be exercised through those identity-based permissions.

Identity Policy
      |
      v
Permissions Requested
      |
      intersect
      |
Permissions Boundary
      |
      v
Effective Maximum

Permissions boundaries are particularly useful when delegating IAM administration.

For example, developers may be allowed to create IAM roles while a required permissions boundary
ensures that those roles can never obtain unrestricted administrative permissions.

17. Service Control Policies (SCPs)

AWS Organizations provides another major authorization layer called Service Control Policies.

AWS Organization
      |
      v
Organizational Unit
      |
      v
SCP
      |
      v
AWS Account
      |
      v
IAM Roles

SCPs define organization-level permission guardrails.

For example, an SCP may prevent accounts from:

• Disabling CloudTrail
• Leaving the AWS Organization
• Using unsupported AWS Regions
• Changing security services

Even if a role inside the account has:

AdministratorAccess

an applicable explicit Deny in an SCP can still block the operation.

18. Identity Policies, Permissions Boundaries, and SCPs

Conceptually:

AWS Organization
      |
      v
     SCP
      |
      v
AWS Account
      |
      v
Permissions Boundary
      |
      v
IAM Role
      |
      v
Identity Policy
      |
      v
AWS Resource

Resource policies, trust policies, and explicit Deny statements introduce additional evaluation layers.

19. AWS STS and Temporary Credentials

AWS Security Token Service is fundamental to role-based security.

User / Application
       |
       | AssumeRole
       v
      STS
       |
       v
Temporary Credentials
       |
       v
AWS APIs

For example:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/ProductionReadRole \
  --role-session-name audit-session

STS returns temporary credentials that expire automatically.

This is significantly preferable to distributing long-lived access keys across servers and applications.

20. EC2 IAM Roles

Applications running on EC2 should generally not store AWS access keys in files or environment variables.

Avoid:

EC2
 |
 |-- access-key.txt

Prefer:

EC2
 |
 v
Instance Profile
 |
 v
IAM Role
 |
 v
Temporary Credentials
 |
 v
AWS APIs

AWS SDKs can automatically obtain and refresh the temporary credentials associated with the role.

21. Lambda Execution Roles

AWS Lambda uses the same principle.

Lambda Function
       |
       v
Execution Role
       |
       |-- CloudWatch Logs
       |-- DynamoDB
       |-- S3
       |-- Secrets Manager

The Lambda role should contain only the permissions actually required by the function.

For example:

secretsmanager:GetSecretValue
dynamodb:PutItem
logs:CreateLogStream
logs:PutLogEvents

rather than attaching unrestricted administrative permissions.

22. Cross-Account Access

IAM roles are the standard mechanism for cross-account AWS access.

Security Account
111111111111

       |
       | AssumeRole
       v

Production Account
222222222222
       |
       v
SecurityAuditRole

The role in the Production account contains a trust policy allowing a principal from the Security
account to assume it.

This pattern is common in enterprise multi-account architectures with accounts such as:

• Security
• Networking
• Logging
• Shared Services
• Development
• Testing
• Production

23. IAM Federation

Large enterprises generally avoid maintaining IAM users for every employee.
Instead, users authenticate through an enterprise identity provider.

Employee
    |
    v
Enterprise Identity Provider
    |
    |-- Microsoft Entra ID
    |-- Okta
    |-- Other IdP
    |
    v
IAM Identity Center
    |
    v
Permission Set
    |
    v
AWS Account / IAM Role

Federation enables centralized controls such as:

• Multi-factor authentication
• Employee onboarding
• Employee termination
• Conditional access
• Centralized password policies
• Group-based access assignments

24. AWS IAM Identity Center

AWS IAM Identity Center, formerly known as AWS Single Sign-On, provides centralized workforce
access across AWS accounts.

Microsoft Entra ID
       |
       v
IAM Identity Center
       |
       |-- Developers
       |-- Security
       |-- Administrators
              |
              v
        Permission Sets
              |
        +-----+-----+
        |     |     |
        v     v     v
       DEV   TEST  PROD

Common permission sets may include:

• DeveloperAccess
• SecurityAudit
• DatabaseAdmin
• ProductionReadOnly

This model works particularly well with AWS Organizations and multi-account landing zones.

25. How AWS Evaluates an IAM Request

When an AWS request occurs, AWS evaluates multiple authorization layers.

              API Request
                   |
                   v
          Authentication Valid?
                   |
                   v
          Applicable Policies
                   |
        +----------+----------+
        |          |          |
        v          v          v
    Identity    Resource      SCP
    Policies    Policies
        |
        +---- Permissions Boundary
        |
        v
      Evaluate
        |
        v
   Explicit Deny?
     /       \
   Yes       No
    |         |
   DENY       v
        Sufficient Allow?
           /       \
         Yes       No
          |         |
        ALLOW      DENY

The exact IAM policy evaluation process has important nuances, particularly when cross-account
access, resource policies, role sessions, and permissions boundaries are involved.

However, the essential rule remains:

An applicable explicit Deny wins.

26. IAM and AWS KMS

AWS Key Management Service adds another important authorization layer.

For encrypted resources you frequently need permission to access both the resource and the encryption key.

Application
     |
     v
IAM Role
     |
     |-- s3:GetObject
     |
     |-- kms:Decrypt
             |
             v
           KMS Key

For example, a user may successfully retrieve an encrypted S3 object but still be unable to
decrypt the object because the user or role cannot use the relevant KMS key.

KMS key policies therefore deserve special attention in AWS security architectures.

27. Attribute-Based Access Control (ABAC)

AWS IAM supports tag-based authorization through Attribute-Based Access Control.

Instead of creating separate policies for every department:

FinanceUserPolicy
HRUserPolicy
EngineeringUserPolicy
MarketingUserPolicy

you can use principal and resource attributes.

For example:

Principal Tag:

Department = Finance

and:

Resource Tag:

Department = Finance

The authorization policy can then conceptually state:

Allow access when:

Principal.Department
        =
Resource.Department

ABAC can significantly reduce the number of static IAM policies required in large environments.

28. RBAC vs. ABAC

Traditional IAM architectures often rely heavily on Role-Based Access Control.

User
 |
 v
Finance Role
 |
 v
Finance Resources

ABAC makes authorization decisions based on attributes instead.

User
Department=Finance
      |
      v
Policy Evaluation
      |
      v
Resource
Department=Finance

Many mature cloud architectures combine RBAC and ABAC.

29. A Typical Enterprise AWS IAM Architecture

A large AWS organization may implement IAM roughly as follows:

                    Corporate Identity
                           |
                           v
                 IAM Identity Center
                           |
                           v
                    Permission Sets
                           |
                           v
                   AWS Organizations
                           |
                           v
                          SCPs
                           |
              +------------+------------+
              |            |            |
              v            v            v
             DEV          TEST         PROD
              |            |            |
              v            v            v
          IAM Roles     IAM Roles     IAM Roles
              |
              v
       Permissions Boundaries
              |
              v
         IAM Policies
              |
              v
       Resource Policies
              |
              v
         AWS Resources

This should normally be surrounded by security monitoring and governance services such as:

• AWS CloudTrail
• AWS Config
• IAM Access Analyzer
• AWS Security Hub
• Amazon GuardDuty
• AWS Organizations
• AWS Control Tower

30. AWS IAM Security Best Practices

Use Federation for Human Users

Avoid creating hundreds of permanent IAM users when enterprise federation through an identity
provider and IAM Identity Center can provide temporary access.

Use IAM Roles for Workloads

EC2, Lambda, ECS, EKS, and applications should generally use temporary role-based credentials
instead of embedded access keys.

Apply Least Privilege

Avoid policies such as:

"Action": "*",
"Resource": "*"

unless they are genuinely required.

Use SCPs as Enterprise Guardrails

SCPs can prevent entire classes of risky behavior across AWS Organizations.

Use Permissions Boundaries for Delegated IAM Administration

They help prevent administrators or developers from accidentally creating identities with more
permissions than intended.

Use Resource Policies Carefully

Resource-based policies are especially powerful in cross-account architectures and therefore
deserve careful review.

Use IAM Conditions

Conditions involving MFA, AWS Organizations, tags, VPC endpoints, networks, and other context can
dramatically reduce unnecessary access.

Continuously Review Permissions

IAM should not be considered a one-time configuration exercise.
Permissions should continuously be reviewed against actual usage and business requirements.

A Simple Way to Remember AWS IAM

A useful mental model is to think of IAM as five questions.

1. WHO ARE YOU?

   User
   Role
   Federated Identity

          |
          v

2. CAN YOU BECOME THIS IDENTITY?

   Authentication
   Federation
   Trust Policy

          |
          v

3. WHAT ARE YOU TRYING TO DO?

   AWS Action

          |
          v

4. WHAT ARE YOU TRYING TO DO IT TO?

   AWS Resource

          |
          v

5. ARE YOU ALLOWED?

   Identity Policy
   Resource Policy
   Permissions Boundary
   SCP
   Conditions
   Explicit Deny

Conclusion

AWS IAM becomes much easier to understand once you separate identity, authentication, role
assumption, authorization, and organization-level guardrails.

The most important concepts to understand are:

• IAM users represent long-lived identities.
• IAM groups organize users.
• IAM roles provide assumable identities with temporary credentials.
• Trust policies determine who can assume a role.
• Permissions policies determine what that role can do.
• Resource policies control access from the resource side.
• Permissions boundaries establish maximum identity permissions.
• SCPs establish organization-level guardrails.
• STS provides temporary credentials.
• IAM Identity Center provides centralized workforce access.
• ABAC allows authorization decisions based on attributes and tags.

For cloud and security architects, the next step is understanding how
IAM policies, resource policies, Service Control Policies, permissions boundaries, trust
policies, and KMS key policies interact during AWS policy evaluation.
That is where many of the most interesting—and most difficult—real-world IAM problems occur.