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 a short time.

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 the corporate directory (Microsoft Entra ID, Okta, Google Workspace) for single sign-on and central management, ideally through AWS IAM Identity Center.

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). For the exact current size and quantity limits for policies, users, and roles, refer to the official IAM quotas documentation, as default and maximum quotas can change over time.

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 AWS STS (Security Token Service) for temporary credentials. The maximum session duration can be configured per role (up to 12 hours); if not specified, sessions typically default to one hour. The AssumeRole API returns an access key, secret key, and session token, which must be refreshed automatically before expiration.

Multi-Factor Authentication (MFA)

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

Virtual MFA: Apps like Google Authenticator, Authy, 1Password Hardware MFA: FIDO security keys and other hardware tokens SMS-based MFA: Not recommended by AWS for security reasons (SIM swapping risk)

MFA can be enforced via IAM policy for sensitive operations, for example allowing S3 object deletion only with active MFA. MFA on the root account is considered a mandatory best practice.

Common Use Cases for AWS IAM

Federation with Corporate Identity Providers

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

Benefits: central user management, automatic onboarding/offboarding on personnel changes, no password synchronization, audit trails in the corporate directory. AWS IAM Identity Center (formerly AWS 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: a security team in a central security account assumes a ReadOnly role in production accounts for audits.

Trust policies define which principals can assume a role. An external ID parameter protects against the 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, such as EC2 instance profiles with S3 read access or Lambda execution roles with DynamoDB access. IAM roles avoid access keys in code, support automatic credential rotation, and enable granular permissions per service. CloudTrail logs all AssumeRole calls for compliance purposes.

Least-Privilege Access for Developers

Developers need access to AWS resources, but with restrictions. Best practice: central login through IAM Identity Center with multiple roles per developer, ReadOnly access as the default, and extended permissions granted only temporarily and after approval. Permission boundaries prevent developers from granting themselves broader rights than intended.

Compliance and Audit

IAM supports compliance requirements through detailed access control and audit trails: CloudTrail logs all IAM API calls, IAM Access Analyzer identifies external access to resources, credential reports show usage of all credentials, and Access Advisor shows which permissions were last used. AWS Config Rules and AWS Security Hub enable automated compliance checks across multiple accounts.

Best Practices for AWS IAM

1. Use IAM Roles Instead of Users

Avoid permanent IAM user credentials. Use federation with a corporate identity provider through IAM Identity Center for humans, IAM roles with EC2 instance profiles or ECS task roles for applications, and OIDC federation for CI/CD pipelines. Where IAM users are unavoidable, enforce MFA and rotate access keys regularly.

2. Implement Least Privilege

Start with minimal permissions and add incrementally what is actually needed. Use AWS-managed policies for standard cases and custom policies for specific requirements. IAM Access Advisor shows recently used permissions; unused permissions should be removed regularly.

3. Activate MFA for Privileged Access

MFA is mandatory for the root account and recommended for all privileged IAM users. MFA can be enforced via IAM policy for sensitive operations, for example through a condition on aws:MultiFactorAuthPresent. Hardware MFA offers stronger protection against phishing than virtual MFA; SMS-based MFA should be avoided.

4. Use Service Control Policies (SCPs)

SCPs set guardrails at the AWS Organizations level and protect against accidental or malicious violations, for example through region restrictions, service deny lists, or encryption requirements. SCPs act as a filter before IAM policies: even an administrator in a member account cannot perform operations the SCP prohibits.

5. Automate Credential Rotation

Permanent credentials such as access keys should be rotated regularly. AWS Config Rules can alert on outdated keys, and AWS Secrets Manager can rotate database credentials automatically. Where possible, short-lived, role-based credentials should replace permanent access keys.

6. Implement Monitoring and Alerting

Monitor IAM activity continuously through CloudTrail logs in CloudWatch, EventBridge rules for critical events like root login or new access keys, IAM Access Analyzer for external access, and Amazon GuardDuty for ML-based anomaly detection.

7. Use Permission Boundaries

Permission boundaries set maximum permissions for users/roles and prevent privilege escalation. A typical use case: developers may create their own roles for Lambda functions, but only within the defined boundary.

8. Conduct Regular IAM Audits

Conduct regular IAM audits: credential reports show password age, MFA status, and key usage; Access Advisor identifies over-privileged roles; and Access Analyzer shows resources with external access. AWS Config, Security Hub, and Trusted Advisor support automating these checks.

AWS IAM vs. Alternatives

AWS IAM vs. Google Cloud IAM

Google Cloud IAM uses a similar policy-based model but relies on hierarchical resource organization (Organization → Folder → Project), while AWS uses a flatter account structure with AWS Organizations. AWS offers a very mature federation and condition model; Google stands out with simpler policy management through inheritance and granular organizational policies.

AWS IAM vs. Microsoft Entra ID

Microsoft Entra ID (formerly Azure Active Directory) is the central identity system in the Microsoft ecosystem, with strong integration into Microsoft 365 and Windows. AWS separates identity (IAM) and directory service (AWS Managed Microsoft AD) more strictly and offers a flexible, multi-cloud-capable policy engine. Entra ID stands out with unified identity across cloud and on-premises plus conditional access policies.

When to Choose AWS IAM vs. an External IAM Tool?

AWS IAM works well for pure AWS environments with standard compliance requirements. For multi-cloud environments, special compliance requirements, or central secret management across cloud boundaries, a specialized external tool like HashiCorp Vault, Okta, or Ping may be more appropriate. As multi-cloud experts, we provide vendor-neutral advice for the optimal solution for your requirements.

AWS IAM Integration with innFactory

As an 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, aligned with the AWS Well-Architected Framework Security Pillar.

Migration: Secure transfer of existing identity systems to AWS IAM, federation setup with Microsoft Entra ID, Okta, or Google Workspace, migration from IAM users to roles, and automated access key rotation.

Security & Compliance: GDPR-compliant IAM implementation, least-privilege policies following the zero-trust principle, MFA enforcement for privileged access, and continuous compliance monitoring with AWS Config, Security Hub, and GuardDuty.

Audit & Optimization: IAM audits to identify over-privileged roles, unused credentials, and external access, including prioritized remediation plans.

Training & Workshops: IAM best practices, policy development, federation setup, and security automation as hands-on workshops for your team.

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