Root, Users, and Groups

Match identities to people and workloads

IAM is a global service. The root user is the email address that created the account; it has full authority and should be used only for tasks that require root. Protect it with MFA and do not create root access keys. For workforce access, AWS recommends IAM Identity Center and temporary credentials; IAM users remain useful for some legacy cases and labs.

flowchart TB
  R["Root user<br/>account tasks only"] -.-> ACC["AWS account"]
  G["Group Developers<br/>PowerUserAccess"] --> A["User dev-alice"]
  G --> B["User dev-bob"]
  U["Group Auditors<br/>ReadOnlyAccess"] --> B
  A --> ACC
  B --> ACC
  %% step R: Root can do everything, including closing the account; lock it away with MFA.
  %% step G: Permissions are attached to a group that matches a job function.
  %% step A: dev-alice gets the Developers permissions by being a member.
  %% step B: dev-bob is in two groups and receives the union of both.
  %% step U: A second group adds read-only audit access.
  %% step ACC: Every request is still checked against the combined policies.

What only root can do

Root is needed for a short list of tasks, such as changing the account's root email or contact settings, closing the account, restoring IAM permissions when every admin is locked out, and some billing settings. Everything else should be done by an admin principal. Keep root's MFA device and password in a safe place that more than one person can reach.

Users and groups

One IAM user represents one person or legacy workload; a team should not share it, because CloudTrail would no longer show who did what. A user can have a Console password, access keys, or both.

A group contains users only, not other groups or roles. A user can join multiple groups (up to 10) and receives their combined permissions unless an explicit Deny blocks access. Groups are not principals: you cannot sign in as a group or reference one in a resource policy.

Groups manage permissions by job function — Developers, Operators, Auditors — so onboarding is "add to group" and offboarding is "remove from groups, disable credentials". Least privilege grants only the necessary actions on the necessary resources instead of defaulting to AdministratorAccess.

IAM Identity Center

For real teams, Identity Center connects to a directory (its own, Microsoft Entra ID, Okta and others) and assigns permission sets to users across many accounts in AWS Organizations. People sign in once through a portal and receive short-lived credentials for the Console and CLI. There are no long-lived access keys to leak and leaving the company is one switch in the directory.

Traps: using root for daily work; sharing one IAM user across a team; trying to nest groups; giving everyone AdministratorAccess "for now".