AWS IAM

What is AWS IAM?

AWS IAM (Identity and Access Management) is the central service for controlling access to AWS resources. IAM enables the management of users, groups, roles, and detailed permissions via policies. The service is free and forms the foundation of every secure AWS architecture.

IAM operates as a global service across all AWS regions. Changes to policies or roles are replicated worldwide within seconds. The service offers a 99.99% availability SLA and is FIPS 140-2 Level 3 certified for the highest security requirements.

AWS IAM supports both direct user management (IAM Users) and federation with external identity providers (SAML 2.0, OpenID Connect). Best practice for enterprises: Federation with corporate directory (Active Directory, Okta, Google Workspace) for single sign-on and central management.

How AWS IAM Works

IAM is based on a policy-based authorization model. Every request to AWS is evaluated against all applicable policies. The principle: Deny by default, explicit allow statements required, explicit deny statements take precedence.

IAM Policies

Policies are JSON documents that define permissions:

Identity-based Policies: Attached to users, groups, roles
Resource-based Policies: Directly on resources (S3 buckets, KMS keys)
Permission Boundaries: Maximum permissions for users/roles
Service Control Policies: Guardrails at AWS Organizations level
Session Policies: Restriction of temporary credentials

Policies use Effect (Allow/Deny), Action (service operations), Resource (ARNs), Condition (context like IP, MFA, time). IAM Policy Simulator enables testing policies before deployment.

IAM Roles

Roles are temporary identities without permanent credentials. Use cases:

Service Roles: EC2 instances access S3 without access keys in code
Cross-Account Roles: Account A delegates access to Account B
Federation Roles: External users receive temporary AWS credentials
Lambda Execution Roles: Lambda functions with least-privilege permissions

Roles use STS (Security Token Service) for temporary credentials with 1-12 hours validity. AssumeRole API returns access key, secret key, and session token. Credentials rotate automatically before expiration.

Multi-Factor Authentication (MFA)

MFA enforces second authentication layer in addition to password or access keys. Supported MFA types:

Virtual MFA: Apps like Google Authenticator, Authy, 1Password
Hardware MFA: YubiKey, Gemalto tokens (FIPS 140-2 certified)
SMS-based MFA: Outdated, not recommended (SIM swapping risk)

MFA can be enforced via IAM policy for sensitive operations. Example: S3 object deletion only with MFA allowed. Root account MFA is mandatory best practice.

Common Use Cases for AWS IAM

Federation with Corporate Identity Providers

Single sign-on between your corporate directory and AWS eliminates separate AWS passwords. Users authenticate against Active Directory, Okta, or Google Workspace. The identity provider issues SAML assertions, AWS exchanges these for temporary IAM role credentials.

Benefits: Central user management, automatic onboarding/offboarding with personnel changes, no password synchronization, audit trails in corporate directory. AWS IAM Identity Center (formerly SSO) simplifies setup for multi-account environments.

Cross-Account Access Management

In multi-account architectures (AWS Organizations), IAM roles enable secure access between accounts. Example: Security team in central security account assumes ReadOnly role in production accounts for audits.

Trust policies define which principals can assume a role. External ID parameter protects against confused deputy problem. Session tags enable attribute-based access control (ABAC) for granular permissions based on user attributes.

Service-to-Service Authorization

AWS services use IAM roles for secure communication without hardcoded credentials. Examples:

EC2 to S3: Instance profile with role that allows s3:GetObject
Lambda to DynamoDB: Execution role with dynamodb:PutItem permission
CodePipeline to CodeBuild: Service role for build orchestration

IAM roles avoid access keys in code, support automatic credential rotation, and enable granular permissions per service. CloudTrail logs all AssumeRole calls for compliance.

Least-Privilege Access for Developers

Developers need access to AWS resources but with restrictions. Best practice: AWS SSO with multiple roles per developer:

ReadOnly Role: Standard access for monitoring and debugging
Developer Role: Deployment permissions for Dev/Test accounts
Production Role: Time-limited, only after approval, only for incidents

Permission boundaries prevent privilege escalation: Developers can create own roles but only within the boundary. Service control policies set guardrails at organizational level (e.g., no resources outside EU regions).

Compliance and Audit

IAM supports compliance requirements through detailed access control and audit trails:

CloudTrail: Logs all IAM API calls (CreateUser, AssumeRole, etc.)
IAM Access Analyzer: Identifies external access to resources
Credential Reports: CSV export of all user credentials with last usage
Access Advisor: Shows which permissions were last used when

Automated compliance checks with AWS Config Rules: Alert on root account usage, missing MFA, excessive permissions. AWS Security Hub aggregates findings from multiple tools.

Best Practices for AWS IAM

1. Use IAM Roles Instead of Users

Avoid permanent IAM user credentials. Use instead:

For Humans: Federation with corporate identity provider via AWS SSO
For Applications: IAM roles with EC2 instance profiles or ECS task roles
For CI/CD: OIDC federation with GitHub Actions, GitLab CI (no access keys)

If IAM users are unavoidable (legacy tools): Enforce MFA, rotate access keys every 90 days, use AWS Access Analyzer to identify unused keys.

2. Implement Least Privilege

Start with zero permissions and add incrementally what is needed. Use AWS-managed policies for standard use cases, create custom policies for specific requirements.

IAM Access Advisor shows which permissions were used in the last 90 days. Remove unused permissions regularly. Avoid wildcard permissions (:) in production. Use condition statements for context-dependent permissions (IP range, MFA status).

