IAM Role vs IAM User
The distinction that underpins secure AWS access: users hold permanent credentials, roles grant temporary ones on assumption — and roles should be your default.
What is an IAM role vs an IAM user?
In AWS IAM, a user is a permanent identity with long-lived credentials (a password, or access keys that don’t expire until you rotate them). A role is an identity with no permanent credentials — it’s assumed by a trusted principal (an EC2 instance, a Lambda, a federated human, another account), and assumption issues temporary credentials that expire in minutes to hours. This one distinction is the foundation of secure AWS access, and the modern guidance is blunt: prefer roles almost everywhere; minimize users.
Why temporary beats permanent
Long-lived access keys are the single most common cloud credential leak — committed to Git, embedded in images, pasted into configs, and valid until someone notices and rotates them. Roles eliminate the class of problem: an EC2 instance with an instance role gets automatically-rotated temporary credentials via the metadata service, so there are no static keys on the box to steal. A human federated through SSO assumes a role for a session that expires — nothing durable to exfiltrate. This is why the well-architected pattern is: workloads use roles (instance roles, Lambda execution roles, IRSA for EKS pods), humans use federated role assumption (SSO → temporary credentials), and standing IAM users approach zero — ideally only break-glass and a few legacy service integrations that genuinely can’t federate.
The trust-policy mechanic
A role has two policy halves: the permissions policy (what it can do) and the trust policy (who may assume it). The trust policy is the security-critical, frequently-fumbled part — an over-broad trust policy (Principal: * or a too-wide account condition) lets unintended principals assume the role, quietly widening access. Cross-account access, third-party integrations, and CI/CD via OIDC federation (GitHub Actions assuming a role with no stored AWS secret) all hinge on getting the trust policy exactly scoped.
What people get wrong
- Access keys for workloads — the leading credential-leak vector, when an instance/Lambda role would carry auto-rotating temp creds.
- Over-broad trust policies: focusing on permissions while leaving who can assume wide open.
- Long-lived keys for CI/CD instead of OIDC federation, which needs no stored secret at all.
Primary source: AWS IAM — roles vs users
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.