An IAM user in AWS represents a real-world entity that needs access to AWS resources, like a person or an application. The user can be assigned permissions that determine which parts of AWS he/she/it can access.

An IAM role is similar in the sense that it too is associated with certain permissions that determine access within AWS. However, it’s not intended to be a representation of a single real-world entity (like IAM users). Instead, it’s designed to be assumed by a user, service or application, in order to get temporary access to AWS resources.

IAM roles are of 4 types, primarily differentiated by who or what can assume the role:

• Service Role
• Service-Linked Role
• Role for Cross-Account Access
• Role for Identity Provider Access

Service Role

A service role is assumed by an AWS service. When creating one of these, you can specify which AWS service you want to be able to assume this role & then assign the permissions that the service would have when it assumes the role.

The most well-known example of a service role is the IAM role in an EC2 instance’s instance profile. When an instance is configured to assume a role at runtime, the applications running inside the instance can perform any actions on any AWS services allowed by the role.

Service-Linked Role

These are AWS-managed roles that are tied to specific AWS services & grant them a very specific predefined set of permissions, for use in very particular use cases. The permission policies applied to service-linked roles are immutable.

One example is the role assumed by the autoscaling service, which grants it all the permissions necessary to perform autoscaling actions on all AWS services that support autoscaling:

Role for Cross-Account Access

As the name implies, cross-account roles allow entities (users, apps, etc.) in one AWS account to assume an IAM role in another AWS account, in order to access resources in that account.

The account that contains the AWS resources to be accessed, is called the TRUSTING account & the AWS account that contains the entities that need access, is called the TRUSTED account. They’re called so because the trusting account is trusting entities in the trusted account.

Role for Identity Provider Access

These provide access to users federated by external web identity providers (Amazon, Facebook, Google), OpenID Connect (OIDC) providers & SAML 2.0 providers.