A scaling group is a group of Elastic Compute Service (ECS) instances or elastic container instances that can be used for similar business scenarios. If you have multiple business scenarios, you can create multiple scaling groups. Auto Scaling automatically adjusts the number of instances in the scaling groups based on your configurations.
Features of scaling groups
If you set the Type parameter to ECS when you create a scaling group, the scaling group contains ECS instances. If you set the Type parameter to ECI when you create a scaling group, the scaling group contains elastic container instances. Different types of scaling groups provide different features. The following table describes the features of scaling groups that contain ECS instances and scaling groups that contain elastic container instances.
|Item||Feature||ECS||Elastic Container Instance||User guide||API references|
|Scaling group||Basic configurations||Supported||Manage scaling groups||CreateScalingGroup|
|Health check||Supported||Health checks on instances in a scaling group|
|Association with Server Load Balancer (SLB) instances||Supported||Associate or disassociate SLB instances with or from a scaling group|
|Association with ApsaraDB RDS instances||Supported||Associate ApsaraDB RDS instances with a scaling group or disassociate ApsaraDB RDS instances from a scaling group|
|Instance configuration source||Launch template||Supported||Not supported||Overview||CreateLaunchTemplate|
|Image update||Supported||Not supported||None|
|Instance list||Automatic creation of instances||Supported|
|Manual addition of instances||Supported||Manually manage instances in a scaling group||AttachInstances|
|Scaling rule and scaling activity||Scaling rule||Supported||Manage scaling rules||CreateScalingRule|
|Scheduled task||Supported||Create a scheduled task||CreateScheduledTask|
|Event-triggered task||Supported||Manage event-triggered tasks||CreateAlarm|
|Scaling group monitoring||Supported||None|
|Lifecycle hook||Supported||Manage lifecycle hooks||CreateLifecycleHook|
|Notification rule||Supported||Create an advanced notification rule||CreateNotificationConfiguration|
|Rolling update||Supported||Rolling update||None|
|Health diagnosis||Supported||Health diagnosis||None|
Scaling group status
The following table describes the different statuses of a scaling group.
|Status||API status||Description||User guide||API references|
|Enabling||Inactive||If you enable a scaling group that is in the Disabled state, the scaling group enters the Enabling state.||Enable a scaling group||EnableScalingGroup|
|Enabled||Active||After you enable a scaling group, the scaling group enters the Enabled state. You can modify scaling groups that are in the Enabled state.|
|Disabling/Disabled||Inactive||Disable a scaling group||DisableScalingGroup|
|Deleting||Deleting||If you delete a scaling group, the scaling group enters the Deleting state.||Delete a scaling group||DeleteScalingGroup|
Instance configuration source
|Instance configuration source||Scenario||Difference|
|Launch Templates||The Launch Templates setting takes effect only for scaling groups that contain ECS instances. If your scaling group contains elastic container instances, you cannot set the Instance Configuration Source parameter to Launch Templates.|
|Select Existing Instance||The Select Existing Instance setting takes effect for scaling groups that contain ECS instances and scaling groups that contain elastic container instances.|
|Set the value to Create from Scratch.||The Create from Scratch setting takes effect for scaling groups that contain ECS instances and scaling groups that contain elastic container instances.||After you create a scaling group, you must create a scaling configuration or a launch template to enable the scaling group. Then, you can use the scaling configuration or the launch template to create ECS instances or elastic container instances in the scaling group.|
A scaling group can contain only one active scaling configuration source. For example, if you activate a new scaling configuration in a scaling group for which an active scaling configuration or launch template is already specified, the current launch template or scaling configuration leaves the Active state. For more information, see Overview.
Scaling rules and activities
After you create a scaling group, you must create scaling rules to add instances to or remove instances from the scaling group.
- Scaling rules: You can create scaling rules to trigger scaling activities in a scaling group or configure the maximum and minimum numbers of instances in the scaling group. For more information, see Overview.
Auto Scaling scales ECS instances in a scaling group based on scaling rules and the maximum, minimum, or expected number of ECS instances that is specified for the scaling group. For example, if you create a scaling rule that adjusts the number of instances in your scaling group to 50 and the maximum number of ECS instances that are allowed in your scaling group is 45, your scaling group contains only 45 ECS instances after the scaling rule is executed. For information about the Expected Number of Instances feature, see Expected number of instances.
You can use one of the following methods to execute scaling rules:
- Manually execute scaling rules.
- Use scheduled tasks to execute scaling rules. For more information, see Create a scheduled task.
- Use event-triggered tasks to execute scaling rules. For more information, see Overview.
- Scaling activities: A scaling activity is triggered when a scaling rule is executed or when you manually add or remove ECS instances. For more information, see Overview.
The following rules apply to scaling activities:
- You cannot terminate an ongoing scaling activity. For example, if a scaling activity is being executed to create 20 ECS instances and only five instances have been created, you cannot terminate the scaling activity.
- If several ECS instances fail to be added to a scaling group during a scaling activity, Auto Scaling determines that the scaling activity is complete. Auto Scaling rolls back only the ECS instances that fail to be added to the scaling group. For example, if a scaling group contains 20 ECS instances and 19 instances are added as backend servers of the SLB instance that is associated with the scaling group, only the ECS instance that fails to be added is rolled back and automatically released.
- Auto Scaling uses Resource Access Management (RAM) to call ECS API operations to create ECS instances. After ECS instances are rolled back, you are still charged for the ECS instances until the ECS instances are released.
- Scaling activities are affected by the cooldown period. During the cooldown period, Auto Scaling rejects all scaling activities that are triggered by event-triggered tasks. When you manually execute a scaling rule or Auto Scaling executes a scheduled task at a specified point in time, a scaling activity can be triggered even before the cooldown period ends. For more information about the cooldown period feature, see Cooldown time.
- The cooldown period starts after the last ECS instance or elastic container instance is added to or removed from a scaling group during a scaling activity.
RemarksIf your scaling group is associated with SLB instances or ApsaraDB RDS instances, take note of the following items when scaling activities are triggered in the scaling group:
Item Description Your scaling group is associated with SLB instances or server groups.
- If an associated SLB instance or server group is deleted or does not exist, scaling activities in the scaling group fail.
- Auto Scaling regularly checks whether the scaling group has associated SLB instances or server groups. If Auto Scaling detects that an associated SLB instance or server group is deleted or does not exist, Auto Scaling disassociates the SLB instance or the server group from the scaling group. Important In this case, the disassociated SLB instance or server group cannot cause scaling failures in the scaling group.
Your scaling group is associated with ApsaraDB RDS instances.
- If an associated ApsaraDB RDS instance is deleted or does not exist, scaling activities in the scaling group fail.
- Auto Scaling regularly checks whether the scaling group has associated ApsaraDB RDS instances. If Auto Scaling detects that an associated ApsaraDB RDS instance is deleted or does not exist, Auto Scaling disassociates the ApsaraDB RDS instance from the scaling group. Important In this case, the disassociated ApsaraDB RDS instance cannot cause scaling failures in the scaling group.