How to Manage IAM Groups Using the AWS CLI (Step-by-Step)

If you have ever stared at an AWS account wondering why a developer has access to something they should not, the answer is almost always sitting inside IAM groups. Groups are where permissions live in AWS at the team level. Get them right and your account runs clean. Get them wrong and you end up with a billing surprise or a security incident that takes a week to untangle.

This guide walks through every IAM group operation you can run from the AWS CLI: listing existing groups, creating a new one, attaching a managed policy, verifying the attachment, detaching the policy, and finally deleting the group. Every command appears in the exact order you would use in a real environment, with an accounting department as the working example from start to finish.

What You’ll Walk Out With

The exact AWS CLI command to list all IAM groups in your account
How to create a new IAM group from the terminal in under 30 seconds
The right way to attach an AWS managed policy to a group using the policy ARN
How to verify group policy assignments without ever opening the AWS console
The correct order of operations for safely detaching a policy before deleting a group
Why IAM groups matter for AWS security, audits, and team access control
How CLI commands map directly to what you see in the AWS Management Console
Not sure which AWS or cloud skill to build next? finder.platformproof.com points you to the right path based on where you are right now.

Why IAM Groups Exist

IAM stands for Identity and Access Management. It is the AWS service that controls who can do what inside your AWS account. Every developer, every application, every automated process that touches AWS needs an IAM identity, and that identity needs permissions attached to it before it can do anything useful.

The simplest approach is to attach permissions directly to each individual IAM user. That approach works fine for one or two people. It breaks down the moment you have a team. If you have ten developers who all need read access to S3, you would attach the same policy to ten separate user accounts. When you need to update that policy, you change it in ten places. Miss one and you have an inconsistency that will surface at the worst possible moment.

An IAM group solves this by letting you attach policies to the group instead of to individuals. Every user in the group automatically inherits the permissions from every policy on that group. Add someone to the group and they instantly have the right access. Remove them and the access is gone. No hunting through individual accounts, no forgotten permissions sitting on a user who left the company six months ago.

In the video tutorial, the AWS account starts with two groups: HR and marketing. The tutorial creates a third group called accounting, gives it access to DynamoDB (Amazon’s managed NoSQL database service), then walks through the full cleanup process as the accounting department is being outsourced and the group needs to be retired.

Prerequisites Before Running These Commands

Before any of these commands will work, you need the AWS CLI installed and configured. Running aws configure walks you through entering your Access Key ID, Secret Access Key, default region, and preferred output format. If you have already done this for other AWS services, you are ready.

You also need an IAM user or role that has permission to manage IAM groups. In a production environment this means your identity needs the following permissions: iam:CreateGroup, iam:DeleteGroup, iam:AttachGroupPolicy, iam:DetachGroupPolicy, iam:ListGroups, and iam:ListAttachedGroupPolicies. A user with AdministratorAccess or IAMFullAccess will have all of these by default.

Step 1: List Your Existing IAM Groups

Before you create anything new, check what already exists. The command to list all IAM groups in your account is:

aws iam list-groups

The response is a JSON object containing every group in your account. Each entry includes the group name, path, group ID, Amazon Resource Name (ARN), and the date the group was created. In the tutorial this returns two groups: HR and marketing. Those same groups are visible simultaneously in the AWS Management Console, confirming the CLI and the console are reading from the same source.

This command is useful beyond just curiosity. If you are scripting IAM setup across multiple AWS accounts, listing groups first gives you a baseline you can compare against your expected state. Any difference between actual and expected flags configuration drift that needs investigation before anything else happens.

Step 2: Create a New IAM Group

Once you have confirmed your baseline, creating a new group is a single command:

aws iam create-group –group-name accounting

Replace “accounting” with whatever name fits your organization. Group names must be unique within your AWS account and can contain letters, numbers, hyphens, underscores, and periods. The name is case-sensitive, so “Accounting” and “accounting” would be two different groups.

A successful response comes back with three key pieces of information: the ARN for the new group, the unique Group ID, and the creation timestamp. In the tutorial the response confirms the accounting group was created, and refreshing the AWS Management Console immediately shows it appearing in the list, going from two groups to three.

At this point the accounting group exists but has zero policies attached. Any user added to this group right now would not be able to do anything in AWS. The group is just a container waiting for permissions.

Running aws iam list-groups again at this point confirms the new group appears as the third entry in the response. This verification step is a habit worth building: confirm that commands succeeded before moving on, especially in any kind of automated script.

Step 3: Attach a Policy to the Group

Policies are where the actual permissions live. A group without a policy is a group that cannot do anything. To give the accounting group real access, you attach a policy using that policy’s Amazon Resource Name (ARN).

