This topic describes how to use RAM roles to grant permissions across accounts in a specific scenario.

Scenario description

Account A and account B represent different enterprises (teams or projects). Assume that A has purchased many cloud resources, such as ECS instances, RDS instances, SLB instances, and OSS buckets, for its business requirements.

  • A wants to focus on its business systems, so it entrusts O&M, monitoring, and management for its cloud resources or grant permissions on its cloud resources to enterprise B.
  • B can grant the access permission for A's resources to its employees. In this way, B can precisely control the employees' permissions on the cloud resources of A.
  • If A and B terminate their O&M entrustment contract, A can revoke the permissions of B at any time.

Requirement analysis

The analysis of the preceding scenario is as follows:

  • The scenario involves authorization between accounts A and B. A is the resource owner and wants to grant B permissions to operate A's resources.
  • B needs to further grant permissions to its users (employees or applications). If an employee of B joins or leaves the company, A does not have to make any changes to the permissions.
  • If A and B terminate their cooperation, A can revoke the permissions of B at any time.


To meet the requirements, a RAM role can be used to authorize users across accounts to access resources.

  • Account A creates a role and grants appropriate permissions to the role, and allows account B to use this role. For more information, see Cross-account authorization.
  • If an employee (a RAM user) under account B needs to use this role, account B can perform authorization control independently. Under the O&M entrustment contract, RAM users under account B can use the authorized role to operate A's resources. For more information, see Cross-account resource access.
  • If A and B terminate their cooperation, account A only needs to revoke account B's permissions for this role. Once the permissions are revoked, RAM users under account B cannot use this role any more. For more information, see Revoking of cross-account authorization.

Cross-account authorization

Assume that enterprise A (with an account ID of 11223344 and an alias of company-a) needs to grant permissions for ECS resources to the employees of enterprise B (with an account ID of 12345678 and an alias of company-b). The following figure shows how to use a RAM role for cross-account authorization.

The procedure is as follows:
  1. Account A creates a user role (for example, a role named ecs-admin) and selects Other Alibaba Cloud Account (account B with the ID of 12345678) as the trusted account. That is, RAM users under account B are allowed to assume this role. For more information, see Role.

    You can view basic information about the role on the role details page.

    • In this example, the RoleARN is:
    • The role's policy (only the RAM users under account A can assume this role) is as follows:
      "Statement": [
       "Action": "sts:AssumeRole",
       "Effect": "Allow",
       "Principal": {
         "RAM": [
      "Version": "1"
  2. Account A adds the policy AliyunECSFullAccess to the role ecs-admin.
  3. Account B creates a RAM user for one of its employees (for example, a user named Bob), and then:

Cross-account resource access

The following describes how Bob can access ECS resources under account A through the console:

  1. Bob logs on to the console.

    Bob must enter the correct enterprise alias (company-b), username (Bob), and password (123456).

  2. Bob switches the role.

    In the upper-right corner, Bob rests the pointer on the logon user name and clicks Switch Role to go to the identity switching page. Then, Bob enters the correct enterprise alias (company-a) and role name (ecs-admin) to switch the role.

  3. Bob operates the ECS resources under account A.

Revoking of cross-account authorization

The following describes how Account A can revoke account B's permissions for the role ecs-admin:

  1. Account A logs on to the RAM console, finds the role ecs-admin on the Roles page, and clicks the name of the role or Manage to go to the Role Details page.
  2. In the upper-right corner, account A clicks Edit Basic Information. In the displayed dialog box, account A removes acs:ram::12345678:root from the Policy Content area. (That is, account B will be removed from the role's trusted accounts.)
    Note Alternatively, account A can click Delete of the role ecs-admin on the Roles page. The policies attached to the role must be detached before the role is deleted.