AWS IAM Role vs Group

Question

The AWS official site reads role as a collection of permissions and group as a collection of users. But still they look the same to me. You attach policies to groups or roles, and then assign groups or roles to a user. What exactly are the differences between role and group?

Apostatize

Answer 1

AWS Groups are the standard groups which you can consider as collection of several users and a user can belong to multiple groups.

AWS IAM Roles are all together different species; they operate like individual users except that they work mostly towards the impersonation style and perform communication with AWS API calls without specifying the credentials.

Given that IAM Roles are little different, I am emphasizing only that. There are several types of IAM Roles like EC2 IAM Roles, Lambda etc. If you consider, you can launch an EC2 instance with an EC2 IAM Role; hence forth any AWS API related communication wouldn't require any AWS Access Key or Secret key for authentication rather can call the APIs directly (however the long answer is - it uses STS and continuously recycles the credentials behind the scenes); the privileges or permissions of what it can do is determined by the IAM Policies attached to the IAM Role.

Lambda IAM Role works exactly the same, except that only Lambda function can use the Lambda IAM Role etc.

Phil

This is incorrect. An EC2 instance with an IAM role still uses access keys; but these are retrieved (automatically using the SDK, or manually otherwise) from instance metadata, and are very short lived. More details at docs.aws.amazon.com/AWSEC2/latest/UserGuide/… – Elodia

thank you Chris - I have updated the answer. My original intension was to highlight the not having the need to need to meddle with the Access Key and Secret. – Phil

@Elodia So.. In AWS world, Can I say, one cannot apply policy(say S3FullAccess) to a service(say EC2) to access another service(say S3)? – Tweedy

@overexchange: That is exactly backwards. You can create an EC2 role, assign it to an instance, and associate one or more policies with that role. That instance will then be able to do whatever that role grants - so in your example, if the role associated with the ec2 instance has S3FullAccess, then the EC2 instance will have full S3 access. – Elodia

@NaveenVijay To me, both Role & Group look equivalent. Both are used to represent a set of policies. While on one hand, a number of 'Trusted Entities' are assigned one or more Role, on the other hand, a number of 'Users' are assigned to one or more Groups. What Groups are for Users, the Roles are for Trusted Entities. – Scant

@KenRussell Except that Role can do more than that. To me it looks like Role covers all use-case of Group. – Sahib

Answer 2

Short answer for googlers: you can't assign role to user.

• group is a bunch of users with the same policies
• role is a preset of policies for service(s)

Users can asume roles according to AWS docs:

Assuming a Role

Natural

you can't assign role to user was the key sentence that made me realize the difference between them. Role is a way to provide permissions to someone (a customer, supplier, contractor, employee, an EC2 instance, some external application outside AWS trying to consume your services) without creating a user for it. – Odrick

To me it seems like IAM Roles cover all use case of IAM Groups. Whenever you want an IAM Group for a user, just create an IAM Role with same policy and let the user assume the Role. Why do we need IAM Group then? – Sahib

what is the difference between "assigning" a role to a user and a user "assuming" a role? I wouldn't say that you could assign a group to a user either. – Devise

@Devise assuming is a temporary manual action while adding to a group is permanent – Natural

Answer 3

Users: End User (Think People).

Groups: A collection of users under one set of permissions (permission as policy). As per IAM standards we create groups with permissions and then assign user to that group.

Role: you create roles and assign them to AWS resource (AWS resource example can be a customer, supplier, contractor, employee, an EC2 instance, some external application outside AWS) but remember you can't assign role to user.

It’s not only users who will login, sometimes applications need access to AWS resources. For example, an EC2 instance might need to access one or more S3 buckets. Then, an IAM role needs to be created and attached to the EC2 instance. That role can be re-used by different EC2 instances.

Remember : Groups are for living. Roles are for non-living.

Glassy

What do you assign roles to then? – Sunsunbaked

Point 3, you create a role and assign to AWS resource. – Glassy

Sorry, I meant to comment no the above answer, not yours. Now that I see yours, it's clear. – Sunsunbaked

Aren't "customer, supplier, contractor, employee" ==IAM users? If not, how? – Landy

