AWS IAM Roles vs IAM Users: Why Roles Win for Workloads and What Still Needs Users

Many AWS accounts still run workloads on IAM users with access keys created years ago, even though AWS's own best practices ask workloads to use temporary credentials through IAM roles. The difference is not cosmetic: a role hands out credentials that expire, an IAM user holds credentials that last until someone rotates or deletes them. This guide compares IAM roles and IAM users property by property, sets out the short list of cases where AWS still expects an IAM user, gives a decision table by workload type and a phased plan to move workloads from users to roles with a safe rollback. It is for cloud platform engineers, AWS account owners and identity teams. For policy and trust policy design see the AWS IAM Policies and Roles Guide; for STS mechanics see the AWS STS and AssumeRole Guide.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Roles issue temporary credentials; users hold long-term ones. A role has no password or access keys of its own. Each session gets temporary credentials that last from 15 minutes to 12 hours, one hour by default.
• AWS's own best practice is roles for workloads. "Require workloads to use temporary credentials with IAM roles to access AWS" is one of the IAM best practices, alongside federation for humans.
• Workloads outside AWS can use roles too. IAM Roles Anywhere (X.509 certificates), AssumeRoleWithWebIdentity (OIDC), AssumeRoleWithSAML and hybrid compute options deliver temporary credentials to non-AWS systems.
• A short list still needs IAM users. AWS names four: emergency access, workloads that cannot use roles (such as CodeCommit and Amazon Keyspaces access), third-party AWS clients, and accounts with no IAM Identity Center or other identity provider.
• Roles still need least privilege. Temporary credentials shorten exposure but carry the role's full permissions while valid, so scope roles tightly and protect the credential delivery path.

What each identity is

An IAM user is an entity in one AWS account, representing a human or a workload, made up of a name and credentials. Its credentials can be a console password, up to two access keys for programmatic calls, SSH public keys for CodeCommit and server certificates. A new IAM user has no permissions until policies are attached. Access key IDs for IAM users begin with AKIA.

An IAM role is an identity in your account with permission policies, but it is not tied to one person and has no standard long-term credentials. A principal that the role's trust policy allows can assume it and receives temporary security credentials for that session (access key ID beginning ASIA, secret key and session token). Principals that can assume a role include IAM users and roles in the same or another account, AWS service principals such as EC2 and Lambda, IAM Roles Anywhere, and external identities authenticated through SAML 2.0 or OpenID Connect providers. Service-linked roles are a special type owned by an AWS service, which you can view but not edit.

Side-by-side comparison

Why roles win for workloads

• No secret to leak from code or config. Workloads on EC2, Lambda, ECS and EKS receive role credentials from the platform, so there is no access key to commit to a repository or copy into a ticket. Long-term keys in files are ATT&CK T1552.001 Credentials In Files.
• Exposure is bounded by time. A stolen session credential stops working when the session ends. A stolen user key keeps working until it is found.
• Trust is explicit. The trust policy states exactly which principals can assume the role, and wildcards are not allowed in principal ARNs. Conditions such as sts:ExternalId, sts:SourceIdentity and, for OIDC federation, subject and audience claims, narrow it further.
• Sessions can be narrowed. Session policies (up to 10 managed policy ARNs plus an inline policy) restrict a session to a subset of the role's permissions, and up to 50 session tags support attribute-based access control.
• No rotation backlog. Removing access keys removes the rotation process, the outages it causes and the audit exceptions when it is skipped.

What still needs IAM users

AWS documents four cases where IAM users with long-term credentials may be needed, and says that outside them IAM users are generally not the best choice. Treat each as a controlled exception.

For the full key lifecycle see the AWS Access Keys Security Guide, and for emergency users the AWS Root Account Compromise Playbook. Root user access keys are a separate matter: AWS says not to create them at all.

Choosing: decision table by workload

Small teams with a single account can get most of the value by moving workloads to execution roles and instance profiles and using IAM Identity Center for people. Multi-account organisations should add guardrails at AWS Organizations level, for example service control policies that deny iam:CreateUser and iam:CreateAccessKey outside an approved exceptions path. See the AWS Organizations and SCPs Guide.

Security trade-offs to manage with roles

