IAM User vs Role vs Policy
IAM users and IAM roles are both principals representing "who or what" accesses AWS, but differ in the nature of their credentials. An IAM policy is the permission document attached to either one, defining "what is allowed."
| Aspect | IAMユーザー | IAMロール |
|---|---|---|
| Credentials | Holds long-term access keys or passwords | Issues temporary security credentials (STS) on each use |
| Typical principal | Exceptional workloads that cannot avoid long-term credentials | AWS services (EC2/Lambda), other accounts, and federated users such as IAM Identity Center users |
| Credential rotation | Requires manual rotation (leak risk) | Automatically issued and expired |
| How it's used | Direct login (password) or access key | Temporarily assumed via AssumeRole |
| Typical use | Exceptions such as legacy tools that cannot use roles or temporary credentials | Granting EC2/Lambda permissions, cross-account access, IAM Identity Center/federation |
How to Choose
For human access, AWS recommends IAM Identity Center or federation with an external identity provider, using roles and temporary credentials. Reserve IAM users for exceptional cases where roles and temporary credentials are unsupported and long-term credentials are unavoidable. Use IAM roles for AWS resources such as EC2/Lambda and for cross-account access, attaching least-privilege IAM policies.
Exam Points
- All exams commonly test "least privilege" and "prefer roles over long-term credentials" as core design principles
- SAA frequently tests the anti-pattern "hardcoding access keys" vs the correct approach of attaching an IAM role to EC2 for S3 access
- Policy evaluation logic (explicit Deny > explicit Allow > default Deny) and the distinction from SCPs (Service Control Policies) are recurring topics
Related Service Guides
References
Last updated: 2026-09-06
This page is created from AWS official documentation and reviewed/edited by the operator. See our editorial & quality policy for details.