3. Activate MFA for Privileged Access

MFA is mandatory for root account and recommended for all privileged IAM users. Enforce MFA via IAM policy for sensitive operations:

{
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

Hardware MFA (YubiKey) offers highest security against phishing. Virtual MFA is sufficient for standard access. Avoid SMS MFA (SIM swapping risk).

4. Use Service Control Policies (SCPs)

SCPs set guardrails at AWS Organizations level and protect against accidental or malicious violations. Examples:

Region Restriction: Only EU regions allowed (GDPR compliance)
Service Deny List: Prohibition of expensive or unneeded services
Root Account Protection: Block root credentials except for break-glass
Require Encryption: Only encrypted S3 buckets, EBS volumes, RDS instances

SCPs act as filter before IAM policies: Even an administrator in member account cannot execute operations that the SCP prohibits.

5. Automate Credential Rotation

Permanent credentials (access keys) should be rotated regularly:

90-Day Rotation: AWS Config Rule alerts on older keys
Automated Rotation: Secrets Manager rotates database credentials automatically
Short-lived Credentials: Role-based credentials with 1-12 hours validity

For applications: Use IAM roles instead of access keys. For CI/CD: OIDC federation with short-lived tokens. Access keys only as last resort, then manage with AWS Secrets Manager.

6. Implement Monitoring and Alerting

Monitor IAM activities continuously:

CloudTrail: All IAM API calls in CloudWatch Logs
EventBridge Rules: Alerting on root login, MFA deactivation, new access keys
IAM Access Analyzer: Continuous monitoring of external access
GuardDuty: ML-based anomaly detection (unusual API calls)

CloudWatch alarms for critical events: Root account activity, failed login attempts, policy changes. SNS notifications to security team. Automated response with Lambda functions.

7. Use Permission Boundaries

Permission boundaries set maximum permissions for users/roles and prevent privilege escalation. Use case: Developers can create own roles for Lambda functions but only within the boundary.

Boundary defines upper limit, IAM policy defines actual permissions. Effective permissions are intersection of both. Ideal for delegated administration without security risk.

8. Regular IAM Audits

Conduct quarterly IAM audits:

Credential Report: All users, last password change, MFA status, last key usage
Unused Identities: Users/roles without activity in 90 days deactivate
Over-privileged Roles: Access Advisor shows unused permissions
External Access: Access Analyzer identifies resources with external access

Automation with AWS Config, AWS Security Hub, Trusted Advisor. Remediation runbooks for common findings. Compliance dashboard for management reporting.

AWS IAM vs. Alternatives

When comparing IAM solutions from different cloud providers, different strengths emerge:

AWS IAM vs. Google Cloud IAM

Google Cloud IAM uses a similar policy-based model but with simpler syntax. Google relies on hierarchical resource organization (Organization → Folder → Project), AWS on flatter account structure with Organizations.

AWS Advantages: More mature federation features, more comprehensive condition syntax, better third-party integration, larger ecosystem for identity tools.

Google Advantages: Simpler policy management through inheritance, more granular organizational policies, VPC Service Controls for data boundaries.

AWS IAM vs. Azure Active Directory / Entra ID

Azure uses Azure Active Directory (now Entra ID) as central identity system. Stronger integration with Microsoft ecosystem (Office 365, Windows, Active Directory). Azure Managed Identities similar to AWS IAM Roles.

AWS Advantages: Separation of identity (IAM) and directory (AWS Managed Microsoft AD), more flexible policy engine, better multi-cloud support.

Azure Advantages: Unified identity across cloud and on-premises, conditional access policies, stronger hybrid cloud features.

When AWS IAM vs. External IAM Tool?

Choose AWS IAM for: Pure AWS environment, standard compliance requirements, integration with AWS services, team with AWS expertise.

Choose External Tool (HashiCorp Vault, Okta, Ping) for: Multi-cloud environment (AWS + GCP + Azure), special compliance requirements (PCI DSS Level 1), dynamic secrets with short lifespan (minutes instead of hours), central secret management across cloud boundaries.

As multi-cloud experts, we provide vendor-neutral advice for the optimal solution for your requirements.

AWS IAM Integration with innFactory

As AWS reseller, innFactory supports you with:

Architecture Design: We design secure, scalable IAM architectures with federation, cross-account access, service control policies, and permission boundaries. Best-practice implementation according to AWS Well-Architected Framework Security Pillar.

Migration: Secure transfer of existing identity systems to AWS IAM. Federation setup with Active Directory, Okta, Google Workspace. Migration from IAM users to roles. Automated access key rotation.

Security & Compliance: GDPR-compliant IAM implementation in EU regions. Least-privilege policies according to zero-trust principle. MFA enforcement for privileged access. Continuous compliance monitoring with AWS Config, Security Hub, GuardDuty.

Audit & Optimization: IAM audits to identify over-privileged roles, unused credentials, external access. Remediation plans with risk-based prioritization. Automated guardrails with service control policies.

Training & Workshops: IAM best practices, policy development, federation setup, security automation. Hands-on workshops for your team with real scenarios.

24/7 Support: Monitoring of critical IAM events (root login, policy changes, MFA deactivation). Incident response for security incidents. Proactive optimization based on access patterns.

Contact us for a non-binding consultation on AWS IAM and security architectures on AWS.