Detailed AWS IAM Reference Guide

Table of Contents
1. Core IAM Concepts
2. IAM Users Deep Dive
3. IAM Groups Management
4. IAM Roles Architecture
5. IAM Policies Comprehensive Guide
6. Security Best Practices
7. Advanced IAM Features
8. Troubleshooting and Debugging
9. Real-World Implementation Patterns
10. Cost Optimization and Limits
Core IAM Concepts
The IAM Security Model
AWS IAM operates on a default deny principle. Every action is denied unless explicitly allowed by a
policy. This creates a secure-by-default environment where permissions must be intentionally granted.
Principal Types in AWS
Root User: The AWS account owner (avoid for daily operations)
IAM Users: Permanent identities for people or applications
IAM Roles: Temporary identities that can be assumed
Federated Users: External identities from identity providers
AWS Services: Services acting on behalf of users
Authentication Methods
Username/Password: Console access with optional MFA
Access Keys: Programmatic access (Access Key ID + Secret Access Key)
Temporary Credentials: Short-term access via STS
Multi-Factor Authentication: Additional security layer
 Single Sign-On: Integration with external identity providers
IAM Users Deep Dive
User Lifecycle Management
Creating Users
bash
# Create user
aws iam create-user --user-name john.doe --path /engineering/
# Add user to group
aws iam add-user-to-group --user-name john.doe --group-name developers
# Create login profile for console access
aws iam create-login-profile --user-name john.doe --password TempPassword123! --password-reset-required

User Categories and Naming Conventions

Human Users: firstname.lastname or flastname
Service Users: service-environment-purpose (e.g., app-prod-s3access )
Cross-Account Users: external-company-purpose
Emergency Users: breakglass-role-description
Access Key Management
bash
# Create access key
aws iam create-access-key --user-name john.doe
# List access keys
aws iam list-access-keys --user-name john.doe
# Rotate access keys (deactivate old, create new)
aws iam update-access-key --user-name john.doe --access-key-id AKIAEXAMPLE --status Inactive

User Security Configuration

Multi-Factor Authentication Setup
 bash
# Create virtual MFA device
aws iam create-virtual-mfa-device --virtual-mfa-device-name john.doe-mfa --outfile QRCode.png --bootstrap-m
# Enable MFA device
aws iam enable-mfa-device --user-name john.doe --serial-number arn:aws:iam::123456789012:mfa/john.doe-mf

Password Policy Enforcement

json
{
"MinimumPasswordLength": 14,
"RequireSymbols": true,
"RequireNumbers": true,
"RequireUppercaseCharacters": true,
"RequireLowercaseCharacters": true,
"AllowUsersToChangePassword": true,
"MaxPasswordAge": 90,
"PasswordReusePrevention": 5,
"HardExpiry": false
}

IAM Groups Management

Group Strategy and Design
Functional Groups
Developers - Development environment access
DevOps - Infrastructure and deployment permissions
DataScientists - Analytics and ML service access
Auditors - Read-only access across environments
Administrators - Full administrative access
Environment-Based Groups
Production-ReadOnly - View production resources
Staging-FullAccess - Complete staging environment control
 Development-PowerUser - Development with billing restrictions
Project-Based Groups
Project-Alpha-Team - Specific project resource access
Client-Beta-Access - Client-specific isolated permissions
Group Policy Attachment Strategies
Layered Permission Model
bash
# Base permissions for all developers
aws iam attach-group-policy --group-name Developers --policy-arn arn:aws:iam::aws:policy/IAMReadOnlyAccess
# Environment-specific permissions
aws iam attach-group-policy --group-name Dev-Environment --policy-arn arn:aws:iam::123456789012:policy/De
# Service-specific permissions
aws iam attach-group-policy --group-name S3-Users --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess

IAM Roles Architecture

