AWS IAM Explained: Users, Groups, Roles and Policies

What IAM does

IAM (Identity and Access Management) is the AWS service that answers one question for every request: is this identity allowed to perform this action on this resource? It applies to people clicking in the console, scripts using the CLI and applications calling AWS APIs.

The default answer is no. Nothing is allowed until a policy explicitly allows it.

The four building blocks

Attach policies to groups and roles, not to individual users. Then onboarding means adding a person to a group, and offboarding means removing them.

How to read a JSON policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

Read it as a sentence:

• Effect — Allow or Deny.
• Action — which API operations, in the form service:Operation. Wildcards like s3:* allow every S3 operation, which is rarely what you want.
• Resource — which objects, identified by ARN. Here: any file in the my-app-uploads bucket, and nothing else.
• Condition (optional) — extra requirements, for example a specific source IP or that MFA was used.

Version is the policy language version, not a date you change.

Evaluation logic in short: an explicit Deny always wins, then an explicit Allow permits the request, and anything not mentioned is denied.

Lock away the root account

The root user is the email address used to create the account. It can do everything, including closing the account and changing billing, and its permissions cannot be restricted by IAM policies.

What to do right after creating an account:

1. Enable MFA on root (a hardware key or authenticator app).
2. Make sure root has no access keys; delete them if they exist.
3. Use a strong unique password and a mailbox the company controls, not a personal one.
4. Create a separate admin identity for daily work and stop signing in as root.

Root is needed only for a few rare tasks, such as some billing and account settings.

Roles instead of access keys

Access keys are a permanent key pair. If they leak through a repository, a log or a laptop, they keep working until someone notices and deletes them.

Roles give temporary credentials that expire automatically. Use them wherever possible:

• EC2 or containers — attach a role to the instance or task; the SDK picks up credentials on its own, no keys in config files.
• Lambda — every function runs with an execution role.
• CI/CD — GitHub Actions and similar systems can assume a role through OIDC without storing keys in secrets.
• People — AWS recommends IAM Identity Center for workforce sign-in, which also hands out temporary credentials.

Keep access keys only for cases where nothing else works, and rotate them.

A least-privilege starting point for a small team

Least privilege means giving each identity only the permissions it actually needs.

• Admins group — one or two people, MFA required.
• Developers group — access to the services the project uses, ideally limited to development resources.
• ReadOnly group — for managers, auditors and support.
• One role per application — permissions only for its own bucket, queue or database.
• One role for deployment — assumed by CI/CD.

Start with AWS managed policies if you must move fast, then narrow them. IAM Access Analyzer can suggest a policy based on what an identity actually used.

Common mistakes

• Working daily as root or with AdministratorAccess for everyone.
• Access keys committed to Git or stored in .env on a laptop.
• "Action": "*" and "Resource": "*" in application policies.
• Shared users for several people, so nobody knows who did what.
• Forgotten users of people who left the team.