This topic describes the common terms used in Auto Scaling.

Terms

Term Description References
Auto Scaling Auto Scaling is a service that automatically changes the number of instances to adjust the computing power based on the business requirements and policies. Auto Scaling can scale Elastic Compute Service (ECS) instances and elastic container instances. Auto Scaling automatically adds instances of the specified type during peak hours to ensure sufficient computing power. Auto Scaling automatically removes instances of the specified type during off-peak hours to reduce resource costs. What is Auto Scaling?
scaling group A scaling group is a group of instances that can be used for the same scenario. Instances within a scaling group must be of the same type. You can specify the minimum and maximum numbers of instances in a scaling group, and associate Server Load Balancer (SLB) instances and ApsaraDB RDS instances with the scaling group. Overview
ECS instance An ECS instance is a virtual server that includes basic computing components such as vCPU, memory, operating system, bandwidth, and disk. ECS eliminates the need for upfront investments in IT hardware and allows you to scale computing resources on demand. This makes ECS instances more convenient and efficient than physical servers. What is ECS?
elastic container instance Elastic Container Instance is a container service provided by Alibaba Cloud that combines container and serverless technologies. What is Elastic Container Instance?
SLB instance SLB is a service that forwards network traffic to backend servers to increase the throughput of your applications. You can use SLB to prevent service interruptions that are caused by single points of failure (SPOFs) and improve the availability of applications. SLB overview
ApsaraDB RDS instance ApsaraDB RDS is a stable and reliable online database service that supports elastic scaling. ApsaraDB RDS supports mainstream database engines and provides a variety of database solutions, such as disaster recovery, backup, restoration, monitoring, and migration. What is ApsaraDB RDS?
scaling mode A scaling mode specifies when to add or remove a specific number of instances for a scaling group. Scaling modes include scheduled mode, dynamic mode, fixed quantity mode, custom mode, health mode, and multi-mode. Scaling modes
instance configuration source Auto Scaling uses the instance configuration source that you select to create instances. The instance configuration source can be a scaling configuration or a launch template. Overview of instance configuration sources
scaling configuration A scaling configuration is a type of instance configuration source and includes the configuration information of instances. Create a scaling configuration (Elastic Compute Service)
scaling rule
  • Step scaling rules, target tracking scaling rules, and simple scaling rules are used to add or remove instances when scaling activities are triggered.
  • Predictive scaling rules are used to predict the future metric values based on historical monitoring data and intelligently specify boundary values for scaling groups.
Overview
scaling task Scaling tasks are categorized into scheduled tasks and event-triggered tasks. A scheduled task can be used to scale instances at a specified time. An event-triggered task can be used to dynamically scale instances based on specified monitoring metrics.
scaling activity A scaling activity records the changes in the number of instances within a scaling group, the boundary values of the scaling group, and the expected number of instances. Scaling activities are triggered when scaling rules are executed, the boundary values of a scaling group are modified, or the expected number of instances is modified. View the details of a scaling activity
expected number of instances After the Expected Number of Instances feature is enabled, Auto Scaling automatically maintains the number of instances at the expected value.
Note To enable the Expected Number of Instances feature, you must set the Expected Instances parameter when you create a scaling group. The specified expected number of instances in the scaling group can be modified.
Expected number of instances
Parallel scaling activity A scaling activity triggered by using one of the following methods is a parallel scaling activity:
  • Execute a scaling rule manually or by using a scheduled task.
  • Manually add or remove ECS instances.
  • Perform a check on the instance health, or the expected, minimum, or maximum number of instances.
A parallel scaling activity can be executed if the ongoing scaling activities are also parallel scaling activities.
Note Parallel scaling activities and non-parallel scaling activities are differentiated only if the Expected Number of Instances feature is enabled. If the Expected Number of Instances feature is disabled, no other scaling activities can be executed when a scaling activity is in progress.
Expected number of instances
Non-parallel scaling activity Scaling activities other than parallel activities are non-parallel scaling activities. No other scaling activities can be triggered when a non-parallel scaling activity is in progress.
Note Parallel scaling activities and non-parallel scaling activities are differentiated only if the Expected Number of Instances feature is enabled. If the Expected Number of Instances feature is disabled, no other scaling activities can be executed when a scaling activity is in progress.
Expected number of instances
stable instance A stable instance refers to an ECS instance that is in the In Service, Protected, or Standby state in a scaling group. ECS instance lifecycle
scaling process A scaling process refers to a process that you can manually suspend and resume, such as the scale-out, scale-in, health check, scheduled task, and event-triggered task. Scaling processes help you control scaling groups at the process level.
ECS instance lifecycle The lifecycle of an ECS instance in a scaling group refers to the process from the time when the instance is created to the time when it is released. The lifecycle management mode of an ECS instance depends on how the instance is created.
  • If the instance is automatically created by Auto Scaling, the lifecycle of the instance is managed by the scaling group.
  • If the instance is manually created and you enable the scaling group to manage the lifecycle of the instance, the lifecycle of the instance is managed by the scaling group. If you do not enable the scaling group to manage the lifecycle of the instance, you must manually manage the lifecycle of the instance.
ECS instance lifecycle
lifecycle hook A lifecycle hook allows ECS instances that are being added to or removed from a scaling group to enter the Pending state. After the ECS instances enter the Pending state, you can perform custom operations on them. For example, after an ECS instance is created, you can use a lifecycle hook to allow the instance to enter the Pending state. You can perform tests on the instance to ensure its service availability. Then, Auto Scaling adds the instance as a backend server to an associated SLB instance. Create a lifecycle hook
cooldown time The cooldown time refers to a period during which Auto Scaling cannot execute new scaling activities after one scaling activity is complete in a scaling group. During the cooldown time, Auto Scaling rejects all scaling activity requests of event-triggered tasks from CloudMonitor. This prevents scaling activities from being frequently triggered due to fluctuations in the metric value. Cooldown time