2 Users, Groups, and Roles

How IAM identities are used

AWS Identity and Access Management (IAM) uses identities to determine who or what can access AWS resources. Choose an identity type according to whether access is for an individual, shared among a set of users, or obtained temporarily by a person, application, or AWS service.

Individual access with IAM users

An IAM user is an identity in one AWS account with its own credentials and permissions. It can represent a person or, in limited cases, a workload that cannot use a role. New users have no permissions by default.

For human access, prefer federation and temporary credentials where possible rather than IAM users with long-term credentials. Use an IAM user when a specific requirement cannot be met with federation or a role. Create only the credentials the user needs: for example, a console-only user does not need access keys. Enable MFA for human access and remove credentials that are no longer needed.

To create a user in the IAM console, open Users and choose Create user. Give the user a clear name, select only the access they require, and grant permissions through an appropriate group when possible. After creation, review the user’s credentials, group memberships, and MFA status.

Shared permissions with IAM groups

An IAM user group is a collection of IAM users. Attach permissions policies to a group to give its members common permissions. Users can belong to multiple groups, but groups cannot contain other groups, roles, or non-user identities. Groups organize user permissions; they are not identities that sign in or assume roles.

For example, a Developers group might receive permissions needed for development tasks. Adding a user to the group gives that user the group’s permissions; removing the user revokes those group-based permissions.

To create a group in the IAM console, open User groups and choose Create group. Name it for a job function, select users to include, and attach only the policies needed for that function. You can create the group first and add users later.

Temporary access with IAM roles

An IAM role has permissions but is not tied to one person and does not have standard long-term passwords or access keys. A trusted person, application, or AWS service assumes the role and receives temporary security credentials for a session.

Roles are commonly used when an AWS service, such as an application running on Amazon EC2, needs access to another AWS service; when a person needs temporary or elevated access for a task; when a user or workload in another AWS account needs authorized access; or when federated users need to access AWS.

A role has two important parts: its trust policy specifies who or what may assume it, and its permissions policy specifies what the role session may do. Limit both to the required principals, actions, and resources.

To create a role in the IAM console, open Roles and choose Create role. Select the appropriate trusted entity or use case, define the needed permissions, and give the role a descriptive name. Review both policies. For an AWS service role, verify that the intended service is trusted; for cross-account access, verify the trusted account or principal.

Choosing an identity type

Choose an IAM user only when a person needs an individual IAM identity in an account and federation is unsuitable; the user has individual credentials and permissions. Choose an IAM group when several IAM users need the same permissions, so those permissions can be managed in one place. Choose an IAM role when a service, application, federated user, or person needs temporary access; the trusted entity assumes it and receives temporary credentials.

A role is not a group: a group organizes IAM users and passes them shared permissions, while a role is assumed to obtain a temporary session. A role is also not simply a user with a different name; it is designed for assumable access rather than permanent credentials belonging to one identity.

Applying IAM access patterns

Apply the identity choices to common access needs:

• An analyst needs the same read-only access as other analysts: Create or use an analyst group, attach appropriate least-privilege permissions, and add the analyst as a user—or use the organization’s federation solution for human access.

• An application on an AWS compute service must read a particular S3 bucket: Create a role trusted by that service and grant only the required bucket access. Do not embed long-term IAM user keys in the application.

• A contractor in another AWS account needs temporary access to a resource: Use a role with a narrowly defined trust policy and permissions policy, and verify the cross-account trust configuration.

• A user changes jobs: Remove the user from groups no longer needed and add them to appropriate groups. Also review any direct permissions and role access.

Managing access responsibly

Users are individual IAM identities with credentials; for people, federation and temporary credentials are preferred where possible. Groups collect IAM users so shared permissions can be managed together, and groups cannot contain other groups or roles. Roles provide permissions to trusted entities through temporary sessions and are the usual choice for AWS services, workloads, federation, and cross-account access.

Grant only the access required, review who can assume each role, and routinely remove access that is no longer needed.