AWS IAM roles vs users vs Identity Center

AWS provides three primary ways to manage identity: IAM users, IAM roles, and IAM Identity Center. Each serves a different purpose, and understanding the difference matters because choosing the wrong one is one of the most common sources of credential-related security incidents in cloud environments.

What is an IAM user?

An IAM user is a long-lived identity attached to a specific AWS account, with credentials that do not expire unless explicitly rotated. IAM users can authenticate with a password (for console access) or an access key pair (for programmatic access). Neither credential type expires automatically.

The problem with long-lived credentials is that they accumulate. Engineers leave and their keys persist. Keys are committed to code repositories by accident. Keys are hardcoded into CI/CD pipelines and forgotten. Security audits routinely surface IAM access keys that have been active for years, never rotated, and in some cases no longer attached to a recognized employee. Long-lived credentials are the most common entry point in cloud account compromises. AWS has moved steadily away from recommending IAM users for human access, and IAM Identity Center is now the explicit recommendation for that use case.

What is an IAM role?

An IAM role is an identity that does not belong to a specific person. Instead of holding permanent credentials, a role is assumed by a trusted entity — a service, a function, an EC2 instance, or another role — which receives temporary credentials with a defined expiry.

Roles are the right model for machine identities. An EC2 instance running application code should assume a role through the instance metadata service; the application calls AWS APIs using credentials that are automatically rotated. A Lambda function is assigned a role at creation time and assumes it on each invocation. A CI/CD pipeline in GitHub Actions can assume a role through OIDC federation without storing any static credentials at all.

Temporary credentials expire, so a leaked token has a limited useful lifetime. This does not eliminate risk, but it substantially reduces the blast radius compared to a leaked access key that remains valid indefinitely.

What is IAM Identity Center?

IAM Identity Center (formerly AWS SSO) is AWS’s recommended solution for managing human access to AWS accounts. It sits above IAM and provides federated authentication through an external identity provider — Okta, Azure AD, Google Workspace, or any SAML 2.0 compatible provider.

When a user authenticates through Identity Center, they receive short-lived credentials scoped to a specific account and permission set. The session expires, typically within one to eight hours. The user’s underlying identity is managed in the external IdP, meaning that offboarding an employee in Okta or Azure AD removes their AWS access without requiring changes in each individual account. Permission sets (the Identity Center equivalent of IAM policies) are defined once and applied across any number of accounts.

This model solves the key lifecycle problem. There are no static access keys to rotate or revoke. Credential validity is bounded by session duration. Audit logs capture which human identity accessed which account, not just which role was assumed.

What do all three have in common?

IAM users, roles, and Identity Center all answer the same question: who is allowed in, and what are they allowed to do once they are. They are access controls.

None of them answer what happens after access is granted. A legitimate user with a valid session and appropriate permissions can still delete a production database, disable audit logging, or exfiltrate data. Identity controls determine whether the door opens. They say nothing about what happens on the other side of it. Monitoring for dangerous actions, requiring additional approval for high-impact operations, and enforcing policy on what can happen inside a permitted session — those are action-layer problems. That is the gap that access controls alone, however well designed, cannot close, and it is where Korvalis operates.