In AWS, what is the difference between an IAM user with long-lived access keys and an IAM role assumed through AWS STS, and why do teams prefer the role?

## Two shapes of AWS credential Every call to an AWS API is signed with a credential, and AWS issues exactly two shapes of them. The first is a **long-term access key pair** belonging to an IAM user: an access key ID (they begin with `AKIA`) and a secret access key. It is created once, printed once, and remains valid until somebody explicitly deactivates or deletes it. The second is a **temporary security credential** minted by AWS STS (Security Token Service): an access key ID beginning with `ASIA`, a secret access key, **and a session token**, plus an expiration time after which all three are dead. An IAM **role** is the identity you assume to get the second shape. A role looks like a user in that it has permissions policies attached, but it has no password and no access keys. Nobody "owns" it. Instead it carries a trust policy naming who may assume it, and anyone who satisfies that policy can call STS and borrow the role's permissions for a bounded window. ## What AssumeRole actually returns ```bash aws sts assume-role \ --role-arn arn:aws:iam::111122223333:role/ReportsReader \ --role-session-name alice-adhoc ``` The response contains a `Credentials` block with `AccessKeyId`, `SecretAccessKey`, `SessionToken` and `Expiration`, and an `AssumedRoleUser` block with the session's ARN. All three credential parts are mandatory: temporary credentials are only accepted when the session token travels with them, as the `X-Amz-Security-Token` header on the signed request. Sending just the key and secret of a temporary credential produces an authentication failure, which is the single most common first-time mistake when people copy credentials by hand. ## Replacement, not addition A session created by assuming a role has **the role's** permissions. It does not keep the caller's. This surprises people who think of a role as a bag of extra rights bolted onto their user. If you can read S3 as yourself and assume a role that can only read DynamoDB, the assumed session cannot read S3 — you have swapped identities, not stacked them. (A session policy passed at assume time can narrow that further, never widen it.) ## Why expiry is the whole point The security argument is about the **exposure window**. A long-lived key that leaks into a git repository, a CI log, a laptop backup or a container image is a working credential the day it leaks and a working credential a year later. A temporary credential that leaks the same way is worthless within hours, usually within one hour, because that is the default session length. You have not made theft impossible; you have made the stolen thing perishable. The operational argument matters just as much. Long-lived keys must be distributed, stored and rotated, and every one of those steps is a place a secret gets written down. With roles, the credential is fetched at runtime by the SDK and refreshed before it expires, so there is no secret to store and no rotation calendar to maintain. The third argument is **attribution**. When you assume a role you supply a `RoleSessionName`, and that string appears in every CloudTrail event the session produces. A shared IAM user's key tells you only that "the deploy user" acted; a role session tells you which pipeline run or which engineer did. ## Revocation is the awkward part Because a temporary credential is self-contained, you cannot cancel it the way you delete an access key. Deleting or detaching the role's permissions policies stops *future* authorization, and in practice the standard emergency lever is to attach a policy that denies everything for sessions issued before a cutoff, keyed on `aws:TokenIssueTime`. It works, but it is clumsy — which is another reason short session lifetimes are the real control. ## Where long-lived keys still legitimately appear They have not vanished. A third-party tool that cannot federate, a legacy on-premises script, or a partner integration may still need an IAM user with keys. When you must, the discipline is: one user per purpose, no console password, minimum policy, and monitoring of last-used data so dormant keys get deleted. Everything else — anything running inside AWS, anything a human uses interactively — should be a role.