In the tutorial the policy being attached is AmazonDynamoDBFullAccess. The scenario is that the accounting team needs full access to DynamoDB, the AWS managed NoSQL database service. The ARN for this managed policy is:

arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess

The full command to attach this policy to the accounting group:

aws iam attach-group-policy –policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess –group-name accounting

A successful attach returns nothing at all. That silence is intentional in CLI design. No output means it worked. If something went wrong, you get an error message. The empty response and the returned prompt are your confirmation.

If you need to look up the exact ARN for a policy before attaching it, run aws iam list-policies –scope AWS. This returns every AWS managed policy with its ARN. It is a long list, so pipe it through grep to find what you need: aws iam list-policies –scope AWS | grep DynamoDB

Step 4: Verify the Policy Is Actually Attached

After attaching a policy, confirm it landed on the group before moving on. The command:

aws iam list-attached-group-policies –group-name accounting

This returns every policy currently attached to the specified group. After the attach command in the tutorial, this confirms AmazonDynamoDBFullAccess is listed. Clicking refresh in the AWS Management Console and opening the accounting group shows the same policy listed there as well.

Including this verification in your scripts means you can confirm IAM changes without a human needing to check the console. A deployment script that attaches policies should immediately verify the attach worked. That is the difference between automation you trust and automation you are hoping is working correctly.

Not sure which cloud skill to build next?

The Platform Proof Finder helps you figure out which AWS certification, skill, or income path fits where you are right now. Try it at finder.platformproof.com.

Step 5: Detach the Policy Before You Delete

This is where real-world IAM management gets interesting. In the tutorial the scenario changes: the accounting department is being outsourced, so the accounting group needs to be retired. Before you can delete an IAM group, you must remove all policies attached to it. AWS will return an error if you try to delete a group that still has policies.

The detach command mirrors the attach command:

aws iam detach-group-policy –policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess –group-name accounting

The tutorial shows a moment worth noting here: the presenter starts typing the command, makes a typo, catches it, corrects it, and then realizes they forgot the required –policy-arn flag entirely. They fix it, add the ARN, and it works. This is a very normal experience with the AWS CLI. The habit to develop is to read the error message carefully before retrying, because the error usually tells you exactly what is missing.

After detaching, running aws iam list-attached-group-policies –group-name accounting confirms the policies list comes back empty. The console refresh shows the same result. The group is clean and ready to delete.

Step 6: Delete the IAM Group

With all policies detached, removing the group is one command:

aws iam delete-group –group-name accounting

Like the detach command, a successful delete returns silence. Running aws iam list-groups one final time confirms the count is back to two: HR and marketing. The accounting group is gone.

One important addition for real-world use: AWS will also return an error if you try to delete a group that still has users in it. The tutorial skips this because the accounting group was freshly created and never had any users added. In production, where groups have real members, you need to run aws iam get-group –group-name accounting first to see who is currently in the group, then remove each member with aws iam remove-user-from-group –user-name username –group-name accounting before running the delete.

The Complete Command Sequence

Here is every command in the order you would run them to take an IAM group from creation through full teardown:

1. See what groups currently exist:
aws iam list-groups

2. Create the new group:
aws iam create-group –group-name accounting

3. Confirm the group was created:
aws iam list-groups

4. Look up the policy ARN if needed:
aws iam list-policies –scope AWS | grep DynamoDB

5. Attach the policy to the group:
aws iam attach-group-policy –policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess –group-name accounting

6. Verify the policy was attached:
aws iam list-attached-group-policies –group-name accounting

7. When cleaning up, detach all policies first:
aws iam detach-group-policy –policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess –group-name accounting

8. Confirm the detach worked:
aws iam list-attached-group-policies –group-name accounting

9. Check for users still in the group and remove them if present:
aws iam get-group –group-name accounting
aws iam remove-user-from-group –user-name username –group-name accounting

10. Delete the group:
aws iam delete-group –group-name accounting

11. Confirm the group is gone:
aws iam list-groups

Honest Drawbacks of Managing IAM Groups via CLI

The AWS CLI is powerful, but IAM group management through it has real friction points you should know going in.

ARNs are long and error-prone. Every policy attach and detach command requires the full ARN. AWS managed policy ARNs follow the format arn:aws:iam::aws:policy/PolicyName, but you still have to know the exact policy name and cannot abbreviate it. A single typo returns an error rather than a helpful suggestion. Keeping a short reference file of commonly used policy ARNs saves repeated lookups.

