You can manage multiple stacks as a single unit called stack group in an efficient manner and at low costs. You can use a template to create multiple stacks across accounts and regions, and enable unified stack deployment in different directory folders and accounts.

Terms

Term Description
administrator account An account within which you create stack groups. The administrator account can be an Alibaba Cloud account, a management account in a resource directory, or a delegated administrator account in a resource directory.
  • If you use an Alibaba Cloud account to create stack groups that have self-managed permissions, Resource Orchestration Service (ROS) deploys stacks to other Alibaba Cloud accounts. In this scenario, both the administrator and execution accounts are Alibaba Cloud accounts.
  • If you use a management account or a delegated administrator account in an active resource directory to create stack groups that have service-managed permissions, ROS deploys stacks within execution accounts in the resource directory. In this scenario, the administrator account is the management account or the delegated administrator account, and the execution accounts are the member accounts.
execution account An account into which ROS deploys stacks.

Permission models

You must have the required permissions to create self-managed or service-managed stack groups. The following table describes the permission models.

Permission model Description Procedure
Self-managed permissions Before you create a stack group that has self-managed permissions, you must manually create RAM roles within the administrator and execution accounts to establish a trust relationship between the accounts. Then, you can deploy stacks within the execution account.
Service-managed permissions If you want to create a stack group that has service-managed permissions, you need only to enable the trusted access feature. ROS automatically creates service-linked roles within the administrator and execution accounts. The administrator account then uses the service-linked roles to deploy stacks within the execution account.

Principles

When you create a stack group within an administrator account, you also need to create stack instances in the specified execution account and region. This way, stacks that correspond to the stack instances can be created. Operations such as update and delete performed on a stack group also affect the stack instances and stacks in this group. The following figure shows the relationships between stack groups, stack instances, and stacks.

StackGroup

Stack groups, stack instances, and stacks are subject to the following items:

  • A stack instance can belong to only one stack group.
  • One stack instance corresponds to one or zero stack. A stack instance can exist without a stack. For example, if the stack cannot be created for some reason, the stack instance shows the reason for stack creation failure.
  • When you delete a stack instance, you can choose to delete or retain the stack with which the instance is associated.
  • When you delete a stack, the stack instance with which the stack is associated is not deleted.

Administrator accounts can be used to create stack groups that have self-managed permissions and service-managed permissions, and deploy stacks across execution accounts and regions.

  • Stack groups that have self-managed permissions: In the following example, Account A is the administrator account within which a stack group that has self-managed permissions is created in the China (Hangzhou) region. Account B and Account C are the execution accounts within which stacks are created in the China (Hangzhou) region, and Account C is the execution account within which stacks are created in the China (Beijing) region. 1
  • Stack groups that have service-managed permissions: In the following example, Account A is the administrator account within which a stack group that has service-managed permissions is created in the China (Hangzhou) region. ROS automatically obtains Account B and Account C as the execution accounts within which stacks are created in the specified resource folders in the China (Hangzhou) region and the China (Beijing) region. 2

Stack groups, regions, permissions, and accounts are subject to the following items:

  • A stack group and the administrator account that creates the stack group must be in the same region. For example, if you use an administrator account to create a stack group in the China (Hangzhou) region, this stack group does not appear in the China (Beijing) region.
  • If you want to create stack groups that have self-managed permissions and service-managed permissions, you must establish a trust relationship between the administrator and execution accounts before you can create stacks across accounts. For more information about permissions, see Permission models.
  • If you create a stack group that has service-managed permissions, you can enable the automatic deployment feature. After an account is added to or removed from a resource directory, ROS automatically creates or deletes the stack instance that is created by the account.

Stack deployment options

When you create a stack group or a stack instance, you can configure the parameters described in the following table to control the time and number of failures allowed to successfully perform stack deployment operations. This allows you to create multiple stacks in an efficient manner.

Parameter Description Example
MaxConcurrentCount The maximum number of execution accounts within which stacks can be deployed at one time in a region. For example, if you want to deploy stacks to five execution accounts within two regions, you can set MaxConcurrentCount to 3. In this case, ROS first deploys stacks to three execution accounts within the first region, and then to the other two execution accounts within the first region. Then, ROS moves on to the next region and begins deployment to the first three execution accounts.
MaxConcurrentPercentage The percentage of execution accounts within which stacks can be deployed at one time in a region.
Note If the specified percentage does not represent a whole number of your accounts, ROS rounds down.
For example, if you want to deploy stacks to five execution accounts, you can set MaxConcurrentPercentage to 50. In this case, ROS rounds down from concurrently deploying 2.5 stacks to concurrently deploying two stacks.
FailureToleranceCount The number of accounts within which stack deployment failures can occur per region, beyond which ROS automatically stops an operation. For example, if you want to deploy stacks to five execution accounts within two regions, you can set FailureToleranceCount to 2. This means that a maximum of two accounts within which stack deployment operations in a region can fail for the operation to continue. If stacks fail to be deployed in a third account in the same region, ROS stops the operation. If no more than two accounts within which stacks fail to be deployed in both regions, ROS considers the operation successful.
FailureTolerancePercentage The percentage of accounts within which stack deployment failures can occur per region, beyond which ROS automatically stops an operation.
Note If the specified percentage does not represent a whole number of your accounts within each region, ROS rounds down.
For example, if you want to deploy stacks to five execution accounts, you can set FailureTolerancePercentage to 50. In this case, ROS rounds down from a failure tolerance of 2.5 accounts to a failure tolerance of two accounts.