Comparing IAM identity types
The following table (Table 3.3) compares the different types of IAM identities mentioned in this sub-section, including their use case and the type of credentials they can be used with:
| Identity Type | Use Cases | Credentials |
| Users | – Human users such as developers and system administrators who interact with AWS – Non-human users such as applications running outside AWS that make programmatic calls to AWS services | Long-term credentials: passwords, access keys, MFA devices |
| Groups | – Departmental or functional roles – Application-based grouping where multiple applications require similar AWS access | None (groups don’t have credentials but hold users who do) |
| Roles | – Cross-account access between AWS accounts – AWS services such as Lambda accessing other resources – Applications outside AWS via IAM Roles Anywhere – Identity federation with external identity providers – Temporary elevated access for specific tasks | Temporary credentials provided by STS |
| External Identities | – SSO for users to access AWS resources after logging into a corporate portal – Web and mobile applications using federation for user authentication – Temporary access based on external identity | Tokens or assertions issued by an external IdP, which are exchanged for temporary credentials via STS |
Table 3.3 – Comparison of the different types of IAM identities
It is important to note that AWS strongly discourages the use of IAM users for both human and non-human entities due to the security vulnerabilities associated with long-term credentials, even when enhanced with MFA. Instead, it is recommended to employ federation with identity providers for human users, granting access via temporary credentials. For non-human users or systems, leveraging IAM roles or integrating with third-party security vaults that issue temporary credentials is advised. IAM users should be considered only as a last resort when no other secure method is feasible. In such a situation, it is crucial to enhance their security by applying the best practices discussed in this section.
Transitioning from IAM identities, let’s pivot to the equally vital aspect of IAM policies.