AWS IAM Users and Groups

An IAM user is a long-lived identity with permanent credentials. A group is a container that carries policies and applies them to its members.

Both are foundational to understanding IAM, and current AWS guidance is that you should not create users for people. That tension is worth resolving up front, because most material on this topic predates the recommendation.

Users

A user has an ARN, optionally a console password, and optionally up to two access keys:

aws iam create-user --user-name ci-legacy-uploader
aws iam create-access-key --user-name ci-legacy-uploader

{
  "AccessKey": {
    "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Status": "Active"
  }
}

The secret is shown exactly once. There is no way to retrieve it again. Losing it means creating a new key and deleting the old one.

Those credentials remain valid until someone deletes them. They do not expire, they work from anywhere in the world, and they are trivially copied. That is the entire problem.

Groups

A group holds policies; users in it inherit them. Groups have no credentials and cannot be assumed.

aws iam create-group --group-name developers
aws iam attach-group-policy \
  --group-name developers \
  --policy-arn arn:aws:iam::aws:policy/PowerUserAccess
aws iam add-user-to-group --user-name alice --group-name developers

Attach policies to groups, never directly to users. Per-user policies produce an estate where nobody can answer "what can this person do" without inspecting each account individually, and where offboarding means finding every attachment.

A user can belong to up to ten groups, and permissions are the union of all of them.

Groups cannot be nested, there is no group-within-a-group, which is one of several reasons Identity Center exists.

Why AWS recommends against users for people

The failure mode with IAM users is not theoretical. Access keys end up in Git repositories, in CI configuration, in Slack messages, on former employees' laptops, and in Docker images. Public scanners find exposed AWS keys within minutes.

IAM Identity Center removes the category entirely: people sign in with corporate credentials and receive a temporary role session.

aws configure sso

Where users still make sense

A small number of genuine cases remain:

• A legacy system that cannot use roles or OIDC.
• A third-party tool requiring a static access key.
• An emergency break-glass account, heavily restricted and monitored.
• Personal learning accounts with no Identity Center.

Treat each as a liability with a named owner and a review date. Everything else, EC2, Lambda, ECS, EKS, CI pipelines, should use a role.

Access key hygiene

If you must have keys, manage them properly.

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d | column -t -s,

The report lists every user with MFA status, key age, and when each key was last used. Two things to act on:

Keys unused for 90 days should be deleted, not rotated. An unused key is pure risk with no benefit.

Rotation uses the two-key allowance:

# 1. Create a second key
aws iam create-access-key --user-name ci-legacy-uploader

# 2. Deploy it everywhere, verify
# 3. Deactivate the old one. Reversible
aws iam update-access-key --user-name ci-legacy-uploader \
  --access-key-id AKIAOLD --status Inactive

# 4. After a settling period, delete it
aws iam delete-access-key --user-name ci-legacy-uploader --access-key-id AKIAOLD

Deactivating before deleting is the part people skip, and it is what turns a botched rotation from an outage into a one-command revert.

MFA

aws iam list-users --query 'Users[].UserName' --output text | \
  xargs -n1 -I{} sh -c 'echo -n "{}: "; aws iam list-mfa-devices --user-name {} --query "length(MFADevices)"'

Enforce it with a policy condition rather than trusting people to enable it. Denying everything except MFA management when aws:MultiFactorAuthPresent is false is the standard pattern.

Migrating to Identity Center

1. Enable IAM Identity Center in the management account.
2. Connect an identity source: the built-in directory, Entra ID, Okta, or Google Workspace.
3. Create permission sets, which are the Identity Center equivalent of policies attached to groups.
4. Assign groups to accounts with permission sets.
5. Have people switch to aws configure sso.
6. Deactivate IAM user keys and watch CloudTrail for anything still using them.
7. Delete the users.

Step 6 matters. Deactivate rather than delete first, so anything you missed fails visibly and reversibly rather than permanently.

Quick reference

---

Key takeaways

• Do not create IAM users for people. Use IAM Identity Center or federation.
• A secret access key is displayed once. There is no way to retrieve it later.
• Attach policies to groups, never directly to users, or offboarding becomes an archaeology exercise.
• Groups cannot be nested and hold no credentials of their own.
• Delete keys unused for 90 days rather than rotating them.
• Deactivate before deleting during rotation, so a mistake is reversible.
• Enforce MFA with a policy condition, not by asking people to enable it.
• Deactivate old keys and watch CloudTrail before deleting users during migration.

---

Check your understanding

---

Frequently Asked Questions

Should I create IAM users for my team?

No. Current AWS guidance is to use IAM Identity Center or federate from an existing identity provider, so people sign in with corporate credentials and receive temporary role sessions. IAM users hold permanent credentials that do not expire, work from anywhere, and are easily copied, which is why exposed AWS access keys are found in public repositories within minutes of being committed. Identity Center also centralises offboarding and MFA enforcement across every account.

What is the difference between an IAM user and an IAM role?

A user is a long-lived identity with permanent credentials. A password and possibly access keys that remain valid until deleted. A role has no permanent credentials; it is assumed temporarily by a person, a service or another account, issuing credentials that expire automatically, typically within an hour. Roles are safer because there is no lasting secret, and they are what EC2 instances, Lambda functions, ECS tasks and CI pipelines should use.

I lost my AWS secret access key. Can I recover it?

No. The secret is displayed exactly once, at creation, and AWS does not store it in retrievable form. Create a new access key, deploy it wherever the old one was used, then deactivate and finally delete the old key. Since a user may hold two active keys, this can be done without downtime. If the lost key is no longer needed anywhere, simply delete it.

How often should I rotate access keys?

Frequently enough that a leaked key has limited value: 90 days is a common policy. But rotation is a mitigation for a problem better solved by removal: a key unused for 90 days should be deleted rather than rotated, and workloads should use roles so there is no key at all. Generate a credential report regularly to find both stale keys and users without MFA. Rotation matters most for the small number of keys that genuinely cannot be eliminated.

Can IAM groups be nested?

No. A group cannot contain another group, so hierarchies such as "all engineers" containing "backend engineers" are not possible in IAM. You would attach overlapping policies or add users to multiple groups instead. A user can belong to up to ten groups and receives the union of their permissions. This limitation is one of several reasons IAM Identity Center exists, since its permission sets and directory groups model organisational structure far better.

How do I migrate from IAM users to Identity Center?

Enable Identity Center in the management account, connect an identity source such as Entra ID, Okta or Google Workspace, then create permission sets and assign groups to accounts. Have people reconfigure their CLI with aws configure sso. Before deleting anything, deactivate the old access keys and watch CloudTrail for authentication failures, that surfaces any automation still using them in a way you can reverse with a single command. Delete the users only once the account has been quiet for a while.