Role Types and Use Cases
Service Roles
EC2 Instance Roles
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Lambda Execution Roles
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Cross-Account Roles
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/ExternalUser",
"arn:aws:iam::111122223333:role/ExternalRole"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "unique-external-id-12345"
},
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}

Federation Roles
SAML Federation
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:saml-provider/CompanySAML"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Role Session Management

Temporary Credential Properties
Default Duration: 1 hour
Maximum Duration: 12 hours (for chained assumptions: 1 hour)
Minimum Duration: 15 minutes
Session Names: Track who assumed the role
Role Chaining Limitations
Maximum of one level of chaining
Reduced session duration (1 hour max)
Original caller identity preserved in CloudTrail
IAM Policies Comprehensive Guide
Policy Language Deep Dive
Action Specification Patterns
json
 {
"Action": [
"s3:GetObject", // Specific action
"s3:Put*", // Wildcard matching
"s3:List*", // Multiple actions
"ec2:Describe*", // Read-only pattern
"*" // All actions (use carefully)
]
}

Resource ARN Patterns

json
{
"Resource": [
"arn:aws:s3:::my-bucket", // Specific bucket
"arn:aws:s3:::my-bucket/*", // All objects in bucket
"arn:aws:s3:::my-bucket/user/${aws:username}/*", // Dynamic paths
"arn:aws:ec2:us-west-2:123456789012:instance/*", // Regional resources
"*" // All resources
]
}

Advanced Condition Operators

String Conditions
json
{
"Condition": {
"StringEquals": {"aws:RequestedRegion": "us-east-1"},
"StringLike": {"s3:prefix": "home/${aws:username}/*"},
"StringNotEquals": {"aws:userid": "AIDACKCEVSQ6C2EXAMPLE"}
}
}
Numeric Conditions
json
 {
"Condition": {
"NumericLessThan": {"aws:MultiFactorAuthAge": "3600"},
"NumericBetween": {"aws:TokenIssueTime": ["1609459200", "1640995200"]}
}
}
Date Conditions
json
{
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2024-01-01T00:00:00Z"},
"DateLessThan": {"aws:TokenIssueTime": "2024-12-31T23:59:59Z"}
}
}
IP Address Conditions
json
{
"Condition": {
"IpAddress": {"aws:SourceIp": ["203.0.113.0/24", "2001:DB8:1234:5678::/64"]},
"NotIpAddress": {"aws:SourceIp": "203.0.113.0/32"}
}
}

Policy Examples by Use Case

Developer Access Policy
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"s3:ListBucket",
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::dev-bucket",
"arn:aws:s3:::dev-bucket/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2"]
},
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
},
{
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances",
"rds:DeleteDB*"
],
"Resource": "*"
}
]
}

Time-Based Access Policy

json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "08:00Z"},
"DateLessThan": {"aws:CurrentTime": "18:00Z"},
"ForAllValues:StringEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2"]
}
}
}
]
}

