Get to Grips with AWS IAM Roles: Terms, Concepts, and Examples

Get to Grips with AWS IAM Roles: Terms, Concepts, and Examples

Play this article

AWS IAM roles are an essential part of managing access to AWS resources securely. IAM roles allow you to define a set of permissions for making AWS service requests without having to provide permanent credentials like passwords or access keys. Instead, IAM roles can be assumed by IAM users, AWS services, or applications that need temporary security credentials to access AWS resources.

In this article, we will discuss the terms, concepts, and examples related to AWS IAM roles, so you can get a better understanding of how to use them effectively in your AWS environment.

aws iam infographic

A Brief Overview of AWS Identity and Access Management

To begin understanding how roles operate and their potential benefits, we first must establish a foundation of AWS Identity and Access Management.

Amazon Resource Identifiers

To make AWS IAM possible, there needs to be a concept of how resources are uniquely identified. This is done via Amazon Resource Identifiers or short ARNs. Each of those ARN strings consists of several parts, including the service, AWS region, and the account ID of the resource.

The segments of an Amazon Resource Name (ARN), including partition, service, region, account-id and resource-id.

ARNs are used not only in IAM but in various contexts, including AWS CloudFormation templates, and AWS service APIs. They allow you to specify and authorize access to resources in a secure and standardized way.

Let’s have a look at different examples:

  • An Amazon S3 bucket: arn:aws:s3:::my-bucket

  • An Amazon EC2 instance: arn:aws:ec2:eu-west-1:123456789012:instance/i-01234567890abcdef

  • An Amazon RDS database: arn:aws:rds:eu-west-1:123456789012:db:mydatabase

  • An Amazon DynamoDB table: arn:aws:dynamodb:eu-west-1:123456789012:table/mytable

The service is the first part (e.g. s3, ec2, rds, dynamodb). After the general prefix arn:aws which just indicates that it’s an ARN for “global” AWS (there’s also AWS China or AWS CN, which is strictly separated and identified with the prefix arn:aws-cn ).

The region is specified by the second part (e.g. us-east-1), and the account ID is specified by the third part (e.g. 123456789012). Note that some services like S3 are not bound to a single region even though their resources may live in one region. In this case, the region identifier is left blank.

The specific resource is identified by the remaining parts of the ARN, which can include the resource name or identifier. For example, the ARN for an Amazon DynamoDB table includes the table name (mytable) after the table/ prefix. This allows you to uniquely identify the table and authorize access to it using IAM policies.

Users

Users are identities that can interact with AWS and its APIs. They consist of a name and credentials and their AWS access type(s). It’s recommendable to use speaking, “friendly” names for your users.

The access type can be either programmatic (via access keys that can be used to make calls to the AWS API), via the AWS Management Console (via password), or both.

For each account, there is one root user, which is the owner of your account and has all privileges to manage, modify or delete all resources or even the account itself. Some configurations can only be set by the root user like changing the account name, updating payment information, or assigning the account to an organization.

💡 The best way to grant human users access to large AWS environments is to make use of federation. This allows you to make use of a dedicated service that's whole purpose is managing identities and therefore controlling access: an identity provider. A better way of directly creating IAM users in an account is to make use of AWS Identity Center. AWS Identity Center allows to create IAM users in a root account of an AWS organization, so permissions can be delegated through different accounts.

Roles

Roles have some similarities to users: it’s an identity that is associated with permissions to determine which actions can be taken at AWS. However, roles are not associated with a single person but can be assumed by anyone or anything who needs it.

This includes AWS service principals that are used for example for Lambda functions or container agents at ECS.

Groups

With increasing users of an AWS account, maintaining individual permissions can become tedious. It’s recommendable to cluster users into dedicated permissions groups based on their requirements for their daily work.

Let’s look at a simple example, a team that consists of four different roles: administrators, developers, quality assurance, and business analysts.

