What is the difference between groups and paths in IAM?

Question

So, users can be grouped by groups and paths. Why we need paths if we have groups? What is the extra advantage of having paths?

Answer 1

My guess is that usage of a user path is more suited for large organizations, or advanced users, that would normally rely on CloudFormation and/or the AWS CLI for managing their AWS resources. clarity for paths -> https://stackoverflow.com/a/46325139/13126651

How i see groups v/s path.

• There might be permissions(more than one) that applies to dev group and specific users
• We don't want specific users to use dev group policies, however dev group needs some permissions that applies to dev users too.
• i would create a dev path
• they can be given access by creating a policy to use that specific service for users in the path.
• In this way adding specific user to dev path, allows to give permission without adding them to dev group.
• If in the future that dev permission needs to be removed, just delete the path.

Example Policy using path

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "iam:GetContextKeysForPrincipalPolicy",
                "iam:SimulatePrincipalPolicy"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/Department/Development/*"
        }
    ]
}

groups :

An IAM user group is a collection of IAM users. User groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users. For example, you could have a user group called Admins and give that user group the types of permissions that administrators typically need. Any user in that user group automatically has the permissions that are assigned to the user group. If a new user joins your organization and needs administrator privileges, you can assign the appropriate permissions by adding the user to that admin group

Path :

You can use a single path, or nest multiple paths as a folder structure. For example, you could use the nested path /division_abc/subdivision_xyz/product_1234/engineering/ to match your company organizational structure. You could then create a policy to allow all users in that path to access the policy simulator API.

The key difference

If you have a user and user group in the same path, IAM doesn't automatically put the user in that user group. For example, you might create a Developers user group and specify the path as /division_abc/subdivision_xyz/product_1234/engineering/. If you create a user named Bob and add the same path to him, this doesn't automatically put Bob in the Developers user group. IAM doesn't enforce any boundaries between users or user groups based on their paths.