IAM Roles vs. Users: The Enterprise Pattern You Should Actually Use

Most people learning AWS start with an IAM user: a name, a password, maybe an access key pair. That's fine for a personal sandbox account. It's the wrong default for any real environment.

The problem with IAM users

An IAM user's access key is a long-lived credential. It doesn't expire on its own, it can be copied into a script or a laptop and forgotten there, and if it leaks, it works until someone manually revokes it. In 23 years of running enterprise infrastructure, almost every credential-leak incident I've seen traced back to a long-lived access key sitting somewhere it shouldn't - a CI script, a config file committed to a repo, an old EC2 instance.

The pattern that actually scales: roles + temporary credentials

An IAM role has no long-term credentials at all. Instead, something - a person, an EC2 instance, a Lambda function, another AWS account - *assumes* the role and receives temporary credentials that expire, typically within an hour. No secret to leak in a durable way, no key rotation to manage, no key sitting in a file six months after the person who created it left the company.

In practice, this looks like: - Humans sign in via SSO (AWS IAM Identity Center, or a federated identity provider) and assume a role scoped to what their job actually requires. - EC2/ECS/Lambda get an instance profile or execution role attached - the workload never touches a static key at all. - Cross-account access (a very common enterprise pattern - a shared services account managing dozens of workload accounts) is done via role assumption with an external ID, not by sharing keys between accounts.

Where this gets real

Owning departmental AWS spend, as I do today, means owning departmental IAM hygiene too. The rule I hold my own teams to: if you're about to create an IAM user with an access key, stop and ask what role-based alternative exists first. Nine times out of ten, there is one - and it's more secure by construction, not just by policy.