This topic describes the common terms used in Auto Scaling.
Concept hierarchy:
A scaling group contains instances and defines the boundaries (minimum, maximum, and expected count) for automatic scaling.
Instance configuration sources (scaling configurations or launch templates) tell Auto Scaling what type of instance to create during scale-out.
Scaling rules define how many instances to add or remove. Scaling tasks (scheduled or event-triggered) execute those rules at the right time.
Each execution produces a scaling activity, which records what changed and why.
Lifecycle hooks let you run custom logic when instances enter or leave the group. Scaling processes let you suspend individual scaling behaviors independently.
Terms
| Term | Description | References |
|---|---|---|
| Auto Scaling | A service that dynamically adjusts the number of instances based on your business requirements and scaling policies. Auto Scaling scales Elastic Compute Service (ECS) instances or elastic container instances — adding instances during peak hours to maintain capacity, and removing them during off-peak hours to reduce costs. | What is Auto Scaling? |
| scaling group | A collection of instances of the same type used for similar business scenarios. A scaling group defines the minimum and maximum number of instances it can contain, and can be associated with Server Load Balancer (SLB) instances and ApsaraDB RDS instances. | Overview |
| ECS instance | A virtual server composed of vCPU, memory, operating system, network configuration, and disk. ECS eliminates upfront hardware investments and scales on demand, making it more flexible than physical servers. | What is ECS? |
| elastic container instance | A container service provided by Alibaba Cloud that combines container and serverless technologies. | What is Elastic Container Instance? |
| SLB instance | A Server Load Balancer (SLB) instance distributes network traffic across backend servers to increase application throughput and prevent service interruptions caused by single points of failure (SPOFs), and improve the availability of applications. | SLB overview |
| ApsaraDB RDS instance | A stable, reliable online database service that supports elastic scaling and mainstream database engines. ApsaraDB RDS provides disaster recovery, backup, restoration, monitoring, and migration capabilities. | What is ApsaraDB RDS? |
| scaling mode | Specifies when Auto Scaling adds or removes instances and by how much. Supported modes: scheduled, dynamic, fixed-number, custom, health, and multiple modes. | Scaling modes |
| instance configuration source | The template Auto Scaling uses to create instances during scale-out. An instance configuration source is either a scaling configuration or a launch template. | Overview |
| scaling configuration | A type of instance configuration source that stores the configuration details of instances to be created. | Create a scaling configuration (ECS) |
| scaling rule | Defines the scaling behavior when a scaling activity is triggered. Rule types serve different purposes: step scaling rules, target tracking scaling rules, and simple scaling rules add or remove instances in response to triggered scaling activities; predictive scaling rules analyze historical monitoring data to forecast future metric values and proactively adjust the maximum and minimum instance counts for a scaling group. | Overview |
| scaling task | The mechanism that executes scaling rules. Scaling tasks come in two types: scheduled tasks, which trigger scaling at a specified time, and event-triggered tasks, which trigger scaling dynamically based on monitoring metrics. | Create a scheduled task · Overview |
| scaling activity | A record of changes to instance count, maximum/minimum instance limits, or expected instance count within a scaling group. Scaling activities are triggered when scaling rules run, when the maximum or minimum instance count is modified, or when the expected instance count is modified. | View the details of a scaling activity |
| expected number of instances | The target instance count that Auto Scaling actively maintains when the Expected Number of Instances feature is enabled. Set this value when creating a scaling group; it can be updated at any time. | Expected number of instances |
| parallel scaling activity | A scaling activity that can run concurrently with other parallel scaling activities. Parallel scaling activities are triggered by: running a scaling rule manually or via a scheduled task, manually adding or removing ECS instances, or performing a health check or expected/minimum/maximum instance count check. The distinction between parallel and non-parallel scaling activities applies only when the Expected Number of Instances feature is enabled. Without this feature, no new scaling activity can start while another is in progress. | Expected number of instances |
| non-parallel scaling activity | Any scaling activity that is not a parallel scaling activity. While a non-parallel scaling activity is in progress, no other scaling activity can start. The distinction between parallel and non-parallel scaling activities applies only when the Expected Number of Instances feature is enabled. Without this feature, no new scaling activity can start while another is in progress. | Expected number of instances |
| stable instance | An ECS instance in the In Service, Protected, or Standby state within a scaling group. | ECS instance lifecycle in a scaling group |
| scaling process | An individual Auto Scaling behavior that you can suspend and resume independently, such as scale-out, scale-in, health check, scheduled task execution, or event-triggered task execution. Suspending specific processes gives you fine-grained control over scaling group behavior. | Suspend a scaling process · Suspend and resume scaling processes |
| lifecycle of an instance in a scaling group | The full span of an ECS instance or elastic container instance from creation to release. Lifecycle management depends on how the instance was added: instances created automatically by Auto Scaling are fully managed by the scaling group; manually added instances are managed by the scaling group only if you explicitly enable that option, otherwise you manage the lifecycle yourself. | ECS instance lifecycle in a scaling group |
| lifecycle hook | Pauses ECS instances or elastic container instances entering or leaving a scaling group so you can run custom operations before Auto Scaling proceeds. For example, after Auto Scaling creates a new instance during scale-out, a lifecycle hook can hold the instance in the Pending state while you run tests to verify service availability. Auto Scaling then adds the instance as a backend server to the associated SLB instance. | Create a lifecycle hook |
| cooldown time | A period after a scaling activity completes during which Auto Scaling rejects all new scaling activity requests from CloudMonitor event-triggered tasks. Cooldown time prevents rapid successive scaling triggered by short-lived metric fluctuations. | Cooldown time |
该文章对您有帮助吗？