AWS IAM Explained: Users, Groups, Roles and Policies

AWS Identity and Access Management (IAM) decides who can do what in your AWS account. Every API call, whether it comes from the console, the CLI, an application or another AWS service, is checked by IAM before it runs. Get IAM right and most security problems never happen. Get it wrong and a leaked key can empty your account.

This guide explains the four building blocks (users, groups, roles and policies), how they fit together, and the habits that keep an account safe.

The four building blocks

The root user: lock it away

When you create an AWS account you get the root user, which can do everything, including closing the account. Use it only for the handful of tasks that require it (changing account settings, some billing actions), enable MFA on it, do not create access keys for it, and use other identities for daily work.

Users and groups

An IAM user is a named identity in your account. It can have a console password, programmatic access keys, or both. Users on their own have no permissions; permissions come from policies.

Rather than attaching policies to every user, put users in groups and attach policies to the group. When someone changes teams, you move them between groups instead of rewriting their permissions. A user can belong to several groups; their effective permissions are the combination.

Note that groups cannot be nested, cannot be the principal in a resource policy, and cannot have tags used for access decisions. They are purely a way to manage user permissions in bulk.

For organizations with many people, IAM users are increasingly replaced by IAM Identity Center (single sign-on), where people sign in with their company identity and receive temporary credentials. The concepts are the same; only the source of the identity changes.

Roles: temporary credentials for everything else

A role is an identity without long-lived credentials. Something that is trusted (an EC2 instance, a Lambda function, a user in another account, a federated user) calls sts:AssumeRole and receives temporary credentials that expire, usually after an hour.

Every role has two policies:

• A trust policy that says who may assume the role, for example "Principal": {"Service": "ec2.amazonaws.com"}.
• Permission policies that say what the role may do once assumed.

The rule of thumb: applications use roles, never access keys. An EC2 instance with an instance profile, or a Lambda function with an execution role, gets credentials from AWS automatically and they rotate on their own. Hard-coded access keys in code or config files are the most common source of leaked credentials.

Policies: the rules

A policy is a JSON document with one or more statements. Each statement has an Effect (Allow or Deny), a list of Actions, the Resources they apply to and optional Conditions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::reports-bucket/*"
  }]
}

There are three flavors:

• AWS managed policies such as ReadOnlyAccess or AmazonS3ReadOnlyAccess. Convenient, maintained by AWS, often broader than you need.
• Customer managed policies you write and reuse across identities.
• Inline policies embedded in a single user, group or role. Use sparingly.

Policies attached to identities are identity-based. Some services also support resource-based policies attached to the resource itself, like an S3 bucket policy or a KMS key policy. We break down the JSON in detail in IAM Policy JSON Explained.

How AWS decides: allow, deny, default

IAM evaluates every request with three simple rules:

1. By default, everything is denied.
2. An explicit Allow in an applicable policy overrides the default.
3. An explicit Deny anywhere overrides any Allow.

Other layers can only narrow permissions further: AWS Organizations service control policies, permission boundaries and session policies set a ceiling that an Allow cannot exceed.

Least privilege in practice

• Start narrow and widen when needed. Granting *:* "for now" usually becomes permanent.
• Scope resources. s3:GetObject on one bucket prefix beats s3:* on *.
• Use conditions. Restrict by Region, source VPC, required tags or MFA.
• Use IAM Access Analyzer to find resources shared outside your account and to generate policies from actual CloudTrail activity.
• Turn on MFA for every human user and remove unused users, keys and roles. The IAM credential report shows when keys were last used.

A worked example: onboarding a new developer

1. Create the user (or their Identity Center account) with console access and enforce MFA.
2. Add them to the developers group, which has read access everywhere and write access to the dev environment.
3. For production changes, they assume a prod-deploy role that requires MFA and is limited to the deployment pipeline's actions.
4. Their application code running on Lambda uses the function's execution role, never their personal keys.

Practice it in a real account

In the free lab IAM Users, Groups and Permissions you create a user, a group and attach managed policies, then sign in as that user to see the permissions take effect. Follow it with IAM Roles and IAM Instance Role: Least-Privilege S3 Access from EC2 to replace access keys with roles.

FAQ

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

A user has long-lived credentials and represents one person or system. A role has no permanent credentials; it is assumed to get temporary ones, which makes it the safer choice for applications and cross-account access.

Can I attach a policy directly to a user?

Yes, but managing permissions through groups (for people) and roles (for workloads) scales far better and is easier to audit.

Is IAM free?

Yes. There is no charge for IAM users, groups, roles or policies.