AWS Identity and Access Management
User Guide

Roles Terms and Concepts

Here are some basic terms to help you get started with roles.


A set of permissions that grant access to actions and resources in AWS. These permissions are attached to the role, not to an IAM user or group. Roles can be used by the following:

  • An IAM user in the same AWS account as the role

  • An IAM user in a different AWS account as the role

  • A web service offered by AWS such as Amazon Elastic Compute Cloud (Amazon EC2)

  • An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker.


AWS Service Role

A role that a service assumes to perform actions on your behalf. When you set up most AWS service environments, you must define a role for the service to assume. This service role must include all the permissions required for the service to access the AWS resources that it needs. Service roles vary from service to service, but many allow you to choose your permissions, as long as you meet the documented requirements for that service. You can create, modify, and delete a service role from within IAM.

AWS Service Role for an EC2 Instance

A special type of service role that a service assumes to launch an Amazon EC2 instance that runs your application. This role is assigned to the EC2 instance when it is launched. AWS automatically provides temporary security credentials that are attached to the role and then makes them available for the EC2 instance to use on behalf of its applications. For details about using a service role for an EC2 instance, see Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.

AWS Service-Linked Role

A unique type of service role that is linked directly to the service. This service-linked role is required by some AWS services. The role is predefined by the service and includes all the permissions that the service requires. This makes setting up a service easier because you don’t have to manually add the necessary permissions. You can create this role from within IAM, but because the role is linked to the service, you cannot customize the role within IAM. You can manage and delete these roles only through the linked service. For information about which services support service-linked roles, see AWS Services That Work with IAM and look for the services that have Yes in the Service-Linked Role column.


The granting of permission to someone to allow access to resources that you control. Delegation involves setting up a trust between the account that owns the resource (the trusting account), and the account that contains the users that need to access the resource (the trusted account). The trusted and trusting accounts can be any of the following:

  • The same account.

  • Two accounts that are both under your (organization's) control.

  • Two accounts owned by different organizations.

To delegate permission to access a resource, you create an IAM role that has two policies attached. The permissions policy grants the user of the role the needed permissions to carry out the intended tasks on the resource. The trust policy specifies which trusted accounts are allowed to grant its users permissions to assume the role.

Keep in mind that you cannot specify a wildcard (*) as a principal in the role's trust policy. The trust policy on the role in the trusting account is one-half of the permissions. The other half is a permissions policy attached to the user in the trusted account that allows that user to switch to, or assume the role. A user who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role. When the user exits, or stops using the role, the original user permissions are restored. An additional parameter called external ID helps ensure secure use of roles between accounts that are not controlled by the same organization.


The creation of a trust relationship between an external identity provider and AWS. Users can sign in to a web identity provider, such as Login with Amazon, Facebook, Google, or any IdP that is compatible with OpenID Connect (OIDC). Users can also sign in to an enterprise identity system that is compatible with Security Assertion Markup Language (SAML) 2.0, such as Microsoft Active Directory Federation Services. When you use OIDC and SAML 2.0 to configure a trust relationship between these external identity providers and AWS, the user is assigned to an IAM role and receives temporary credentials that enable the user to access your AWS resources.


A document in JSON format in which you define the permissions for a role. The document is written according to the rules of the IAM policy language.

When you create a role, you create two separate policies for it: a trust policy, which specifies who is allowed to assume the role (the trusted entity, or principal; see the next term), and the permissions policy, which defines what actions and resources the principal is allowed to use.


An entity in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role. You can grant permissions to access a resource in one of two ways:

  • You can attach a permissions policy to a user (directly, or indirectly through a group) or to a role.

  • For those services that support resource-based policies, you can identify the principal in the Principal element of a policy attached to the resource.

If you reference an AWS account as principal, it generally means any principal defined within that account.


You cannot use a wildcard (*) in the Principal element in a role's trust policy.

Role for cross-account access

Granting access to resources in one account to a trusted principal in a different account. Roles are the primary way to grant cross-account access. However, with some of the web services offered by AWS you can attach a policy directly to a resource (instead of using a role as a proxy). These are called resource-based policies, and you can use them to grant principals in another AWS account access to the resource. The following services support resource-based policies for the specified resources: Amazon Simple Storage Service (S3) buckets, Amazon Glacier vaults, Amazon Simple Notification Service (SNS) topics, and Amazon Simple Queue Service (SQS) queues. For more information, see How IAM Roles Differ from Resource-based Policies.