• Credential delivery becomes the target. Role credentials on EC2 come from the instance metadata service, so request forgery in an application can expose them (ATT&CK T1552.005 Cloud Instance Metadata API). Require IMDSv2 and keep the hop limit low for containers.
• Over-broad trust policies. A trust policy that trusts a whole account root, or an OIDC provider without subject conditions, lets more principals assume the role than intended.
• Role chaining hides the origin. Chained sessions are capped at one hour, but without SourceIdentity the original caller is hard to trace. See AWS Role Chaining Detection.
• Revocation is session-based. Issued session credentials stay valid until they expire. Know how to revoke active sessions for a role (the console's revoke sessions action adds a deny policy keyed on token issue time) and keep maximum session durations short for sensitive roles.
• Shared roles lose attribution. One role used by many workloads behaves like a shared account. Use one role per workload and a session name that identifies the caller.

Migrating workloads from IAM users to roles

1. Inventory users and keys. Pull the IAM credential report and access key last used data. Classify each user as human, workload, third-party tool or break-glass.
2. Find each key's real consumer. Use CloudTrail to see source IP, user agent and API calls per access key ID, which identifies the system and the permissions actually used.
3. Create the target role. Write a trust policy for exactly that workload's delivery path, and a permissions policy based on observed use. IAM Access Analyzer can generate a policy from CloudTrail activity; test it before production.
4. Switch a pilot. Move one instance, function or pipeline to the role. SDKs pick up role credentials through the default credential chain, so the change is often configuration only. Watch for AccessDenied errors (see the AWS AccessDenied Troubleshooting Guide).
5. Deactivate, do not delete. Set the old access key to inactive, keep it for a defined window, and monitor for failed calls that show a missed consumer. Rollback is reactivating the key.
6. Delete the key and the user. When the window passes with no use, delete the access key, then the IAM user if nothing else depends on it.
7. Prevent regression. Add SCP guardrails, an AWS Config rule or Security Hub control for access key age and user MFA, and secret scanning on repositories.

Detection and measurement

Log and alert on CreateUser, CreateAccessKey, CreateLoginProfile and UpdateAssumeRolePolicy events in CloudTrail. Attackers who obtain keys often create new IAM users and keys for persistence (ATT&CK T1136.003 Cloud Account and T1098.001 Additional Cloud Credentials). Watch for role credentials used from outside the network or account where they were issued, and for AssumeRole from unexpected principals. Use IAM Access Analyzer external access findings to catch roles trusted by outside accounts. See the AWS CloudTrail Guide and IAM Access Analyzer Guide.

• Workload users remaining: IAM users classified as workloads, trending to the documented exceptions only.
• Active access keys and median age: across all accounts, falling over time.
• Keys unused for 90 days: target zero; deactivate on sight.
• Human IAM users: target zero outside break-glass, with people on federation.
• Roles with external trust: every one reviewed and owned, with external ID or OIDC subject conditions.
• Roles with unused permissions: from Access Analyzer unused access findings, falling each quarter.

Common failure patterns

• A "CI user" with admin keys. One IAM user with broad rights whose keys sit in every pipeline. Replace it with OIDC federation and one role per pipeline.
• Migrating credentials but not permissions. The workload moves to a role that copies the old user's full policy. Use observed activity to cut it down.
• Trust policies without conditions. OIDC trust without repository or subject restrictions, or cross-account trust without an external ID for third parties.
• Keys created "temporarily" for debugging. An engineer creates an access key on a workload user to test something and it stays. Alert on CreateAccessKey and expire exceptions.
• Break-glass users that are never tested. MFA devices lost, passwords unknown, alarms not wired. Test on a schedule.
• Persistence left behind after an incident. Responders deactivate the leaked key but miss the new users, keys and roles created with it. Review every identity created during the exposure window.

Where identity governance fits

Both roles and workload users are non-human identities and belong in the NHI inventory with an owner, purpose and review date. Roles need the same lifecycle as any other identity: removal when the workload is retired, and periodic review of trust and permissions. See the Non-Human Identity (NHI) Guide and NHI Offboarding and Decommissioning Guide.

Framework mapping

Practitioner checklist

• Run the credential report and classify every IAM user as human, workload, third-party tool or break-glass.
• Move every workload on AWS compute to an instance profile, execution role or task role.
• Move external pipelines and servers to OIDC federation or IAM Roles Anywhere.
• Move people to IAM Identity Center; remove access keys from human users.
• Document each remaining IAM user against one of AWS's four named use cases, with an owner.
• Pin trust policies with subject, external ID or source conditions; require IMDSv2.
• Set short maximum session durations on sensitive roles and require SourceIdentity where chaining is used.
• Block new users and access keys through SCPs except via an approved path.
• Alert on CreateUser, CreateAccessKey and trust policy changes; review unused access quarterly.

Standards and references

• AWS: Security best practices in IAM
• AWS: IAM roles
• AWS: IAM users
• AWS: When to use IAM users
• AWS: STS AssumeRole API reference
• AWS: Manage access keys for IAM users
• NIST: SP 800-53 Rev. 5
• OWASP: Non-Human Identities Top 10 2025

Related NHI Mgmt Group resources: AWS IAM Policies and Roles Guide, AWS STS and AssumeRole Guide, AWS Access Keys Security Guide, Cloud Workload Identity Guide, AWS Security Guide.