@Landy yes you are correct. Roles can't be assigned to users. It can be assigned to aws Services. – Flatulent

Answer 4

I think of an AWS Role as a kind of 'sudo', where each AWS Role can temporarily provide a very specific set of elevated privileges, but without needing the elevated credentials. I get the impression that like sudo, AWS Roles try to prevent privileged actions being used accidentally. I'd be interested to hear if others agree with this analogy.

Presentational

I think this is the best description of it that I have seen so far. – Popgun

Answer 5

Groups:

Intended to represent human users created within IAM who need identical policies.

Ex. Dev 1 - Dev 8 are all developers, and all need access to create servers.

This is similar to traditional user management.

---

Roles:

Roles hand out automatic credentials and permissions.

This makes it good for two things:

1. Giving permissions to non-humans, such as services / applications.

Ex. EC2 of type A needs access to S3 of type B.

This is the most common use case for making systems.

2. Giving permissions to federated / outside users & groups.

Ex. Contractor A @ Outside Company A needs access to your Server A.

Authorizations from identity providers are mapped to your IAM role(s), NOT users or groups.

This is technically point 1, as IdP(s) need some way to manage human users created outside IAM!

• Note: I've used Jumpcloud's Article & AWS's Documentation to gather this information. The terms "Group", "Role", and "User" become overloaded in context to SSO+IdP, and IAM.

Here's an image showing how they map roles:

Hopefully this provides clarity to the answers above.

---

Note: There is a way of assigning Roles to normal IAM Users & Groups, but it appears to be bad practice.

Exultation

Answer 6

Please note that Groups are specific to local IAM users, which are not federated, and local IAM user logs do not show who has done the actions (i.e.., multiple people or applications could use the same long-term secret/access keys, and there is no record of which entity used them). If you must use local IAM users, you can place them into IAM Groups. Where this can be especially useful is to serve as a boundary -- you could place a deny policy on the group, restricting access to specific services or actions, and that deny policy will be applied to all users in the Group.

Conversely, roles can be federated, whereas local IAM users are not. You might create an on-premises AD group that serves as a member container, for example, and then the members of that AD group (and only they) can use the role that the AD group correlates to, with whatever allow or deny policies and/or permissions boundaries you've applied to the role. (Here is a link explaining the AWS ADFS federation.)

Importantly, roles allow for temporary session credentials (which is a best security practice), as their session tokens expire after a maximum of 12 hours. Equally importantly, roles do show in the logs which of the AD members with access to use the role actually did the action. You'll find this tacked to the end of the role ARN in the logs (e.g., a user ID). CloudTrail would be one of several services that indicate user activity. This is important from a logging standpoint.

Dave

Answer 7

Understanding IAM roles vs IAM groups (IAM indentities) is very important foundational concept . Its important to look at difference between IAM role and IAM user as essentially group is just a bunch of users performing similar functions (eg. group of developers, QA's etc.) Roles are not uniquely associated with one person (user), they can be assumed by user,resource or service who needs it to perform task at that point of time (session). Roles do not provide long-term credentials like password or access keys. Best practice recommendation is to require workloads to use temporary credentials with IAM roles to access AWS

Please refer to link below for more clarity: https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

Equiponderance

Answer 8

I was confused all the time about the difference between these two functions.

In short,

Role is like a tag with all the preset policies that can attach on IAM users/groups or AWS services. IAM users share the same account with the account root user (Admin) but with assigned permissions by the root user to use AWS resources within that account.

Therefore, IAM users can directly interact with AWS services; whereas IAM roles cannot make direct requests to AWS services, they are meant to be assumed by authorised entities like an IAM user or an instance. https://aws.amazon.com/iam/faqs/

Oven

Answer 9

Only one IAM Role can be assumed at a time! And there are several situations which fits exactly this kind of permission.

Read the faq about: How many IAM roles can I assume?

The underlaying tool in use is "Permission" in both of the use cases namely: Group and IAM Role.

Group or IAM Role --> Has Policy --> Policy defines permisions --> Permissions are assigned to a Group or IAM Role.

Gavrilla