IAM Groups

An IAM (Identity and Access Management) group is a collection of IAM users that share the same permissions. Instead of attaching the same policies to ten different people one by one, you attach the policies to a group once, then drop those people into the group. When someone changes jobs, you move them between groups instead of editing their individual permissions. Groups exist purely to make permission management for humans simpler and less error-prone.

What a group actually is

A group is a container for IAM users. The group itself has one or more policies attached to it. Every user who is a member of the group automatically inherits those policies, on top of any policies attached directly to that user.

A few key facts to keep straight:

A group has no credentials. You cannot log in “as a group.” Only users have passwords and access keys.
A user can belong to multiple groups (up to 10 by default). Their effective permissions are the union of all attached policies.
A group is not an identity you can grant access to in a resource policy or a trust policy. It is only a way to manage user permissions.

Gotcha: Groups cannot be nested — a group cannot be a member of another group. Also, a role cannot be a member of a group, and a group is only for human IAM users, never for AWS services. If you need a non-human identity (an application or service) to have permissions, use an IAM role instead.

When to use a group (and when not to)

Use a group whenever two or more users need the same set of permissions. Common examples: a Developers group, a Billing group, an Admins group. Managing by role-like group keeps your account tidy and auditable.

Do not reach for a group when:

Only one person ever needs a permission set — but even then, a group is often still cleaner because the next hire can just be added.
You need a service, an EC2 instance (Elastic Compute Cloud, AWS virtual servers), or a Lambda function to have permissions — use a role instead.
You need temporary, assumed credentials or cross-account access — again, that is a role, not a group.

Groups vs roles vs direct user policies

	IAM group	IAM role	Policy on a user
Who/what uses it	Human IAM users	Users, services, other accounts	One human user
Has long-term credentials	No	No (gives temporary credentials)	Yes (the user does)
Best for	Sharing permissions across people	Apps, services, assumed/temporary access	One-off exceptions
Can be nested / a member of another	No	No	N/A

The short rule: groups for people, roles for machines and temporary access.

Creating a group and adding users (Console)

Open the IAM console and choose User groups in the left navigation.
Click Create group.
Enter a group name, for example Developers.
Under Attach permissions policies, search for and tick the managed policies you want, for example AmazonS3ReadOnlyAccess.
(Optional) Under Add users to the group, select existing users now.
Click Create group.
To add a user later, open the group, go to the Users tab, choose Add users, select the user, and confirm.

Creating a group and adding users (CLI)

The same workflow with AWS CLI v2. First create the group:

aws iam create-group --group-name Developers

Output:

{
    "Group": {
        "Path": "/",
        "GroupName": "Developers",
        "GroupId": "AGPA0A1B2C3D4E5F6G7H8",
        "Arn": "arn:aws:iam::123456789012:group/Developers",
        "CreateDate": "2026-06-15T10:42:11+00:00"
    }
}

Attach a managed policy so members inherit those permissions:

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

This command prints nothing on success. Now add an existing user to the group:

aws iam add-user-to-group \
  --group-name Developers \
  --user-name jane.doe

Confirm who is in the group:

aws iam get-group --group-name Developers

Output:

{
    "Users": [
        {
            "Path": "/",
            "UserName": "jane.doe",
            "UserId": "AIDA0A1B2C3D4E5F6G7H8",
            "Arn": "arn:aws:iam::123456789012:user/jane.doe",
            "CreateDate": "2026-05-02T08:15:00+00:00"
        }
    ],
    "Group": {
        "Path": "/",
        "GroupName": "Developers",
        "GroupId": "AGPA0A1B2C3D4E5F6G7H8",
        "Arn": "arn:aws:iam::123456789012:group/Developers"
    }
}

To remove a user, use aws iam remove-user-from-group --group-name Developers --user-name jane.doe.

Defining a group as code

For repeatable, reviewable setups, define groups in infrastructure as code. CloudFormation example:

Resources:
  DevelopersGroup:
    Type: AWS::IAM::Group
    Properties:
      GroupName: Developers
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Tip: There is no cost for IAM groups, users, roles, or policies — IAM is free. The only “cost” is operational: messy per-user permissions are hard to audit and a common source of over-privileged access. Groups are the cheap way to stay clean.

Best practices

Manage permissions through groups, not by attaching policies to individual users — it scales and is far easier to audit.
Name groups by job function (Developers, Billing, ReadOnly) so the intended access is obvious.
Follow least privilege: give each group only the policies its members truly need.
Use groups only for human users; use IAM roles for applications, EC2 instances, and cross-account access.
Review group membership and attached policies regularly, and remove users when they change roles or leave.
Prefer well-scoped customer-managed policies on groups over broad AWS-managed ones when you need tighter control.