Dynamic Resource Access

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::company-bucket/users/${aws:username}/*"
}
]
}

Security Best Practices

Multi-Layered Security Approach
Defense in Depth Strategy
 1. Account Level: Organizations, SCPs, CloudTrail
2. Identity Level: MFA, strong passwords, key rotation
3. Permission Level: Least privilege, permission boundaries
4. Resource Level: Resource-based policies, encryption
5. Network Level: VPC endpoints, security groups
6. Application Level: Application-specific authentication
Zero Trust Implementation
Never trust, always verify
Continuous authentication and authorization
Minimal access with just-in-time permissions
Comprehensive logging and monitoring
Access Key Security
Access Key Rotation Process
1. Create new access key (user now has 2 keys)
2. Update applications to use new key
3. Test thoroughly in all environments
4. Deactivate old key (don't delete immediately)
5. Monitor for errors for 24-48 hours
6. Delete old key once confirmed working
Detecting Compromised Keys
Unusual API call patterns in CloudTrail
Calls from unexpected IP addresses or regions
High-volume API calls
Calls to services the user doesn't normally use
AWS will notify you of suspected compromise
MFA Implementation Strategies
MFA Device Types
Virtual MFA: Apps like Google Authenticator, Authy
 Hardware MFA: Physical tokens (Gemalto, RSA)
U2F Security Keys: FIDO U2F compatible devices
SMS MFA: Text message codes (less secure)
Conditional MFA Policies
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
},
"NumericLessThan": {
"aws:MultiFactorAuthAge": "3600"
}
}
}
]
}

Advanced IAM Features

Permission Boundaries
Use Cases for Permission Boundaries
Developer Sandboxes: Limit what developers can access
Delegated Administration: Allow creation of roles with restrictions
Compliance Requirements: Ensure maximum permissions never exceeded
Incident Response: Temporary permission restrictions
Permission Boundary Example
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"ec2:*",
"lambda:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
}
]
}

Service Control Policies (SCPs)

SCP vs IAM Policy Differences
Feature IAM Policies SCPs
Effect Grant permissions Restrict permissions
Scope Individual accounts Organization/OUs
Inheritance No Yes (through OU hierarchy)
Management Account level Organization level

Common SCP Patterns

Prevent Root Access
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalType": "Root"
}
}
}
]
}
Region Restriction
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2", "eu-west-1"]
}
}
}
]
}

AWS Security Token Service (STS)

STS Operations
AssumeRole : Assume an IAM role
AssumeRoleWithSAML : SAML federation
 AssumeRoleWithWebIdentity : Web identity federation
GetFederationToken : Create federated user session
GetSessionToken : Create temporary credentials for MFA
Cross-Account Role Assumption
bash
# Assume role in another account
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/CrossAccountRole \
--role-session-name MySession \
--external-id UniqueExternalId
# Use temporary credentials
export AWS_ACCESS_KEY_ID=ASIAEXAMPLE
export AWS_SECRET_ACCESS_KEY=secretexample
export AWS_SESSION_TOKEN=tokenexample

Identity Federation
SAML 2.0 Federation
1. Identity Provider Setup: Configure SAML IdP
2. SAML Provider Creation: Create SAML provider in AWS
3. Role Configuration: Create roles for SAML users
4. Attribute Mapping: Map SAML attributes to AWS permissions
OpenID Connect (OIDC) Federation
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/example.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"example.com:aud": "my-application-id"
}
}
}
]
}

AWS SSO Integration

Centralized access management
Automatic user provisioning
Integration with external identity sources
Permission sets instead of individual policies
Single sign-on to multiple AWS accounts
Troubleshooting and Debugging
IAM Policy Simulator
Using the Policy Simulator
1. Select Principal: Choose user, group, or role
2. Select Actions: Specify actions to test
3. Select Resources: Define resource ARNs
4. Set Context: Add condition context values
5. Run Simulation: See allow/deny results with explanations
Simulation Context Keys
 aws:CurrentTime : Current date/time
aws:SourceIp : Source IP address
aws:userid : Unique user identifier
aws:username : IAM user name
aws:MultiFactorAuthPresent : MFA status
CloudTrail for IAM Debugging
Key CloudTrail Events
AssumeRole : Role assumption attempts
ConsoleLogin : Console access events
CreateAccessKey : Access key creation
AttachUserPolicy : Policy attachments
PutBucketPolicy : Resource policy changes
CloudTrail Query Examples
bash
# Find failed API calls
aws logs filter-log-events \
--log-group-name CloudTrail/IAMEvents \
--filter-pattern '{ $.errorCode = "AccessDenied" }'
# Track role assumptions
aws logs filter-log-events \
--log-group-name CloudTrail/IAMEvents \
--filter-pattern '{ $.eventName = "AssumeRole" }'

Common IAM Errors and Solutions

AccessDenied Troubleshooting Checklist
1. Check Explicit Denies: Look for deny statements
2. Verify Policy Attachment: Ensure policies are attached
3. Check Resource ARNs: Verify resource specification
4. Review Conditions: Check condition evaluation
5. Cross-Account Issues: Verify trust relationships
 6. Service Limits: Check IAM quotas and limits
Policy Conflict Resolution
json
// Example: Competing policies
// Policy A allows, Policy B denies
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
// vs
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::my-bucket/*"
}
// Result: Deny wins (explicit deny always overrides allow)

IAM Access Analyzer

Access Analyzer Findings Types
External Access: Resources accessible from outside your account
Unused Access: Permissions that haven't been used
Public Access: Resources accessible by anyone
Cross-Account Access: Resources shared with other accounts
Automated Security Reviews
bash
# Create access analyzer
aws accessanalyzer create-analyzer --analyzer-name security-review --type ACCOUNT
# List findings
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/secu

Real-World Implementation Patterns

Enterprise IAM Architecture
Multi-Account Strategy
Security Account: Centralized logging and monitoring
Shared Services Account: Common infrastructure
Production Accounts: Production workloads
Development Accounts: Development and testing
Sandbox Accounts: Individual developer experimentation
Role-Based Access Control (RBAC) Implementation
Organization Root
├── Security OU
│ ├── Log Archive Account
│ └── Audit Account
├── Production OU
│ ├── Prod App Account
│ └── Prod Data Account
└── Non-Production OU
├── Dev Account
├── Test Account
└── Staging Account

DevOps IAM Patterns

CI/CD Pipeline Roles
json
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::deployment-artifacts/*"
]
},
{
"Effect": "Allow",
"Action": [
"ecs:UpdateService",
"ecs:DescribeServices"
],
"Resource": [
"arn:aws:ecs:*:*:service/production/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Environment": "Production"
}
}
}
]
}

Infrastructure as Code (IaC) Permissions

Terraform/CloudFormation: Broad permissions for resource creation
Deployment Roles: Specific permissions for application deployment
Monitoring Roles: Read-only access for observability tools
Application Security Patterns
Microservices IAM Strategy
Service-Specific Roles: Each service has dedicated role
 Cross-Service Communication: Roles for service-to-service calls
Data Access Patterns: Database-specific access roles
Secrets Management: Integration with Secrets Manager/Parameter Store
Container Security
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:*:*:secret:app/production/*"
],
"Condition": {
"StringEquals": {
"secretsmanager:ResourceTag/Application": "${aws:PrincipalTag/Application}"
}
}
}
]
}

Cost Optimization and Limits

IAM Service Limits
Hard Limits (Cannot be Increased)
Users per Account: 5,000
Groups per Account: 300
Roles per Account: 1,000
Instance Profiles per Account: 1,000
Managed Policies per Account: 1,500
Soft Limits (Can Request Increase)
 Customer Managed Policies: 1,500 (default)
Policy Versions: 5 per managed policy
Attached Policies per Entity: 10 managed + inline policies
Policy Size Limits
Managed Policy: 6,144 characters
Inline Policy: 2,048 characters
Role Trust Policy: 2,048 characters
Resource-based Policy: Varies by service
Cost Optimization Strategies
Reducing IAM Complexity
Consolidate Policies: Use managed policies instead of multiple inline policies
Group-Based Management: Use groups instead of individual user policies
Regular Cleanup: Remove unused users, roles, and policies
Policy Standardization: Create reusable policy templates
Monitoring IAM Costs
IAM itself is free, but access granted can incur costs
Monitor resource usage through granted permissions
Use Cost Explorer with IAM user/role tags
Implement billing alerts for unexpected usage
Compliance and Auditing
Regular IAM Audits
Quarterly Access Reviews: Verify user access is still needed
Annual Policy Reviews: Update policies for changing requirements
Unused Credential Cleanup: Remove inactive access keys and users
Role Usage Analysis: Identify and remove unused roles
Compliance Frameworks
SOC 2: Logical access controls
PCI DSS: Payment card data access restrictions
 HIPAA: Healthcare data access controls
GDPR: Data access and processing controls
Audit Checklist
All users have MFA enabled
No unused access keys older than 90 days
All roles have appropriate trust policies
No overly permissive policies (wildcard actions/resources)
Cross-account access is documented and approved
Service accounts are properly identified and managed
CloudTrail is enabled and logs are retained
Access Analyzer findings are reviewed monthly
Advanced Scenarios and Examples
Cross-Account CI/CD Pipeline
Architecture Overview
1. Central CI/CD Account: Contains build/deployment tools
2. Target Accounts: Production, staging, development accounts
3. Cross-Account Roles: Deployment roles in each target account
4. Temporary Access: Time-limited deployment permissions
Implementation Steps
bash
# 1. Create deployment role in target account
aws iam create-role --role-name CrossAccountDeployRole --assume-role-policy-document file://trust-policy.json
# 2. Attach deployment permissions
aws iam attach-role-policy --role-name CrossAccountDeployRole --policy-arn arn:aws:iam::aws:policy/PowerUser
# 3. In CI/CD account, assume role
aws sts assume-role --role-arn arn:aws:iam::TARGET-ACCOUNT:role/CrossAccountDeployRole --role-session-na

Database Access Patterns

RDS IAM Authentication
 json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-1:123456789012:dbuser:database-instance-id/database-username"
]
}
]
}

DynamoDB Fine-Grained Access

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/UserData",
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": ["${aws:username}"]
}
}
}
]
}
Serverless IAM Patterns
Lambda Function Roles
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/MyTable"
}
]
}

API Gateway Lambda Authorizers

Custom authorization logic
Token-based authentication
Integration with external identity providers
Fine-grained API access control
Monitoring and Alerting
CloudTrail Integration
Key Events to Monitor
 ConsoleLogin failures
AssumeRole from unexpected sources
CreateUser or CreateRole events
AttachUserPolicy or AttachRolePolicy
CreateAccessKey events
Root account usage
CloudWatch Alarms for IAM
bash
# Root account usage alarm
aws cloudwatch put-metric-alarm \
--alarm-name "Root-Account-Usage" \
--alarm-description "Alarm for root account usage" \
--metric-name RootAccountUsage \
--namespace CloudTrailMetrics \
--statistic Sum \
--period 300 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold

Automated Compliance Checking

AWS Config Rules for IAM
iam-user-mfa-enabled : Ensure all users have MFA
iam-root-access-key-check : Detect root access keys
iam-user-unused-credentials-check : Find unused credentials
iam-policy-no-statements-with-admin-access : Prevent admin policies
Custom Compliance Scripts
python
 import boto3
def check_unused_access_keys():
iam = boto3.client('iam')
users = iam.list_users()
for user in users['Users']:
username = user['UserName']
access_keys = iam.list_access_keys(UserName=username)
for key in access_keys['AccessKeyMetadata']:
# Check last used date
last_used = iam.get_access_key_last_used(AccessKeyId=key['AccessKeyId'])
# Alert if unused for > 90 days

Emergency Procedures
Break-Glass Access
Emergency Access Role
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
},
"StringLike": {
"aws:userid": "AIDACKCEVSQ6C2EXAMPLE:*"
}
}
}
]
}
Emergency Response Procedures
1. Document Emergency: Create incident ticket
2. Notify Security Team: Alert security of emergency access
3. Use MFA: Ensure multi-factor authentication
4. Log All Actions: Document what was done and why
5. Time-Box Access: Limit emergency session duration
6. Post-Incident Review: Analyze and improve procedures
Account Recovery Scenarios
Lost Root Access
1. Contact AWS Support with account verification
2. Provide account details and ownership proof
3. Follow AWS account recovery process
4. Re-establish proper access controls
Compromised IA