Silent success is easy to misread. Commands that succeed return no output. If you come from tools that print “Done” or show a confirmation screen, the empty prompt after a successful IAM command feels wrong. The habit of running a verification command after every change becomes essential, especially inside scripts where you cannot visually inspect what happened.

Delete order is enforced and unforgiving. You must detach all policies before deleting a group, and remove all users before detaching policies. The CLI will tell you what went wrong, but it will not clean up for you automatically. In a scripted teardown workflow, your sequence has to handle these dependencies explicitly or the script will fail partway through and leave things in a half-deleted state.

No bulk attach operations exist. If you want to attach three policies to a group, you run the attach command three separate times. There is no single command that attaches multiple policies at once. For large-scale IAM management across many accounts, tools like AWS CloudFormation or Terraform handle bulk operations more cleanly than raw CLI commands strung together.

IAM changes are global, not regional. IAM is a global AWS service, which means group changes you make affect your entire account across all regions. This is generally what you want, but it means there is no regional sandbox to test changes in before they are live everywhere.

Find Your X

AWS IAM is one of the highest-tested domains across AWS certifications, and it is one of the skills that appears in almost every cloud job description regardless of whether the role is developer, sysadmin, or architect. Once you can manage groups confidently from the CLI, you are closer to a passing score on the AWS Certified Solutions Architect Associate or SysOps Administrator exam, and closer to being the person on your team who can actually explain why permissions are set up the way they are. If you are trying to figure out where to go next with AWS or cloud skills, the Platform Proof Finder gives you a straight answer based on your actual situation. Try it at finder.platformproof.com.

Frequently Asked Questions

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

An IAM group is a collection of IAM users, and policies attached to the group apply to all users in it. An IAM role is a set of permissions that any identity can assume temporarily, including users, services, or applications. Groups are for managing ongoing permissions for human users. Roles are for temporary access and for giving AWS services like Lambda or EC2 permission to interact with other services without embedding credentials.

Can an IAM user belong to more than one group?

Yes. A single IAM user can be a member of up to 10 IAM groups. Their effective permissions are the union of all policies from all their groups plus any policies attached directly to their user account. This makes it possible to model access along multiple dimensions. For example, a user in both the “developers” group and the “read-only-billing” group gets the combined permissions of both groups.

What happens to users in a group when I delete the group?

AWS will not let you delete a group that still has users in it. The delete command returns an error. You have to remove all users from the group first using aws iam remove-user-from-group, then run the delete. The users themselves are not deleted or harmed in any way. Only their membership in that group is removed, meaning they lose the permissions that came from that group.

How many policies can I attach to a single IAM group?

The default limit is 10 managed policies per IAM group. This is a soft limit that AWS Support can increase on request. In practice, well-designed IAM setups rarely need more than a handful of policies per group, because good policies are scoped tightly enough that a small number of them covers what a team of users actually needs to do.

How do I see all users currently in a group from the CLI?

Run aws iam get-group –group-name groupname. This returns both the group metadata and a complete list of all IAM users currently in that group. This is the command to run before any delete operation to confirm there are no users you need to reassign to another group before removing them.

Can I nest IAM groups inside other IAM groups?

No. AWS IAM groups cannot contain other groups. A group can only contain IAM users. If you need a hierarchical permission model, the typical approach is to use IAM roles with permission boundaries for fine-grained control within an account, or AWS Organizations with Service Control Policies at the account level for controls that span multiple accounts.

What is the difference between a managed policy and an inline policy for groups?

A managed policy is a standalone policy document that you create independently and then attach to any number of groups, users, or roles. It has its own ARN and can be reused across multiple identities. An inline policy is embedded directly inside one specific group and cannot be shared or reused. AWS recommends managed policies for group permissions because they are easier to audit, version, and update. Inline policies are best saved for cases where a policy is so specific to one group that sharing it would not make sense.

Do I need to understand IAM groups to pass AWS certification exams?

Yes. IAM is one of the most consistently tested domains across AWS certifications. The AWS Certified Cloud Practitioner tests basic IAM concepts. The AWS Certified Solutions Architect Associate, SysOps Administrator, and Developer Associate exams all go deeper into IAM group management, policy evaluation logic, and permission boundaries. Being able to work through IAM group operations from the CLI means you understand what is actually happening beneath the console, which is the depth that AWS exam questions are written to test.

Sources

AWS CLI Command Reference: aws iam commands — AWS documentation
AWS IAM User Guide: Managing IAM Groups — AWS documentation
Original video: Mastering AWS featuring Identity and Access Management (2018)
AmazonDynamoDBFullAccess managed policy — AWS IAM console