Each of the roles can be put into a group for which fitting permissions are assigned.

  • administrators: having enhanced IAM permissions to create and manage users while the company or team grows, shrinks, or adapts in its structure.

  • developers: permissions to create AWS resources to build and deploy applications on AWS.

  • quality assurance: permissions to access delivery pipelines, databases, and reports.

  • business analysts: permissions to access production data and usage reports to gather detailed insights about customer behavior.

Even if not noted in this example, users can also be part of multiple groups which will then gain the commutated permissions of all of the assigned groups.

Policies

Every request to AWS goes through an enforcement check to determine if the requesting principal is authenticated and authorized for the targeted action. The decision is based on the assigned policies either directly to the IAM user or the role that is currently assumed.

A policy is an object in AWS that determines allow or deny actions for services and resources. They are mostly stored as structured JSON documents and come in different types.

Each policy comes with one or several statements that define which actions are granted to which resource under what conditions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGetObject",
      "Action": "s3:GetObject",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::mydata/*"
    }
  ]
}

Example A: This policy allows the user or group that the policy is attached to retrieve objects from the mydata bucket. The Resource element specifies the Amazon Resource Name (ARN) of the bucket, and the /* at the end of the ARN allows access to all objects in the bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIPRange",
      "Action": "*",
      "Effect": "Deny",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": ["192.0.2.0/24", "203.0.113.0/24"]
        }
      }
    }
  ]
}

Example B: This policy denies all actions on all resources for requests that originate from the specified IP ranges. The NotIpAddress condition specifies the IP ranges to be denied, and the aws:SourceIp value specifies the source IP address of the request.

Let’s have a detailed look at each of the elements of our two example policies:

  • Version: specifying the version of the policy language you want to use. The latest one is 2012-10-17 and you shouldn’t use a previous version.

  • Statement: a container holding one or several items that define the permissions.

  • Effect: stating whether actions are granted (allow) or denied (deny). A deny statement always overwrites allow statements.

  • Principal: missing in our example, but for example used with resource-based policies to determine the account, user, or role for which the statement applies.

  • Action: a list of API actions for the target service that is either allowed or denied.

  • Resource: the resources for which the statement should allow or deny the given actions. This is not required for resource-based policies, as it’s implicitly applied to the resource to which the policy is attached.

  • Condition: specifying under which circumstances the statement should be applied. This is optional but can be used to further drill-down permissions.

Policies come with size restrictions and it’s a best practice to split your policies by the resources you’re granting access to.

Combining The Concepts

Let's quickly rephrase the fundamental concepts of IAM.

Combining Users, Groups, Roles, and Policies to build an AWS environment following the best security practices.

  • Your account is a closed bucket of resources.

  • The root user is the owner of your account.

  • Policies are a list of permissions to services and resources that can be granted to identities.

  • IAM Users should have tailor-made permissions to fulfill their daily tasks.

  • Groups are there to easily manage permissions for a small or large set of users.

Now that we have this concept in mind, let's delve deeper into the topic of roles.

Understanding IAM Roles

IAM roles allow us to group a set of permissions without having to associate them with a specific identity. Instead, we can assign these roles to one or more principals, like a user, service, or group, granting them the associated permissions.

Roles enable us to adhere to sound security protocols by assigning only the necessary permissions to users or services to carry out their functions. This is commonly referred to as the principle of least privilege.

Permissions that are granted by a role are defined via policies that are assigned to this role. These policies can be added in different ways:

  1. inline, directly included in the role definition.

  2. via an existing managed policy that gets attached to the role.

IAM Roles can have an inline policy and one or multiple attached policies.

Option two can be either a custom-managed tailor-made policy or one that is managed by AWS.

When using AWS-managed policies, it is important to be mindful that they may receive updates. This could result in conflicts with permissions or the granting of excessive permissions.

Trust Policies

Roles can be taken on by various entities such as IAM users, AWS services, AWS accounts, or even whole AWS organizations.

Trust policies define the trust relationship to principals.

AWS mandates that we specify the precise principals authorized to access them by defining a trust policy for the role.

A trust policy for a Lambda function would look like this:

{
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
}

We see the three required elements in this case:

  • Effect - by default, all permissions are denied. This policy will grant additional permissions by setting it to Allow.

  • Principal - the policy allows the principal to utilize an AWS service, specifically AWS Lambda in our case.

  • Action - the principal is granted permission to allow the service to assume the role.

Service Roles

In order to make use of most AWS services, it is necessary to create a role that includes a trust relationship with that particular service through a trust policy, as explained in the previous paragraph.

Trust policies define which principals are allowed to assume a role.

By utilizing inline or attached policies, the service can utilize the associated role and acquire all permissions defined for it.

Our trust policy permits AWS Lambda to assume the role, and our attached managed policy grants CloudWatch permissions, enabling Lambda to create log groups and write log streams.

Service-Linked Roles

AWS service-linked roles are unique IAM roles that are predefined by AWS services. These roles are designed to

  • enable specific AWS services to perform necessary actions on your behalf.

  • assuring that the service has the minimum required permissions.

Service-linked roles have a predefined set of permissions that cannot be modified.

If certain AWS services require them, AWS will usually prompt you to set up those roles when you activate or configure them.

These roles are designed to minimize the workload of permission management, as AWS will handle the role and its policies for you.

AWS offers managed policies such as the AWSLambdaBasicExecutionRole. These policies have the required permissions for the basic functions of the service in question. For instance, this policy allows access to logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents across all resources.

💡 Just a quick reminder: you don't have control over these policies because AWS has the ability to update them at any moment.

IAM PassRole

As we know, when configuring AWS services, it is necessary to provide an IAM role to the relevant service. This enables the service to function correctly and obtain the required permissions to carry out its tasks, including accessing other services if needed.

The transfer of roles must be explicitly permitted through iam:PassRole.

Passing a role to a Lambda function.

For instance, suppose we, as an IAM user, intend to generate a function. In that case, we must possess the PassRole authorizations for the role that our function will use later on.

We can strictly define which roles can be passed to services.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/lambda-role"
    }
  ]
}

If the PassRole permission is not restricted properly, an AWS environment could fall prey to privilege escalation.

Example: If a user has unrestricted pass-role permissions, they could potentially assign a role to an EC2 instance (or Lambda function or any service capable of executing code) that grants more permissions than the user themselves. Moreover, if this user can upload code to the instance, they could leverage it to increase their own permissions via the AWS SDK.

Increasing permissions via PassRole

This isn't solely an issue that impacts AWS, but rather a broader concern.

Permission Boundaries

AWS permission boundaries are a powerful tool for managing IAM users and roles. They allow you to set limits on the maximum level of permissions that can be granted. With permission boundaries, you can establish a set of overarching permissions that restrict the actions of users or roles, regardless of their individual policies. This is particularly useful when you need to delegate IAM administration to others, while still maintaining tight control over the allowed actions.

Permissions boundaries are a powerful tool for restricting effective permissions for users and roles.

When it comes to a user or role's permissions, it's important to note that the effective permissions are based on the overlap between their IAM policies and the permission boundary.

Creating Roles

We have covered the theoretical aspects of IAM fundamentals and delved into IAM roles. Now, let's move on to some practical guidance.

Using the AWS Management Console

Navigate to the roles section of AWS IAM. You'll find a list of existing roles, including the ones managed by AWS.

  1. Via a click on Create role we'll be taken to the wizard for creating new roles.

    The console will prompt us regarding the principal that can assume the role later, as we have previously learned that this is the trust policy.
    Let's take AWS service for our example. On the first page of the wizard, we can pick a specific service in the lower section. We'll go with Lambda and proceed to the next step.

  2. We now can associate our role with existing policies or generate a new one. To do so, we can utilize the search bar and input AWSLambdaBasicExecutionRole. This policy authorizes the bare minimum access to Lambda, including necessary permissions for CloudWatch, to optimize its functionality.

    By performing this action, our function is capable of creating its log group and streams, as well as appending log events.

  3. In the last step, we must specify the name of the role, and if needed, we can include tags for organizational purposes. Once we clicked on Create Role, a newly created role is available for Lambda usage.

Using the AWS CLI

At AWS, everything functions as an API, which is why it's clear that we're able to generate roles using the AWS CLI.

Be sure that your AWS CLI is configured correctly and that your credentials are exported. If you're using MFA or SSO, be sure that there's a valid session.

  1. Let's create a new JSON file named trust-policy.json that will contain our trust relationship with AWS Lambda.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
  1. Next, use the aws iam create-role command to create the IAM role using the trust policy file:
aws iam create-role --role-name lambda-role --assume-role-policy-document file://trust-policy.json
  1. We can now attach the AWSLambdaBasicExecutionRole policy to our new role via the following command:
aws iam attach-role-policy --role-name lambda-role --policy-arn arn:aws:iam::aws:policy/AWSLambdaBasicExecutionRole

We now got the exact same results as we'd have when using the AWS console.

Using Infrastructure-As-Code Tools like Terraform

Using the AWS console to create roles isn't ideal, as it involves manual steps that are difficult to replicate. This approach should only be utilized for building prototypes, experimenting with new services, or gaining familiarity with AWS. The same applies to utilizing the AWS CLI, even when incorporated into scripts, as it can never be entirely dependable.

For serious projects, it's important to go with Infrastructure-as-Code (IaC) tools like Terraform, CloudFormation, CDK, Pulumi, Serverless Framework, or any other tool you might prefer. This ensures that our procedures are reproducible and we can effortlessly oversee various environments with identical configurations.

If you are unfamiliar with IaC or haven't come across it yet, we invite you to read our introductory guide.

In our example, we'll create our Lambda role with Terraform.

  1. Install Terraform if you haven't already. On macOS, you can use the package manager homebrew and run brew install terraform to get Terraform within a few seconds.

  2. Create a new file named main.tf and add the following content:

provider "aws" {
  region = "eu-west-1"
}

resource "aws_iam_role" "example_role" {
  name = "lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "policy" {
  policy_arn = "arn:aws:iam::aws:policy/AWSLambdaBasicExecutionRole"
  role       = aws_iam_role.example_role.name
}
  1. Initialize Terraform once via terraform init. This will install the necessary AWS provider plugins that allow us to use the AWS API.

  2. Apply the configuration by running terraform apply. This will execute the creation of our role.

This brief example fails to remotely save the state of your infrastructure, which is crucial. To gain further insight into Terraform and its potential, you may refer to another blog post.

Assuming Roles

Assuming an IAM role in AWS involves a temporary transfer of permissions from one IAM role to another, including an IAM user, an IAM role, an AWS service, or even a federated user. This means we are granting access to entities.

Assuming a role to get additional permissions.

By assuming a role, the entity can carry out tasks and utilize resources with the authorized permissions, without making any permanent alterations to their own permissions.

Once the session token for the assumed role has expired, the entity's additional permissions will be revoked.

The Role Assumption Process

Let's quickly review the two necessary preconditions that must be met for a principal to assume a role.

  1. the entity needs to have permission to use the sts:AssumeRole action for the specific role they want to assume.

  2. The role must have a trust policy that allows the principal to use it.

When an entity assumes a role, the AWS Security Token Service (STS) issues temporary security credentials which include a session token.

💡 Side note: STS handles more than 400 million requests per second worldwide.

These credentials enable API requests and resource access with the permissions of the assigned role. They are temporary and have a restricted lifespan, ensuring an added level of security.

If we want to assume a role for an IAM user, we can do this via the AWS CLI:

aws sts assume-role \
  --role-arn "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
  --role-session-name "MySession"
  --duration-seconds 84600

You already know this, but in order to take on the role we're after, we need to establish a trust relationship with our IAM user. This requires us to have the following trust policy in place:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:user/<IAM_USER_NAME>"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

If everything works out correctly, the aws sts assume-role will return temporary credentials.

{
  "Credentials": {
    "AccessKeyId": "ASIAxxxxxxxxxxxx",
    "SecretAccessKey": "2666f327xxxxxxxxxxxx",
    "SessionToken": "e8bcee6czxxxxxxx",
    "Expiration": "2023-03-18T15:37:11Z"
    },
    "AssumedRoleUser": {
      "AssumedRoleId": "AROAxxxxxxxxxxxx:MyRoleSession",
      "Arn": "arn:aws:sts::<ACCOUNT_ID>:assumed-role/<ROLE_NAME>/MySession"
    }
}

We can now export the necessary environment variables.

export AWS_ACCESS_KEY_ID=ASIAxxxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=2666f327xxxxxxxxxxxx
export AWS_SESSION_TOKEN=e8bcee6czxxxxxxx

From now on, any AWS CLI commands you execute will employ the temporary credentials and permissions from the assumed role.

Using Roles with AWS Services

When utilizing AWS Lambda, there's no need to worry about managing temporary credentials since everything is automatically handled in the background.

If we use our previously created Lambda role for a new function, AWS will ensure that the function always possesses the required credentials to utilize the role.

Cross-Account Access

With IAM roles and trust relationships, we can easily enable cross-account access between two accounts.

We only need to provide the correct principal within the nested object AWS as we're granting access to another AWS account. Bonus in the example: we're only allowing entities that are using multi-factor authentication.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {
                "AWS": "123456789012"
            },
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": true
                }
            }
        }
    ]
}

We can also generate a fresh role with the required trust relationship using the role creation wizard.

Finally, our source account (or the user themselves) must receive permission to take on the role from the other account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<TARGET_ACCOUNT_ID>:role/<ROLE_NAME>"
    }
  ]
}

The user or role belonging to IAM in the source account can now take on the role in the target account to gain access to resources or carry out tasks. However, this access is limited solely to privileges granted by the assumed role.

AWS IAM Security Best Practices

To wrap up this article, we've compiled a set of recommended practices for your everyday use of IAM. It's important to note that this list is not comprehensive, as AWS IAM is a complex service that can be difficult to fully grasp.

Not using your Root Account Credentials

Your root user has full control over your account, your billing, and every resource you’ll ever create. As a best practice, it’s recommended to lock it away immediately and switch to Identity and Access Management (IAM) users. Don’t ever use the root credentials for your daily work, neither in the AWS console nor with infrastructure as code or the AWS command line interface.

Also, citing the AWS documentation about root users:

We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user.

Enforcing MFA for Users

Credentials can get lost or leaked easily, that’s why you should rely on a physical second factor for authenticating to AWS with both your root user and your daily IAM users.

Enabling multi-factor authentication (MFA) is very straight forward and AWS supports both virtual MFA devices (e.g. the Google Authenticator) and hardware MFA devices like the YubiKey.

If you're the root user of an account, you can require IAM users to use MFA strictly. To accomplish this, you'll need to set up a policy that prohibits all actions other than those related to managing the user's credentials and MFA devices.

The required policy looks like this:

{
  "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "iam:ListVirtualMFADevices",
    "iam:ResyncMFADevice",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

It limits users to only perform actions that are essential for configuring their MFA devices.

Once you've formulated the policy, you can link it to the designated IAM user group to ensure that all users are obliged to use MFA going forward. It's crucial to conduct a thorough test with a trial group before implementing this for production users.

Using AWS Organizations and Service Control Policies

When dealing with big projects or corporations, it is recommended to utilize several accounts and oversee them through AWS Organizations. This way, one can take advantage of the limitations associated with each AWS account and limit the harm caused by security breaches.

Member accounts for an AWS Organization.

With AWS Organizations we can put all its member accounts into different organizational units. We can pack each organizational unit into another unit, allowing us to map any possible structure.

Putting member accounts into organizational units so we can later apply Service Control Policies.

For each of those units, we can apply Service Control Policies (SCPs) that restrict IAM permissions for each of its member accounts. This allows us to effortlessly pass on rules throughout the organizational hierarchy.

As a simple example, we can create an SCP with the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "iam:AttachRolePolicy",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PolicyARN": "arn:aws:iam::aws:policy/AdministratorAccess"
        }
      }
    }
  ]
}

This will prevent IAM roles from receiving complete administrative access through the AWS-managed policy AdministratorAccess in AWS accounts located within the organizational unit where the SCP is linked.

💡 This is merely an illustration - there may be alternative methods for entities to acquire administrator-level privileges within the organizational unit. Our limitation only pertains to attachments of the AWS-provided managed role.

AWS Identity Center and Federation

As previously stated, utilizing IAM users in large organizations is not recommended. Instead, it is advisable to use identity federation with a dedicated identity provider (IdP) that supports SAML.

If you set up a SAML provider resource in your AWS accounts, you can enable users from a trusted IdP to assume IAM roles.

You can set up these resources directly in your accounts or use the AWS Identity Center to configure them for your whole organization when using AWS Organizations.

The Identity Center can function as an IdP, eliminating the requirement for a third-party service to manage users and groups across the organization and facilitate Single-Sign-On (SSO). However, for larger-scale environments, it is advisable to opt for a service that specializes in identity management.

Tooling

Working with multiple AWS accounts, users, and roles can be tedious. Not only when using your local terminal, especially when using the AWS console.

Luckily, there's great tool support out there.

Easily working with several AWS accounts, users, and roles by using Leapp

The maybe easiest way to deal with your daily work with AWS and other cloud providers is to use Leapp.

Leapp automatically generates secure, short-lived credentials for you. All sensitive data is stored in your local system vault and used only as required for best-in-class security. Credentials are cleared with each session stop. It also supports identity federation so you can easily integrate with known identity providers like Octa. OneLogin, or AWS SSO via the AWS Identity Center.

Conclusion

Understanding AWS IAM roles is essential for managing access to AWS resources securely.

By creating IAM roles, you can delegate access to AWS services and resources to other users, applications, or services without the need to share long-term access keys. IAM roles provide a secure way to manage access to AWS resources and reduce the risk of security breaches.

By following the best practices and concepts described in this article, you can get to grips with AWS IAM roles and improve your AWS security.

Frequently Asked Questions

  1. What is an IAM role in AWS?
    An IAM role is an AWS Identity and Access Management (IAM) entity that defines a set of permissions for making AWS service requests. IAM roles do not have any credentials (password or access keys) associated with them and are instead assumed by AWS services, users, or applications that need temporary security credentials to access AWS resources.

  2. How do IAM roles differ from IAM users?
    IAM roles are similar to IAM users in that they define a set of permissions for making AWS service requests. However, IAM roles do not have any permanent credentials associated with them and are instead assumed by IAM users, AWS services, or applications that need temporary security credentials to access AWS resources. IAM users, on the other hand, have permanent credentials (passwords or access keys) associated with them and can make AWS service requests directly.

  3. How do I create an IAM role in AWS?
    You can create an IAM role in AWS by using the AWS Management Console, AWS CLI, or AWS SDKs. To create an IAM role, you must define a policy that specifies the permissions that the role grants, and then attach the policy to the role. Once the role is created, you can assign it to an IAM user, AWS service, or application that needs temporary security credentials to access AWS resources.

  4. How do I assign an IAM role to an AWS service or application?
    You can assign an IAM role to an AWS service or application by using the AWS Management Console, AWS CLI, or AWS SDKs. When you assign an IAM role to an AWS service or application, you are granting it permission to assume the role and access AWS resources based on the permissions defined in the inline or attached managed policies.