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

<MCQExercise exercise={{ id: 'aws-iamug-group-policies', title: 'Policies on users or groups', description: 'Why is attaching policies to groups rather than directly to individual users considered best practice?', options: [ { id: 'a', text: 'Permissions become reviewable and consistent in one place, and removing someone from a group revokes everything at once' }, { id: 'b', text: 'Group policies are evaluated faster than user policies by IAM' }, { id: 'c', text: 'Users cannot have policies attached directly' }, { id: 'd', text: 'Group policies bypass service control policy restrictions' }, ], correctId: 'a', explanation: 'With per-user policies, answering "what can this person do" means inspecting every attachment on every user, and offboarding means finding all of them. Group-based permissions make the intended access model explicit and reviewable, and membership changes apply instantly. It is the same reasoning behind role-based access control generally.', wrongExplanations: { b: 'Policy evaluation performance is identical and is never a consideration. The benefit is entirely organisational.', c: 'Users can have policies attached directly, both managed and inline. Doing so is discouraged rather than impossible.', d: 'Nothing bypasses a service control policy. SCPs set a ceiling that no identity policy of any kind can exceed.', }, }} />

<MCQExercise exercise={{ id: 'aws-iamug-rotation', title: 'Rotating a key safely', description: 'What is the correct sequence for rotating an IAM access key that is in active use?', options: [ { id: 'a', text: 'Create a second key, deploy it, deactivate the old one, verify nothing broke, then delete it' }, { id: 'b', text: 'Delete the old key, then create a new one and deploy it quickly' }, { id: 'c', text: 'Create a new key and delete the old one in the same command to avoid a window with two active keys' }, { id: 'd', text: 'Rotate the user's console password, which regenerates the access key automatically' }, ], correctId: 'a', explanation: 'IAM allows two active keys per user precisely to make zero-downtime rotation possible. Deactivating rather than deleting at step three is the important detail: if something you missed was still using the old key, reactivating it is one command, whereas a deleted key is gone and the secret is unrecoverable.', wrongExplanations: { b: 'Deleting first guarantees an outage for anything using the key, and leaves no way back since the old secret cannot be recovered.', c: 'The overlap window is the whole point of the two-key allowance, not something to avoid. Without it, rotation always causes downtime.', d: 'Console passwords and access keys are entirely separate credentials. Changing one has no effect on the other.', }, }} />