AWS Identity & Access Management (IAM) Fundamentals
Last updated
Last updated
AWS Identity & Access Management (IAM) is the foundation of secure access control in AWS. It manages who can access AWS resources, what they can do, and how access is granted.
User authentication & authorization
Granular access controls with policies
Role-based access management (RBAC)
Temporary security credentials for workloads
Integration with Identity Providers (Okta, Azure AD, etc.)
SecureCart uses IAM to control access to AWS services and resources while following security best practices to protect customer data, prevent unauthorized changes, and enable seamless operations.
Developers need to manage deployments but should NOT have full admin access.
SecureCart’s EC2 instances need to retrieve product images from S3 without storing credentials.
A Lambda Function Needs to Process Payments Using AWS Secrets Manager
SecureCart’s CI/CD Pipeline in the DevOps Account Needs to Deploy to Production
SecureCart’s security engineers should be able to audit AWS resources but NOT make changes.
Scenario
IAM Solution
Developer Access to AWS Accounts
IAM Identity Center (SSO) with Permission Sets
EC2 Access to S3 for Product Images
IAM Role assigned to EC2 instance
Lambda Access to Secrets Manager for Payments
IAM Role with Secrets Manager read access
CI/CD Deployment Across Accounts
Cross-account IAM Role assumption
Security Team Read-Only Audits
IAM Identity Center Group with SecurityAudit policy
IAM Users represent individuals who need access to AWS.
Each IAM User has unique credentials (password, access keys, MFA) and can have assigned permissions.
Only used for break-glass access (not for daily work).
SecureCart relies on IAM Identity Center (SSO) instead of IAM Users for authentication.
MFA is required for any IAM User with AWS Management Console access.
IAM Groups combine multiple IAM Users and assign permissions to them collectively.
Instead of assigning policies one by one, a group policy applies to all users inside the group.
SecureCart avoids IAM Groups in favor of IAM Identity Center (SSO).
If IAM Groups were needed, SecureCart would create
Billing-ReadOnly (Finance Team)
Security-Audit (Security Team)
DevOps-Admin (Operations Team)
IAM Policies define permissions for users, groups, or roles.
They specify who can do what on which resources.
AWS-Managed Policies → Predefined by AWS (e.g., AdministratorAccess, ReadOnlyAccess).
Customer-Managed Policies → Custom policies SecureCart creates for fine-grained control.
Inline Policies → Directly attached to users, groups, or roles (not reusable).
Least privilege (Only allow necessary actions).
Deny dangerous actions like deleting databases.
Use AWS-Managed Policies for standard use cases.
IAM Roles provide temporary permissions to users, AWS services, or applications.
Unlike IAM Users, IAM Roles do not have permanent credentials.
Applications running on EC2, Lambda, or ECS that need access to AWS services.
Cross-account access between different AWS accounts.
Temporary security credentials for users via AWS STS.
SecureCart EC2 instances assume IAM Roles to access S3 securely.
Developers assume IAM Roles instead of using IAM Users.
Cross-account roles allow CI/CD to deploy across multiple AWS accounts.
Use IAM Identity Center (SSO) instead of IAM Users
Require MFA for all human access
Use IAM Roles instead of long-term IAM credentials
Follow the principle of least privilege in IAM Policies
Enable IAM Access Analyzer to detect misconfigurations
Use AWS CloudTrail to log IAM activity
