You can manage multiple stacks as a single unit called stack group with high efficiency and cost-effectiveness. 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, the management account of a resource directory, or a delegated administrator account of 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 the management account or a delegated administrator account of 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 members.
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 to only 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.

001

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 is the execution account 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 (Hangzhou) and China (Beijing) regions. 002
  • 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. 003

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 set 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 a time in a region. For example, if you want to deploy stacks to five execution accounts within two regions, you can set this parameter to 3. In this case, ROS deploys stacks first 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 a time in a region.
Note If the number of accounts specified by the percentage is not a whole number, ROS rounds down the number.
For example, if you want to deploy stacks to five execution accounts, you can set this parameter 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 are allowed in a region. If the value is exceeded in a region, ROS stops the operation in the region. For example, if you want to deploy stacks to five execution accounts within two regions, you can set this parameter 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 are allowed in a region. If the value is exceeded in a region, ROS stops the operation in the region.
Note If the number of accounts specified by the percentage is not a whole number, ROS rounds down the number.
For example, if you want to deploy stacks to five execution accounts, you can set this parameter to 50. In this case, ROS rounds down from a failure tolerance of 2.5 accounts to a failure tolerance of two accounts.
RegionConcurrencyType The mode in which you want to concurrently deploy stacks in the specified regions. Valid values:
  • SEQUENTIAL: deploys stacks in the specified regions one by one in sequence. This way, stacks are deployed in only one region at a time. This is the default value.
  • PARALLEL: deploys stacks in parallel in all specified regions.
For example, if you want to deploy stacks to five execution accounts within two regions, you can set this parameter to PARALLEL and the MaxConcurrentCount parameter to 3. In this case, ROS first concurrently deploys stacks to three execution accounts within the two regions. After the deployment is complete, ROS moves on to deploy stacks to the other two execution accounts within the two regions.