# IAM role management Role management Before a user, application, or service can use a role that you created, you must grant permissions to switch to the role. You can use any policy attached to groups or users to grant the necessary permissions. This section describes how to grant users permission to use a role. It also explains how the user can switch to a role from the AWS Management Console, the Tools for Windows PowerShell, the AWS Command Line Interface (AWS CLI) and the [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API. **Important** When you create a role programmatically instead of in the IAM console, you have an option to add a `Path` of up to 512 characters in addition to the `RoleName`, which can be up to 64 characters long. However, if you intend to use a role with the **Switch Role** feature in the AWS Management Console, then the combined `Path` and `RoleName` cannot exceed 64 characters. **Topics** + [ ## View role access ](#roles-modify_prerequisites) + [ ## Generate a policy based on access information ](#roles-modify_gen-policy) + [ # Grant a user permissions to switch roles ](id_roles_use_permissions-to-switch.md) + [ # Grant a user permissions to pass a role to an AWS service ](id_roles_use_passrole.md) + [ # Revoke IAM role temporary security credentials ](id_roles_use_revoke-sessions.md) + [ # Update a service-linked role ](id_roles_update-service-linked-role.md) + [ # Update a role trust policy ](id_roles_update-role-trust-policy.md) + [ # Update permissions for a role ](id_roles_update-role-permissions.md) + [ # Update settings for a role ](id_roles_update-role-settings.md) + [ # Delete roles or instance profiles ](id_roles_manage_delete.md) ## View role access Before you change the permissions for a role, you should review its recent service-level activity. This is important because you don't want to remove access from a principal (person or application) who is using it. For more information about viewing last accessed information, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md). ## Generate a policy based on access information You might sometimes grant permissions to an IAM entity (user or role) beyond what they require. To help you refine the permissions that you grant, you can generate an IAM policy that is based on the access activity for an entity. IAM Access Analyzer reviews your AWS CloudTrail logs and generates a policy template that contains the permissions that have been used by the entity in your specified date range. You can use the template to create a managed policy with fine-grained permissions and then attach it to the IAM entity. That way, you grant only the permissions that the user or role needs to interact with AWS resources for your specific use case. To learn more, see [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html). # Grant a user permissions to switch roles Grant permissions to switch roles When an administrator [creates a role for cross-account access](id_roles_create_for-user.md), they establish trust between the account that owns the role, the resources (trusting account), and the account that contains the users (trusted account). To do this, the administrator of the trusting account specifies the trusted account number as the `Principal` in the role's trust policy. That *potentially* allows any user in the trusted account to assume the role. To complete the configuration, the administrator of the trusted account must give specific groups or users in that account permission to switch to the role. **To grant permission to switch to a role** 1. As the administrator of the trusted account, create a new policy for the user, or edit an existing policy to add the required elements. For details, see [Creating or editing the policy](#roles-usingrole-createpolicy). 1. Then, choose how you want to share the role information: + **Role link:** Send users a link that takes them to the **Switch Role** page with all the details already filled in. + **Account ID or alias:** Provide each user with the role name along with the account ID number or account alias. The user then goes to the **Switch Role** page and adds the details manually. For details, see [Providing information to the user](#roles-usingrole-giveuser). Note that you can switch roles only when you sign in as an IAM user, a SAML-federated role, or a web-identity federated role. You cannot switch roles when you sign in as the AWS account root user. **Important** You cannot switch roles in the AWS Management Console to a role that requires an [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) value. You can switch to such a role only by calling the [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API that supports the `ExternalId` parameter. **Notes** This topic discusses policies for a *user*, because you are ultimately granting permissions to a user to accomplish a task. However, we don't recommend that you grant permissions directly to an individual user. When a user assumes a role, they are assigned the permissions associated with that role. When you switch roles in the AWS Management Console, the console always uses your original credentials to authorize the switch. This applies whether you sign in as an IAM user, as a SAML-federated role, or as a web-identity federated role. For example, if you switch to RoleA, IAM uses your original user or federated role credentials to determine if you are allowed to assume RoleA. If you then try to switch to RoleB *while you are using RoleA*, your **original** user or federated role credentials are used to authorize your attempt. The credentials for RoleA are not used for this action. **Topics** + [ ## Creating or editing the policy ](#roles-usingrole-createpolicy) + [ ## Providing information to the user ](#roles-usingrole-giveuser) ## Creating or editing the policy A policy that grants a user permission to assume a role must include a statement with the `Allow` effect on the following: + The `sts:AssumeRole` action + The Amazon Resource Name (ARN) of the role in a `Resource` element Users that get the policy are allowed to switch roles on the resource listed (either through group membership or directly attached). **Note** If `Resource` is set to `*`, the user can assume any role in any account that trusts the user's account. (In other words, the role's trust policy specifies the user's account as `Principal`). As a best practice, we recommend that you follow the [principle of least privilege](http://en.wikipedia.org/wiki/Principle_of_least_privilege) and specify the complete ARN for only the roles that the user needs. The following example shows a policy that lets the user assume roles in only one account. In addition, the policy uses a wildcard (\$1) to specify that the user can switch to a role only if the role name begins with the letters `Test`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/Test*" } } ``` ------ **Note** The permissions that the role grants to the user do not add to the permissions already granted to the user. When a user switches to a role, the user temporarily gives up his or her original permissions in exchange for those granted by the role. When the user exits the role, then the original user permissions are automatically restored. For example, let's say the user's permissions allow working with Amazon EC2 instances, but the role's permissions policy does not grant those permissions. In that case, while using the role, the user cannot work with Amazon EC2 instances in the console. In addition, temporary credentials obtained via `AssumeRole` do not work with Amazon EC2 instances programmatically. ## Providing information to the user After you create a role and grant your user permissions to switch to it, you must provide the user with the following: + The name of the role + The ID or alias of the account that contains the role You can streamline access for your users by sending them a link that is preconfigured with the account ID and role name. You can see the role link after completing the **Create Role** wizard by selecting the **View Role** banner, or on the **Role Summary** page for any cross-account enabled role. You can also use the following format to manually construct the link. Substitute your account ID or alias and the role name for the two parameters in the following example. `https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name` We recommend that you direct your users to [Switch from a user to an IAM role (console)](id_roles_use_switch-role-console.md) to walk them through the process. To troubleshoot common issues that you might encounter when you assume a role, see [I can't assume a role](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role). **Considerations** + If you create the role programmatically, you can create the role with a path and a name. If you do so, you must provide the complete path and role name to your users so they can enter it on the **Switch Role** page of the AWS Management Console. For example: `division_abc/subdivision_efg/role_XYZ`. + If you create the role programmatically, you can add a `Path` of up to 512 characters and a `RoleName`. The role name can be up to 64 characters long. However, to use a role with the **Switch Role** feature in the AWS Management Console, the combined `Path` and `RoleName` cannot exceed 64 characters. + For security purposes, you can [review AWS CloudTrail logs](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) to learn who performed an action in AWS. You can use the `sts:SourceIdentity` condition key in the role trust policy to require users to specify an identity when they assume a role. For example, you can require that IAM users specify their own user name as their source identity. This can help you determine which user performed a specific action in AWS. For more information, see [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity). You can also use [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname) to require users to specify a session name when they assume a role. This can help you differentiate between role sessions when a role is used by different principals. # Grant a user permissions to pass a role to an AWS service Grant permissions to pass a role to a service To configure many AWS services, you must *pass* an IAM role to the service. This allows the service to assume the role later and perform actions on your behalf. For most services, you only have to pass the role to the service once during setup, and not every time that the service assumes the role. For example, assume that you have an application running on an Amazon EC2 instance. That application requires temporary credentials for authentication, and permissions to authorize the application to perform actions in AWS. When you set up the application, you must pass a role to Amazon EC2 to use with the instance that provides those credentials. You define the permissions for the applications running on the instance by attaching an IAM policy to the role. The application assumes the role every time it needs to perform the actions that are allowed by the role. To pass a role (and its permissions) to an AWS service, a user must have permissions to *pass the role* to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the `PassRole` permission to the user's IAM user, role, or group. **Warning** You can only use the `PassRole` permission to pass an IAM role to a service that shares the same AWS account. To pass a role in Account A to a service in Account B, you must first create an IAM role in Account B that can assume the role from Account A, and then the role in Account B can be passed to the service. For details, see [Cross account resource access in IAM](access_policies-cross-account-resource-access.md). Do not try to control who can pass a role by tagging the role and then using the `ResourceTag` condition key in a policy with the `iam:PassRole` action. This approach does not have reliable results. When setting the `PassRole` permission, you should make sure that a user doesn’t pass a role where the role has more permissions than you want the user to have. For example, Alice might not be allowed to perform any Amazon S3 actions. If Alice could pass a role to a service that allows Amazon S3 actions, the service could perform Amazon S3 actions on behalf of Alice when executing the job. When you specify a service-linked role, you must also have permission to pass that role to the service. Some services automatically create a service-linked role in your account when you perform an action in that service. For example, Amazon EC2 Auto Scaling creates the `AWSServiceRoleForAutoScaling` service-linked role for you when you create an Auto Scaling group for the first time. If you try to specify the service-linked role when you create an Auto Scaling group and you don't have the `iam:PassRole` permission, you receive an error. If you don't explicitly specify the role, the `iam:PassRole` permission is not required, and the default is to use `AWSServiceRoleForAutoScaling` role for all operations that are performed on that group. To learn which services support service-linked roles, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md). To learn which services automatically create a service-linked role when you perform an action in that service, choose the **Yes** link and view the service-linked role documentation for the service. A user can pass a role ARN as a parameter in any API operation that uses the role to assign permissions to the service. The service then checks whether that user has the `iam:PassRole` permission. To limit the user to passing only approved roles, you can filter the `iam:PassRole` permission with the `Resources` element of the IAM policy statement. You can use the `Condition` element in a JSON policy to test the value of keys included in the request context of all AWS requests. To learn more about using condition keys in a policy, see [IAM JSON policy elements: Condition](reference_policies_elements_condition.md). The `iam:PassedToService` condition key can be used to specify the service principal of the service to which a role can be passed. To learn more about using the `iam:PassedToService` condition key in a policy, see [iam:PassedToService](reference_policies_iam-condition-keys.md#ck_PassedToService). **Example 1** Suppose you want to grant a user the ability to pass any of an approved set of roles to the Amazon EC2 service upon launching an instance. You need three elements: + An IAM *permissions policy* attached to the role that determines what the role can do. Scope permissions to only the actions that the role must perform, and to only the resources that the role needs for those actions. You can use an AWS managed or customer-created IAM permissions policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "A list of the permissions the role is allowed to use" ], "Resource": [ "A list of the resources the role is allowed to access" ] } } ``` ------ + A* trust policy* for the role that allows the service to assume the role. For example, you could attach the following trust policy to the role with the `UpdateAssumeRolePolicy` action. This trust policy allows Amazon EC2 to use the role and the permissions attached to the role. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole", "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } } ``` ------ + An IAM *permissions policy* attached to the IAM user that allows the user to pass only those approved roles. You usually add `iam:GetRole` to `iam:PassRole` so the user can get the details of the role to be passed. In this example, the user can pass only roles that exist in the specified account with names beginning with `EC2-roles-for-XYZ-`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::111122223333:role/EC2-roles-for-XYZ-*" } ] } ``` ------ Now the user can start an Amazon EC2 instance with an assigned role. Applications running on the instance can access temporary credentials for the role through the instance profile metadata. The permissions policies attached to the role determine what the instance can do. **Example 2** Amazon Relational Database Service (Amazon RDS) supports a feature called **Enhanced Monitoring**. This feature enables Amazon RDS to monitor a database instance using an agent. It also allows Amazon RDS to log metrics to Amazon CloudWatch Logs. To enable this feature, you must create a service role to give Amazon RDS permissions to monitor and write metrics to your logs. **To create a role for Amazon RDS enhanced monitoring** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Choose **Roles**, and then choose **Create role**. 1. Choose the **AWS Service** role type, and then for **Use cases for other AWS services**, choose the **RDS** service. Choose **RDS – Enhanced Monitoring**, and then choose **Next**. 1. Choose the **AmazonRDSEnhancedMonitoringRole** permissions policy. 1. Choose **Next**. 1. For **Role name**, enter a role name that helps you identify the purpose of this role. Role names must be unique within your AWS account. When a role name is used in a policy or as part of an ARN, the role name is case sensitive. When a role name appears to customers in the console, such as during the sign-in process, the role name is case insensitive. Because various entities might reference the role, you can't edit the name of the role after it is created. 1. (Optional) For **Description**, enter a description for the new role. 1. (Optional) Add metadata to the user by attaching tags as key-value pairs. For more information about using tags in IAM, see [Tags for AWS Identity and Access Management resources](id_tags.md). 1. Review the role and then choose **Create role**. The role automatically gets a trust policy that grants the `monitoring.rds.amazonaws.com` service permissions to assume the role. After it does, Amazon RDS can perform all of the actions that the `AmazonRDSEnhancedMonitoringRole` policy allows. The user that you want to access Enhanced Monitoring needs a policy that includes a statement that allows the user to to list the RDS roles and a statement that allows the user to pass the role, like the following. Use your account number and replace the role name with the name you provided in step 6. ``` { "Sid": "PolicyStatementToAllowUserToListRoles", "Effect": "Allow", "Action": ["iam:ListRoles"], "Resource": "*" }, { "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::account-id:role/RDS-Monitoring-Role" } ``` You can combine this statement with statements in another policy or put it in its own policy. To instead specify that the user can pass any role that begins with `RDS-`, you can replace the role name in the resource ARN with a wildcard, as follows. ``` "Resource": "arn:aws:iam::account-id:role/RDS-*" ``` ## `iam:PassRole` actions in AWS CloudTrail logs `PassRole` is not an API call. `PassRole` is a permission, meaning no CloudTrail logs are generated for IAM `PassRole`. To review what roles are passed to which AWS services in CloudTrail, you must review the CloudTrail log that created or modified the AWS resource receiving the role. For example, a role is passed to an AWS Lambda function when it's created. The log for the `CreateFunction` action shows a record of role that was passed to the function. # Revoke IAM role temporary security credentials Revoke role temporary credentials **Warning** If you follow the steps on this page, all users with current sessions created by assuming the role are denied access to all AWS actions and resources. This can result in users losing unsaved work. When you permit users to access the AWS Management Console with a long session duration time (such as 12 hours), their temporary credentials do not expire as quickly. If users inadvertently expose their credentials to an unauthorized third-party, that party has access for the duration of the session. However, you can immediately revoke all permissions to the role's credentials issued before a certain point in time if you need to. All temporary credentials for that role issued before the specified time become invalid. This forces all users to re-authenticate and request new credentials. **Note** You cannot revoke the session for a *[service-linked role](id_roles.md#iam-term-service-linked-role)*. When you revoke permissions for a role using the procedure in this topic, AWS attaches a new inline policy to the role that denies all permissions to all actions. It includes a condition that applies the restrictions only if the user assumed the role *before* the point in time when you revoke the permissions. If the user assumes the role *after* you revoked the permissions, then the deny policy does not apply to that user. For more information on denying access, see [Disabling permissions for temporary security credentials](id_credentials_temp_control-access_disable-perms.md). **Important** This deny policy applies to all users of the specified role, not just those with longer duration console sessions. ## Minimum permissions to revoke session permissions from a role To successfully revoke session permissions from a role, you must have the `PutRolePolicy` permission for the role. This allows you to attach the `AWSRevokeOlderSessions` inline policy to the role. ## Revoking session permissions You can revoke the session permissions from a role to deny all permissions to any user who assumed the role. **Note** You can't edit roles in IAM that were created from IAM Identity Center permission sets. You must revoke the active permission set session for a user in IAM Identity Center. For more information, see [Revoke active IAM role sessions created by permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) in the *IAM Identity Center User Guide*. **To immediately deny all permissions to any current user of role credentials** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**, and then choose the name (not the checkbox) of the role whose permissions you want to revoke. 1. On the **Summary** page for the selected role, choose the **Revoke sessions** tab. 1. On the **Revoke sessions** tab, choose **Revoke active sessions**. 1. AWS asks you to confirm the action. Select the **I acknowledge that I am revoking all active sessions for this role.** checkbox and choose **Revoke active sessions** on the dialog box. IAM then attaches a policy named `AWSRevokeOlderSessions` to the role. After you choose **Revoke active sessions**, the policy denies all access to users who assumed the role in the past as well as approximately 30 seconds into the future. This future time choice takes into account the propagation delay of the policy in order to deal with a new session that was acquired or renewed before the updated policy is in effect in a given region. Any user who assumes the role more than approximately 30 seconds after you choose Revoke active sessions is not affected. To learn why changes are not always immediately visible, see [Changes that I make are not always immediately visible](troubleshoot.md#troubleshoot_general_eventual-consistency). **Note** If you choose to **Revoke active sessions** again later, the date and time stamp in the policy is refreshed and it again denies all permissions to any user who assumed the role before the new specified time. Valid users whose sessions are revoked in this way must acquire temporary credentials for a new session to continue working. The AWS CLI caches credentials until they expire. To force the CLI to delete and refresh cached credentials that are no longer valid, run one of the following commands: **Linux, macOS, or Unix** ``` $ rm -r ~/.aws/cli/cache ``` **Windows** ``` C:\> del /s /q %UserProfile%\.aws\cli\cache ``` ## Revoking session permissions before a specified time You can also revoke session permissions at any time of your choice using the AWS CLI or SDK to specify a value for the `aws:TokenIssueTime` key in the Condition element of a policy. This policy denies all permissions when the value of `aws:TokenIssueTime` is earlier than the specified date and time. The value of `aws:TokenIssueTime` corresponds to the exact time at which the temporary security credentials were created. The `aws:TokenIssueTime` value is only present in the context of AWS requests that are signed with temporary security credentials, so the Deny statement in the policy does not affect requests that are signed with the long-term credentials of the IAM user. This policy can also be attached to a role. In that case, the policy affects only the temporary security credentials that were created by the role before the specified date and time. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"} } } } ``` ------ Valid users whose sessions are revoked in this way must acquire temporary credentials for a new session to continue working. The AWS CLI caches credentials until they expire. To force the CLI to delete and refresh cached credentials that are no longer valid, run one of the following commands: **Linux, macOS, or Unix** ``` $ rm -r ~/.aws/cli/cache ``` **Windows** ``` C:\> del /s /q %UserProfile%\.aws\cli\cache ``` # Update a service-linked role The method that you use to edit a service-linked role depends on the service. Some services might allow you to edit the permissions for a service-linked role from the service console, API, or CLI. However, after you create a service-linked role, you cannot change the name of the role because various entities might reference the role. You can edit the description of any role from the IAM console, API, or CLI. For information about which services support using service-linked roles, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md) and look for the services that have **Yes **in the **Service-Linked Role** column. To learn whether the service supports editing the service-linked role, choose the **Yes** link to view the service-linked role documentation for that service. ## Editing a service-linked role description (console) You can use the IAM console to edit the description of a service-linked role. **To edit the description of a service-linked role (console)** 1. In the navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role to modify. 1. To the far right of **Role description**, choose **Edit**. 1. Enter a new description in the box and choose **Save**. ## Editing a service-linked role description (AWS CLI) You can use IAM commands from the AWS CLI to edit the description of a service-linked role. **To change the description of a service-linked role (AWS CLI)** 1. (Optional) To view the current description for a role, run the following commands: ``` aws iam [get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) --role-name ROLE-NAME ``` Use the role name, not the ARN, to refer to roles with the CLI commands. For example, if a role has the following ARN: `arn:aws:iam::123456789012:role/myrole`, you refer to the role as **myrole**. 1. To update a service-linked role's description, run the following command: ``` aws iam [update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) --role-name ROLE-NAME --description OPTIONAL-DESCRIPTION ``` ## Editing a service-linked role description (AWS API) You can use the AWS API to edit the description of a service-linked role. **To change the description of a service-linked role (AWS API)** 1. (Optional) To view the current description for a role, call the following operation, and specify the name of the role: AWS API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To update a role's description, call the following operation, and specify the name (and optional description) of the role: AWS API: [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) # Update a role trust policy To change who can assume a role, you must modify the role's trust policy. You cannot modify the trust policy for a *[service-linked role](id_roles.md#iam-term-service-linked-role)*. **Notes** If a user is listed as the principal in a role's trust policy but cannot assume the role, check the user's [permissions boundary](access_policies_boundaries.md). If a permissions boundary is set for the user, then it must allow the `sts:AssumeRole` action. To allow users to assume the current role again within a role session, specify the role ARN or AWS account ARN as a principal in the role trust policy. AWS services that provide compute resources such as Amazon EC2, Amazon ECS, Amazon EKS, and Lambda provide temporary credentials and automatically update these credentials. This ensures that you always have a valid set of credentials. For these services, it's not necessary to assume the current role again to obtain temporary credentials. However, if you intend to pass [session tags](id_session-tags.md) or a [session policy](access_policies.md#policies_session), you need to assume the current role again. ## Updating a role trust policy (console) **To change a role trust policy in the AWS Management Console** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, choose **Roles**. 1. In the list of roles in your account, choose the name of the role that you want to modify. 1. Choose the **Trust relationships** tab, and then choose **Edit trust policy**. 1. Edit the trust policy as needed. To add additional principals that can assume the role, specify them in the `Principal` element. For example, the following policy snippet shows how to reference two AWS accounts in the `Principal` element: ``` "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ] }, ``` If you specify a principal in another account, adding an account to the trust policy of a role is only half of establishing the cross-account trust relationship. By default, no users in the trusted accounts can assume the role. The administrator for the newly trusted account must grant the users the permission to assume the role. To do that, the administrator must create or edit a policy that is attached to the user to allow the user access to the `sts:AssumeRole` action. For more information, see the following procedure or [Grant a user permissions to switch roles](id_roles_use_permissions-to-switch.md). The following policy snippet shows how to reference two AWS services in the `Principal` element: ``` "Principal": { "Service": [ "opsworks.amazonaws.com", "ec2.amazonaws.com" ] }, ``` 1. When you are finished editing your trust policy, choose **Update policy** to save your changes. For more information about policy structure and syntax, see [Policies and permissions in AWS Identity and Access Management](access_policies.md) and the [IAM JSON policy element reference](reference_policies_elements.md). **To allow users in a trusted external account to use the role (console)** For more information and detail about this procedure, see [Grant a user permissions to switch roles](id_roles_use_permissions-to-switch.md). 1. Sign in to the trusted external AWS account. 1. Decide whether to attach the permissions to a user or to a group. In the navigation pane of the IAM console, choose **Users** or **User groups** accordingly. 1. Choose the name of the user or group to which you want to grant access, and then choose the **Permissions** tab. 1. Do one of the following: + To edit a customer managed policy, choose the name of the policy, choose **Edit policy**, and then choose the **JSON** tab. You cannot edit an AWS managed policy. AWS managed policies appear with the AWS icon (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policy_icon.png)). For more information about the difference between AWS managed policies and customer managed policies, see [Managed policies and inline policies](access_policies_managed-vs-inline.md). + To edit an inline policy, choose the arrow next to the name of the policy and choose **Edit policy**. 1. In the policy editor, add a new `Statement` element that specifies the following: ``` { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME" } ``` Replace the ARN in the statement with the ARN of the role that the user can assume. 1. Follow the prompts on screen to finish editing the policy. ## Updating a role trust policy (AWS CLI) You can use the AWS CLI to change who can assume a role. **To modify a role trust policy (AWS CLI)** 1. (Optional) If you don't know the name of the role that you want to modify, run the following command to list the roles in your account: + [aws iam list-roles](https://docs.aws.amazon.com/cli/latest/reference/iam/list-roles.html) 1. (Optional) To view the current trust policy for a role, run the following command: + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. To modify the trusted principals that can access the role, create a text file with the updated trust policy. You can use any text editor to construct the policy. For example, the following trust policy shows how to reference two AWS accounts in the `Principal` element. This allows users within two separate AWS accounts to assume this role. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ]}, "Action": "sts:AssumeRole" } } ``` ------ If you specify a principal in another account, adding an account to the trust policy of a role is only half of establishing the cross-account trust relationship. By default, no users in the trusted accounts can assume the role. The administrator for the newly trusted account must grant the users the permission to assume the role. To do that, the administrator must create or edit a policy that is attached to the user to allow the user access to the `sts:AssumeRole` action. For more information, see the following procedure or [Grant a user permissions to switch roles](id_roles_use_permissions-to-switch.md). 1. To use the file that you just created to update the trust policy, run the following command: + [aws iam update-assume-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-assume-role-policy.html) **To allow users in a trusted external account to use the role (AWS CLI)** For more information and detail about this procedure, see [Grant a user permissions to switch roles](id_roles_use_permissions-to-switch.md). 1. Create a JSON file that contains a permissions policy that grants permissions to assume the role. For example, the following policy contains the minimum necessary permissions: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME" } } ``` ------ Replace the ARN in the statement with the ARN of the role that the user can assume. 1. Run the following command to upload the JSON file that contains the trust policy to IAM: + [aws iam create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html) The output of this command includes the ARN of the policy. Make a note of this ARN because you will need it in a later step. 1. Decide which user or group to attach the policy to. If you don't know the name of the intended user or group, use one of the following commands to list the users or groups in your account: + [aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html) + [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html) 1. Use one of the following commands to attach the policy that you created in the previous step to the user or group: + [aws iam attach-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html) + [aws iam attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html) ## Updating a role trust policy (AWS API) You can use the AWS API to change who can assume a role. **To modify a role trust policy (AWS API)** 1. (Optional) If you don't know the name of the role that you want to modify, call the following operation to list the roles in your account: + [ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html) 1. (Optional) To view the current trust policy for a role, call the following operation: + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To modify the trusted principals that can access the role, create a text file with the updated trust policy. You can use any text editor to construct the policy. For example, the following trust policy shows how to reference two AWS accounts in the `Principal` element. This allows users within two separate AWS accounts to assume this role. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ]}, "Action": "sts:AssumeRole" } } ``` ------ If you specify a principal in another account, adding an account to the trust policy of a role is only half of establishing the cross-account trust relationship. By default, no users in the trusted accounts can assume the role. The administrator for the newly trusted account must grant the users the permission to assume the role. To do that, the administrator must create or edit a policy that is attached to the user to allow the user access to the `sts:AssumeRole` action. For more information, see the following procedure or [Grant a user permissions to switch roles](id_roles_use_permissions-to-switch.md). 1. To use the file that you just created to update the trust policy, call the following operation: + [UpdateAssumeRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html) **To allow users in a trusted external account to use the role (AWS API)** For more information and detail about this procedure, see [Grant a user permissions to switch roles](id_roles_use_permissions-to-switch.md). 1. Create a JSON file that contains a permissions policy that grants permissions to assume the role. For example, the following policy contains the minimum necessary permissions: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME" } } ``` ------ Replace the ARN in the statement with the ARN of the role that the user can assume. 1. Call the following operation to upload the JSON file that contains the trust policy to IAM: + [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html) The output of this operation includes the ARN of the policy. Make a note of this ARN because you will need it in a later step. 1. Decide which user or group to attach the policy to. If you don't know the name of the intended user or group, call one of the following operations to list the users or groups in your account: + [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html) + [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html) 1. Call one of the following operations to attach the policy that you created in the previous step to the user or group: + API: [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html) + [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html) # Update permissions for a role Update role permissions Use the following procedures to update a role's permissions policies and permissions boundaries. ## Prerequisite: View role access Before you change the permissions for a role, you should review its recent service-level activity. This is important because you don't want to remove access from a principal (person or application) who is using it. For more information about viewing last accessed information, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md). ## Update the permissions policy for a role Update permissions policy To change the permissions allowed by the role, modify the role's permissions policy (or policies). You cannot modify the permissions policy for a *[service-linked role](id_roles.md#iam-term-service-linked-role)* in IAM. You might be able to modify the permissions policy within the service that depends on the role. To check whether a service supports this feature, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md) and look for the services that have **Yes **in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. ### Updating a role permissions policy (console) **To change the permissions allowed by a role (console)** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role that you want to modify, and then choose the **Permissions** tab. 1. Do one of the following: + To edit an existing customer managed policy, choose the name of the policy and then choose **Edit policy**. **Note** You cannot edit an AWS managed policy. AWS managed policies appear with the AWS icon (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policy_icon.png)). For more information about the difference between AWS managed policies and customer managed policies, see [Managed policies and inline policies](access_policies_managed-vs-inline.md). + To attach an existing managed policy to the role, choose **Add permissions** and then choose **Attach policies**. + To edit an existing inline policy, expand the policy and choose **Edit**. + To embed a new inline policy, choose **Add permissions** and then choose **Create inline policy**. + To remove an existing policy from the role, select the check box next to the policy name and then choose **Remove**. ### Updating a role permissions policy (AWS CLI) To change the permissions allowed by the role, modify the role's permissions policy (or policies). You cannot modify the permissions policy for a *[service-linked role](id_roles.md#iam-term-service-linked-role)* in IAM. You might be able to modify the permissions policy within the service that depends on the role. To check whether a service supports this feature, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md) and look for the services that have **Yes **in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. **To change the permissions allowed by a role (AWS CLI)** 1. (Optional) To view the current permissions associated with a role, run the following commands: 1. [aws iam list-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-policies.html) to list inline policies 1. [aws iam list-attached-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html) to list managed policies 1. The command to update permissions for the role differs depending on whether you are updating a managed policy or an inline policy. To update a managed policy, run the following command to create a new version of the managed policy: + [aws iam create-policy-version](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html) To update an inline policy, run the following command: + [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) ### Updating a role permissions policy (AWS API) To change the permissions allowed by the role, modify the role's permissions policy (or policies). You cannot modify the permissions policy for a *[service-linked role](id_roles.md#iam-term-service-linked-role)* in IAM. You might be able to modify the permissions policy within the service that depends on the role. To check whether a service supports this feature, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md) and look for the services that have **Yes **in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. **To change the permissions allowed by a role (AWS API)** 1. (Optional) To view the current permissions associated with a role, call the following operations: 1. [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html) to list inline policies 1. [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html) to list managed policies 1. The operation to update permissions for the role differs depending on whether you are updating a managed policy or an inline policy. To update a managed policy, call the following operation to create a new version of the managed policy: + [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html) To update an inline policy, call the following operation: + [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) ## Update the permissions boundary for a role Update permissions boundary To change the maximum permissions allowed for a role, modify the role's [permissions boundary](access_policies_boundaries.md). ### Updating a role permissions boundary (console) Update permissions boundary (console) **To change the policy used to set the permissions boundary for a role** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. 1. Choose the name of the role with the [permissions boundary](access_policies_boundaries.md) that you want to change. 1. Choose the **Permissions** tab. If necessary, open the **Permissions boundary** section and then choose **Change boundary**. 1. Select the policy that you want to use for the permissions boundary. 1. Choose **Change boundary**. Your changes don't take effect until the next time someone assumes this role. ### Updating a role permissions boundary (AWS CLI) Update permissions boundary (AWS CLI) **To change the managed policy used to set the permissions boundary for a role (AWS CLI)** 1. (Optional) To view the current [permissions boundary](access_policies_boundaries.md) for a role, run the following command: + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. To use a different managed policy to update the permissions boundary for a role, run the following command: + [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) A role can have only one managed policy set as a permissions boundary. If you change the permissions boundary, you change the maximum permissions allowed for a role. ### Updating a role permissions boundary (AWS API) Update permissions boundary (API) **To change the managed policy used to set the permissions boundary for a role (AWS API)** 1. (Optional) To view the current [permissions boundary](access_policies_boundaries.md) for a role, call the following operation: + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To use a different managed policy to update the permissions boundary for a role, call the following operation: + [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) A role can have only one managed policy set as a permissions boundary. If you change the permissions boundary, you change the maximum permissions allowed for a role. # Update settings for a role Update role settings Use the following procedures to update a role's description or change the maximum session duration for a role. ## Update a role description To change the description of the role, modify the description text. ### Updating a role description (console) **To change the description of a role (console)** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role to modify. 1. In the **Summary** section, choose **Edit**. 1. Enter a new description in the box and choose **Save changes**. ### Updating a role description (AWS CLI) **To change the description of a role (AWS CLI)** 1. (Optional) To view the current description for a role, run the following command: + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. To update a role's description, run the following command with the description parameter: + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) ### Updating a role description (AWS API) **To change the description of a role (AWS API)** 1. (Optional) To view the current description for a role, call the following operation: + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To update a role's description, call the following operation with the description parameter: + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) ## Update the maximum session duration for a role To specify the maximum session duration setting for roles that are assumed using the console, the AWS CLI, or AWS API, modify the maximum session duration setting value. This setting can have a value from 1 hour to 12 hours. If you do not specify a value, the default maximum of 1 hour is applied. This setting does not limit sessions assumed by AWS services. ### Updating the maximum role session duration (console) **To change the maximum session duration setting for roles that are assumed using the console, AWS CLI, or AWS API (console)** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role to modify. 1. In the **Summary** section, choose **Edit**. 1. For **Maximum session duration**, choose a value. Alternatively, choose **Custom duration** and enter a value (in seconds). 1. Choose **Save changes**. Your changes don't take effect until the next time someone assumes this role. To learn how to revoke existing sessions for this role, see [Revoke IAM role temporary security credentials](id_roles_use_revoke-sessions.md). In the AWS Management Console, IAM user sessions are 12 hours by default. IAM users who switch roles in the console are granted the role maximum session duration, or the remaining time in the user's session, whichever is less. Anyone who assumes the role from the AWS CLI or AWS API can request a longer session, up to this maximum. The `MaxSessionDuration` setting determines the maximum duration of the role session that can be requested. + To specify a session duration using the AWS CLI use the `duration-seconds` parameter. To learn more, see [Switch to an IAM role (AWS CLI)](id_roles_use_switch-role-cli.md). + To specify a session duration using the AWS API, use the `DurationSeconds` parameter. To learn more, see [Switch to an IAM role (AWS API)](id_roles_use_switch-role-api.md). ### Updating the maximum role session duration (AWS CLI) **Note** Anyone who assumes the role from the AWS CLI or API can use the `duration-seconds` CLI parameter or the `DurationSeconds` API parameter to request a longer session. The `MaxSessionDuration` setting determines the maximum duration of the role session that can be requested using the `DurationSeconds` parameter. If users don't specify a value for the `DurationSeconds` parameter, their security credentials are valid for one hour. **To change the maximum session duration setting for roles that are assumed using the AWS CLI (AWS CLI)** 1. (Optional) To view the current maximum session duration setting for a role, run the following command: + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. To update a role's maximum session duration setting, run the following command with the `max-session-duration` CLI parameter or the `MaxSessionDuration` API parameter: + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) Your changes don't take effect until the next time someone assumes this role. To learn how to revoke existing sessions for this role, see [Revoke IAM role temporary security credentials](id_roles_use_revoke-sessions.md). ### Updating the maximum role session duration (AWS API) **Note** Anyone who assumes the role from the AWS CLI or API can use the `duration-seconds` CLI parameter or the `DurationSeconds` API parameter to request a longer session. The `MaxSessionDuration` setting determines the maximum duration of the role session that can be requested using the `DurationSeconds` parameter. If users don't specify a value for the `DurationSeconds` parameter, their security credentials are valid for one hour. **To change the maximum session duration setting for roles that are assumed using the API (AWS API)** 1. (Optional) To view the current maximum session duration setting for a role, call the following operation: + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To update a role's maximum session duration setting, call the following operation with the `max-sessionduration` CLI parameter or the `MaxSessionDuration` API parameter: + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) Your changes don't take effect until the next time someone assumes this role. To learn how to revoke existing sessions for this role, see [Revoke IAM role temporary security credentials](id_roles_use_revoke-sessions.md). # Delete roles or instance profiles If you no longer need a role, we recommend that you delete the role and its associated permissions. That way you don't have an unused entity that is not actively monitored or maintained. If the role was associated with an EC2 instance, you can also remove the role from the instance profile and then delete the instance profile. **Warning** Make sure that you do not have any Amazon EC2 instances running with the role or instance profile you are about to delete. Deleting a role or instance profile that is associated with a running instance will break any applications that are running on the instance. If you prefer not to permanently delete a role, you can disable a role. To do this, change the role policies and then revoke all current sessions. For example, you could add a policy to the role that denied access to all of AWS. You could also edit the trust policy to deny access to anyone attempting to assume the role. For more information about revoking sessions, see [Revoke IAM role temporary security credentials](id_roles_use_revoke-sessions.md). **Topics** + [ ## Viewing role access ](#roles-delete_prerequisites) + [ ## Deleting a service-linked role ](#id_roles_manage_delete_slr) + [ ## Deleting an IAM role (console) ](#roles-managingrole-deleting-console) + [ ## Deleting an IAM role (AWS CLI) ](#roles-managingrole-deleting-cli) + [ ## Deleting an IAM role (AWS API) ](#roles-managingrole-deleting-api) + [ ## Related information ](#roles-managingrole-deleting-related-info) ## Viewing role access Before you delete a role, we recommend that you review when the role was last used. You can do this using the AWS Management Console, the AWS CLI, or the AWS API. You should view this information because you don't want to remove access from someone using the role. The date of the role last activity might not match the last date reported in the **Last Accessed** tab. The [**Last Accessed**](access_policies_last-accessed-view-data.md) tab reports activity only for services allowed by the role permissions policies. The date of the role last activity includes the last attempt to access any service in AWS. **Note** The tracking period for a role last activity and Last Accessed data is for the trailing 400 days. This period can be shorter if your Region began supporting these features within the last year. The role might have been used more than 400 days ago. For more information about the tracking period, see [Where AWS tracks last accessed information](access_policies_last-accessed.md#last-accessed_tracking-period). **To view when a role was last used (console)** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. 1. Find the row of the role with the activity you want to view. You can use the search field to narrow the results. View the **Last activity** column to see the number of days since the role was last used. If the role has not been used within the tracking period, then the table displays **None**. 1. Choose the name of the role to view more information. The role ** Summary** page also includes **Last activity**, which displays the last used date for the role. If the role has not been used within the last 400 days, then **Last activity** displays **Not accessed in the tracking period**. **To view when a role was last used (AWS CLI)** `[aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)` - Run this command to return information about a role, including the `RoleLastUsed` object. This object contains the `LastUsedDate` and the `Region` in which the role was last used. If `RoleLastUsed` is present but does not contain a value, then the role has not been used within the tracking period. **To view when a role was last used (AWS API)** `[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/GetRole.html)` - Call this operation to return information about a role, including the `RoleLastUsed` object. This object contains the `LastUsedDate` and the `Region` in which the role was last used. If `RoleLastUsed` is present but does not contain a value, then the role has not been used within the tracking period. ## Deleting a service-linked role The method that you use to delete a service-linked role depends on the service. In some cases, you don't need to manually delete a service-linked role. For example, when you complete a specific action (such as removing a resource) in the service, the service might delete the service-linked role for you. In other cases, the service might support deleting a service-linked role manually from the service console, API, or AWS CLI. Review the documentation for the *[service-linked role](id_roles.md#iam-term-service-linked-role)* in the linked service to learn how to delete the role. You can view the service-linked roles in your account by going to the IAM **Roles** page in the console. Service-linked roles appear with **(Service-linked role)** in the **Trusted entities** column of the table. A banner on the role **Summary** page also indicates that the role is a service-linked role. If the service does not include documentation for deleting the service-linked role, you can use the IAM console, AWS CLI, or API to delete the role. ## Deleting an IAM role (console) When you use the AWS Management Console to delete a role, IAM automatically detaches managed policies associated with the role. It also automatically deletes any inline policies associated with the role, and any Amazon EC2 instance profile that contains the role. **Important** In some cases, a role might be associated with an Amazon EC2 instance profile, and the role and the instance profile might have the same name. In that case you can use the AWS Management Console to delete the role and the instance profile. This linkage happens automatically for roles and instance profiles that you create in the console. If you created the role from the AWS CLI, Tools for Windows PowerShell, or the AWS API, then the role and the instance profile might have different names. In that case you cannot use the console to delete them. Instead, you must use the AWS CLI, Tools for Windows PowerShell, or AWS API to first remove the role from the instance profile. You must then take a separate step to delete the role. **To delete a role (console)** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**, and then select the check box next to the role name that you want to delete. 1. At the top of the page, choose **Delete**. 1. In the confirmation dialog box, review the last accessed information, which shows when each of the selected roles last accessed an AWS service. This helps you to confirm if the role is currently active. If you want to proceed, enter the name of the role in the text input field and choose **Delete**. If you are sure, you can proceed with the deletion even if the last accessed information is still loading. **Note** You cannot use the console to delete an instance profile unless it has the same name as the role. The instance profile is deleted as part of the process of deleting a role as described in the preceding procedure. To delete an instance profile without also deleting the role, you must use the AWS CLI or AWS API. For more information, see the following sections. ## Deleting an IAM role (AWS CLI) When you use the AWS CLI to delete a role, you must first delete inline policies associated with the role. You must also detach managed policies associated with the role. If you want to delete the associated instance profile that contains the role, you must delete it separately. **To delete a role (AWS CLI)** 1. If you don't know the name of the role that you want to delete, enter the following command to list the roles in your account: ``` aws iam list-roles ``` The list includes the Amazon Resource Name (ARN) of each role. Use the role name, not the ARN, to refer to roles with the CLI commands. For example, if a role has the following ARN: `arn:aws:iam::123456789012:role/myrole`, you refer to the role as **myrole**. 1. Remove the role from all instance profiles that the role is associated with. 1. To list all instance profiles that the role is associated with, enter the following command: ``` aws iam list-instance-profiles-for-role --role-name role-name ``` 1. To remove the role from an instance profile, enter the following command for each instance profile: ``` aws iam remove-role-from-instance-profile --instance-profile-name instance-profile-name --role-name role-name ``` 1. Delete all policies that are associated with the role. 1. To list all inline policies that are in the role, enter the following command: ``` aws iam list-role-policies --role-name role-name ``` 1. To delete each inline policy from the role, enter the following command for each policy: ``` aws iam delete-role-policy --role-name role-name --policy-name policy-name ``` 1. To list all managed policies that are attached to the role, enter the following command: ``` aws iam list-attached-role-policies --role-name role-name ``` 1. To detach each managed policy from the role, enter the following command for each policy: ``` aws iam detach-role-policy --role-name role-name --policy-arn policy-arn ``` 1. Enter the following command to delete the role: ``` aws iam delete-role --role-name role-name ``` 1. If you do not plan to reuse the instance profiles that were associated with the role, you can enter the following command to delete them: ``` aws iam delete-instance-profile --instance-profile-name instance-profile-name ``` ## Deleting an IAM role (AWS API) When you use the IAM API to delete a role, you must first delete inline policies associated with the role. You must also detach managed policies associated with the role. If you want to delete the associated instance profile that contains the role, you must delete it separately. **To delete a role (AWS API)** 1. To list all instance profiles that a role is associated with, call [ListInstanceProfilesForRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html). To remove the role from an instance profile, call [RemoveRoleFromInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html). You must pass the role name and instance profile name. If you are not going to reuse an instance profile that was associated with the role, call [DeleteInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) to delete it. 1. To list all inline policies for a role, call [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html). To delete inline policies that are associated with the role, call [DeleteRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRolePolicy.html). You must pass the role name and inline policy name. 1. To list all managed policies that are attached to a role, call [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html). To detach managed policies that are attached to the role, call [DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html). You must pass the role name and managed policy ARN. 1. Call [DeleteRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRole.html) to delete the role. ## Related information For general information about instance profiles, see [Use instance profiles](id_roles_use_switch-role-ec2_instance-profiles.md). For general information about service-linked roles, see [Create a service-linked role](id_roles_create-service-linked-role.md).