@alicloud/ess20220222 1.3.2 → 1.4.1

package/dist/client.d.ts

@@ -1880,6 +1880,59 @@ export declare class DescribeNotificationTypesResponse extends $tea.Model {
         [key: string]: any;
     });
 }
+export declare class DescribePatternTypesRequest extends $tea.Model {
+    architecture?: string[];
+    burstablePerformance?: string;
+    channelId?: number;
+    cores?: number;
+    coresList?: number[];
+    excludedInstanceType?: string[];
+    instanceFamilyLevel?: string;
+    maxPrice?: number;
+    memory?: number;
+    memoryList?: number[];
+    regionId?: string;
+    spotStrategy?: string;
+    vSwitchId?: string[];
+    static names(): {
+        [key: string]: string;
+    };
+    static types(): {
+        [key: string]: any;
+    };
+    constructor(map?: {
+        [key: string]: any;
+    });
+}
+export declare class DescribePatternTypesResponseBody extends $tea.Model {
+    patternTypes?: DescribePatternTypesResponseBodyPatternTypes[];
+    requestId?: string;
+    static names(): {
+        [key: string]: string;
+    };
+    static types(): {
+        [key: string]: any;
+    };
+    constructor(map?: {
+        [key: string]: any;
+    });
+}
+export declare class DescribePatternTypesResponse extends $tea.Model {
+    headers?: {
+        [key: string]: string;
+    };
+    statusCode?: number;
+    body?: DescribePatternTypesResponseBody;
+    static names(): {
+        [key: string]: string;
+    };
+    static types(): {
+        [key: string]: any;
+    };
+    constructor(map?: {
+        [key: string]: any;
+    });
+}
 export declare class DescribeRegionsRequest extends $tea.Model {
     acceptLanguage?: string;
     ownerId?: number;
@@ -2444,6 +2497,7 @@ export declare class DetachInstancesRequest extends $tea.Model {
     clientToken?: string;
     decreaseDesiredCapacity?: boolean;
     detachOption?: string;
+    ignoreInvalidInstance?: boolean;
     instanceIds?: string[];
     lifecycleHook?: boolean;
     ownerAccount?: string;
@@ -3832,6 +3886,7 @@ export declare class RecordLifecycleActionHeartbeatResponse extends $tea.Model {
 export declare class RemoveInstancesRequest extends $tea.Model {
     clientToken?: string;
     decreaseDesiredCapacity?: boolean;
+    ignoreInvalidInstance?: boolean;
     instanceIds?: string[];
     ownerAccount?: string;
     ownerId?: number;
@@ -6227,6 +6282,22 @@ export declare class DescribeNotificationConfigurationsResponseBodyNotificationC
         [key: string]: any;
     });
 }
+export declare class DescribePatternTypesResponseBodyPatternTypes extends $tea.Model {
+    cores?: number;
+    instanceFamilyLevel?: string;
+    instanceType?: string;
+    instanceTypeFamily?: string;
+    memory?: number;
+    static names(): {
+        [key: string]: string;
+    };
+    static types(): {
+        [key: string]: any;
+    };
+    constructor(map?: {
+        [key: string]: any;
+    });
+}
 export declare class DescribeRegionsResponseBodyRegions extends $tea.Model {
     classicUnavailable?: boolean;
     localName?: string;
@@ -8051,905 +8122,1875 @@ export default class Client extends OpenApi {
     getEndpoint(productId: string, regionId: string, endpointRule: string, network: string, suffix: string, endpointMap: {
         [key: string]: string;
     }, endpoint: string): string;
+    /**
+     * @summary Manages scaling configurations of the Elastic Container Instance type. If you want to efficiently create or update a scaling configuration of the Elastic Container Instance type by using a configuration file, you can call the ApplyEciScalingConfiguration operation.
+     *
+     * @description You can manage scaling configurations of the Elastic Container Instance type by using a YAML configuration file based on the following logic:
+     * If you specify the ID of a scaling configuration, you can update the scaling configuration by using the YAML configuration file. If you do not specify the ID of a scaling configuration, you can create a scaling configuration by using the YAML configuration file.
+     *
+     * @param request ApplyEciScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ApplyEciScalingConfigurationResponse
+     */
     applyEciScalingConfigurationWithOptions(request: ApplyEciScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<ApplyEciScalingConfigurationResponse>;
+    /**
+     * @summary Manages scaling configurations of the Elastic Container Instance type. If you want to efficiently create or update a scaling configuration of the Elastic Container Instance type by using a configuration file, you can call the ApplyEciScalingConfiguration operation.
+     *
+     * @description You can manage scaling configurations of the Elastic Container Instance type by using a YAML configuration file based on the following logic:
+     * If you specify the ID of a scaling configuration, you can update the scaling configuration by using the YAML configuration file. If you do not specify the ID of a scaling configuration, you can create a scaling configuration by using the YAML configuration file.
+     *
+     * @param request ApplyEciScalingConfigurationRequest
+     * @return ApplyEciScalingConfigurationResponse
+     */
     applyEciScalingConfiguration(request: ApplyEciScalingConfigurationRequest): Promise<ApplyEciScalingConfigurationResponse>;
+    /**
+     * @summary 基于yaml配置进行弹性伸缩管理
+     *
+     * @description You can call the ApplyScalingGroup operation to create scaling groups of the Elastic Container Instance type with ease. The resources of the scaling groups are defined in Kubernetes Deployment YAML files. You can also call this operation to extend annotations for elastic container instances in Kubernetes Deployment YAML files. For more information, see "Supported annotations" in this topic.
+     * Mapping between YAML files and scaling groups: You can map the triplet of namespace, kind, and name in a YAML file to a scaling group name. A YAML file and a scaling group have a one-to-one mapping relationship in a region. For example, if you use the Kubernetes Deployment YAML file whose name is NGINX in the default namespace to create a scaling group in a region, the unique name of the mapped scaling group is k8s_default_Deployment_nginx.
+     * You can use a Kubernetes Deployment YAML file to manage a scaling group based on the following logic:
+     * * If an existing scaling group has a mapping relationship with your Kubernetes Deployment YAML file, you can update the scaling group by using the YAML file.
+     * * If no scaling group that has a mapping relationship with your Kubernetes Deployment YAML file exists, you can create a scaling group with ease by using the YAML file.
+     * ### Precautions
+     * 1. If you do not specify a virtual private cloud (VPC), vSwitch, security group, or annotation in your Kubernetes Deployment YAML file, the system creates a default VPC that has default vSwitches and uses the default security group ess-default-sg of Auto Scaling. By default, the security group rule allows traffic on Transmission Control Protocol (TCP)-based port 22 and port 3389 and enables Internet Control Message Protocol (ICMP) for IPv4 addresses. If you want to enable other ports or protocols, you can create custom security group rules.
+     * 2. If you want to use a public image, you must enable the Internet access feature and configure the k8s.aliyun.com/eci-with-eip pod annotation to enable the elastic IP address (EIP) feature.
+     * 3. After you call the ApplyScalingGroup operation to apply a Kubernetes Deployment YAML file, the scaling group immediately enters the Enabled state and the scaling configuration immediately enters the Active state. If the number of replicas that you specified in the YAML file is grater than 0, elastic container instances are automatically created.
+     * ### Supported annotations
+     * For more information about annotations, see [ECI Pod Annotation](https://help.aliyun.com/document_detail/186939.html).
+     * |Annotation|Example|Description|
+     * |---|---|---|
+     * |k8s.aliyun.com/ess-scaling-group-min-size|1|The minimum size of the scaling group that you want to create. Default value: 0.|
+     * |k8s.aliyun.com/ess-scaling-group-max-size|20|The maximum size of the scaling group that you want to create. Default value: maximum number of replicas or 30, whichever is greater.|
+     * |k8s.aliyun.com/eci-ntp-server|100.100.*.*|The IP address of the Network Time Protocol (NTP) server.|
+     * |k8s.aliyun.com/eci-use-specs|2-4Gi|The specifications of 2 vCPUs and 4 GB memory. For more information, see [Create pods by specifying multiple specifications](https://help.aliyun.com/document_detail/451267.html).|
+     * |k8s.aliyun.com/eci-vswitch|vsw-bp1xpiowfm5vo8o3c\\*\\*\\*\\*|The ID of the vSwitch. You can specify multiple vSwitches to specify multiple zones.|
+     * |k8s.aliyun.com/eci-security-group|sg-bp1dktddjsg5nktv\\*\\*\\*\\*|The ID of the security group. Before you configure this annotation, take note of the following requirements:<ul data-sourcepos="26:74-26:168"><li data-sourcepos="26:78-26:114">You can specify one or more security groups. You can specify up to five security groups for each scaling group.</li><li data-sourcepos="26:114-26:140">If you specify multiple security groups, the security groups must belong to the same VPC.</li><li data-sourcepos="26:140-26:163">If you specify multiple security groups, the security groups must be of the same type.</li></ul>|
+     * |k8s.aliyun.com/eci-sls-enable|"false"|If you set the value to false, the log collection feature is disabled.
+     * If you do not want to use Custom Resource Definition (CRD) for Simple Log Service to collect logs of specific pods, you can configure this annotation for the pods and set the value to false. This prevents resource wastes caused by Logtails created by the system.|
+     * |k8s.aliyun.com/eci-spot-strategy|SpotAsPriceGo|The bidding policy for the preemptible instance. Valid values:<ul data-sourcepos="28:69-28:204"><li data-sourcepos="28:73-28:158">SpotWithPriceLimit: The instance is created as a preemptible instance for which you specify the maximum hourly price If you set the value to SpotWithPriceLimit, you must configure the k8s.aliyun.com/eci-spot-price-limit annotation.</li><li data-sourcepos="28:158-28:199">SpotAsPriceGo: The instance is a preemptible instance for which the market price at the time of purchase is used as the bid price.</li></ul>|
+     * |k8s.aliyun.com/eci-spot-price-limit|"0.5"|The maximum hourly price of the preemptible instance. This value can be accurate to up to three decimal places.
+     * This annotation takes effect only when you set the k8s.aliyun.com/eci-spot-strategy annotation to SpotWithPriceLimit.|
+     * |k8s.aliyun.com/eci-with-eip|"true"|If you set the value to true, an EIP is automatically created and bound to each elastic container instance.|
+     * |k8s.aliyun.com/eci-data-cache-bucket|default|The bucket of the specified DataCache. If you want to use a DataCache to create a pod, you must configure this annotation.|
+     * |k8s.aliyun.com/eci-data-cache-pl|PL1|The performance level (PL) of the cloud disk that you want to create by using the specified DataCache.
+     * By default, enhanced SSDs (ESSDs) are created. Default value: PL1.|
+     * |k8s.aliyun.com/eci-data-cache-provisionedIops|"40000"|The provisioned read/write IOPS of the ESSD AutoPL disk. Valid values: 0 to min{50000, 1000 × Capacity - Baseline IOPS}. Baseline IOPS = min{1,800 + 50 × Capacity, 50,000}. For more information, see [ESSD AutoPL](https://help.aliyun.com/document_detail/368372.html).
+     * If you configure this annotation, the cloud disk that is created by using the specified DataCache is of the ESSD AutoPL type.|
+     * |k8s.aliyun.com/eci-data-cache-burstingEnabled|"true"|Specifies whether the Burst feature is enabled for the ESSD AutoPL disk. For more information, see [ESSD AutoPL](https://help.aliyun.com/document_detail/368372.html).
+     * If you configure this annotation, the cloud disk that is created by using the specified DataCache is of the ESSD AutoPL type.|
+     * |k8s.aliyun.com/eci-custom-tags|"env:test,name:alice"|The tags that you want to add to each elastic container instance. You can add up to three tags for each elastic container instance. Separate a tag key and a tag value with a colon (:). Separate multiple tags with commas (,).|
+     *
+     * @param request ApplyScalingGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ApplyScalingGroupResponse
+     */
     applyScalingGroupWithOptions(request: ApplyScalingGroupRequest, runtime: $Util.RuntimeOptions): Promise<ApplyScalingGroupResponse>;
+    /**
+     * @summary 基于yaml配置进行弹性伸缩管理
+     *
+     * @description You can call the ApplyScalingGroup operation to create scaling groups of the Elastic Container Instance type with ease. The resources of the scaling groups are defined in Kubernetes Deployment YAML files. You can also call this operation to extend annotations for elastic container instances in Kubernetes Deployment YAML files. For more information, see "Supported annotations" in this topic.
+     * Mapping between YAML files and scaling groups: You can map the triplet of namespace, kind, and name in a YAML file to a scaling group name. A YAML file and a scaling group have a one-to-one mapping relationship in a region. For example, if you use the Kubernetes Deployment YAML file whose name is NGINX in the default namespace to create a scaling group in a region, the unique name of the mapped scaling group is k8s_default_Deployment_nginx.
+     * You can use a Kubernetes Deployment YAML file to manage a scaling group based on the following logic:
+     * * If an existing scaling group has a mapping relationship with your Kubernetes Deployment YAML file, you can update the scaling group by using the YAML file.
+     * * If no scaling group that has a mapping relationship with your Kubernetes Deployment YAML file exists, you can create a scaling group with ease by using the YAML file.
+     * ### Precautions
+     * 1. If you do not specify a virtual private cloud (VPC), vSwitch, security group, or annotation in your Kubernetes Deployment YAML file, the system creates a default VPC that has default vSwitches and uses the default security group ess-default-sg of Auto Scaling. By default, the security group rule allows traffic on Transmission Control Protocol (TCP)-based port 22 and port 3389 and enables Internet Control Message Protocol (ICMP) for IPv4 addresses. If you want to enable other ports or protocols, you can create custom security group rules.
+     * 2. If you want to use a public image, you must enable the Internet access feature and configure the k8s.aliyun.com/eci-with-eip pod annotation to enable the elastic IP address (EIP) feature.
+     * 3. After you call the ApplyScalingGroup operation to apply a Kubernetes Deployment YAML file, the scaling group immediately enters the Enabled state and the scaling configuration immediately enters the Active state. If the number of replicas that you specified in the YAML file is grater than 0, elastic container instances are automatically created.
+     * ### Supported annotations
+     * For more information about annotations, see [ECI Pod Annotation](https://help.aliyun.com/document_detail/186939.html).
+     * |Annotation|Example|Description|
+     * |---|---|---|
+     * |k8s.aliyun.com/ess-scaling-group-min-size|1|The minimum size of the scaling group that you want to create. Default value: 0.|
+     * |k8s.aliyun.com/ess-scaling-group-max-size|20|The maximum size of the scaling group that you want to create. Default value: maximum number of replicas or 30, whichever is greater.|
+     * |k8s.aliyun.com/eci-ntp-server|100.100.*.*|The IP address of the Network Time Protocol (NTP) server.|
+     * |k8s.aliyun.com/eci-use-specs|2-4Gi|The specifications of 2 vCPUs and 4 GB memory. For more information, see [Create pods by specifying multiple specifications](https://help.aliyun.com/document_detail/451267.html).|
+     * |k8s.aliyun.com/eci-vswitch|vsw-bp1xpiowfm5vo8o3c\\*\\*\\*\\*|The ID of the vSwitch. You can specify multiple vSwitches to specify multiple zones.|
+     * |k8s.aliyun.com/eci-security-group|sg-bp1dktddjsg5nktv\\*\\*\\*\\*|The ID of the security group. Before you configure this annotation, take note of the following requirements:<ul data-sourcepos="26:74-26:168"><li data-sourcepos="26:78-26:114">You can specify one or more security groups. You can specify up to five security groups for each scaling group.</li><li data-sourcepos="26:114-26:140">If you specify multiple security groups, the security groups must belong to the same VPC.</li><li data-sourcepos="26:140-26:163">If you specify multiple security groups, the security groups must be of the same type.</li></ul>|
+     * |k8s.aliyun.com/eci-sls-enable|"false"|If you set the value to false, the log collection feature is disabled.
+     * If you do not want to use Custom Resource Definition (CRD) for Simple Log Service to collect logs of specific pods, you can configure this annotation for the pods and set the value to false. This prevents resource wastes caused by Logtails created by the system.|
+     * |k8s.aliyun.com/eci-spot-strategy|SpotAsPriceGo|The bidding policy for the preemptible instance. Valid values:<ul data-sourcepos="28:69-28:204"><li data-sourcepos="28:73-28:158">SpotWithPriceLimit: The instance is created as a preemptible instance for which you specify the maximum hourly price If you set the value to SpotWithPriceLimit, you must configure the k8s.aliyun.com/eci-spot-price-limit annotation.</li><li data-sourcepos="28:158-28:199">SpotAsPriceGo: The instance is a preemptible instance for which the market price at the time of purchase is used as the bid price.</li></ul>|
+     * |k8s.aliyun.com/eci-spot-price-limit|"0.5"|The maximum hourly price of the preemptible instance. This value can be accurate to up to three decimal places.
+     * This annotation takes effect only when you set the k8s.aliyun.com/eci-spot-strategy annotation to SpotWithPriceLimit.|
+     * |k8s.aliyun.com/eci-with-eip|"true"|If you set the value to true, an EIP is automatically created and bound to each elastic container instance.|
+     * |k8s.aliyun.com/eci-data-cache-bucket|default|The bucket of the specified DataCache. If you want to use a DataCache to create a pod, you must configure this annotation.|
+     * |k8s.aliyun.com/eci-data-cache-pl|PL1|The performance level (PL) of the cloud disk that you want to create by using the specified DataCache.
+     * By default, enhanced SSDs (ESSDs) are created. Default value: PL1.|
+     * |k8s.aliyun.com/eci-data-cache-provisionedIops|"40000"|The provisioned read/write IOPS of the ESSD AutoPL disk. Valid values: 0 to min{50000, 1000 × Capacity - Baseline IOPS}. Baseline IOPS = min{1,800 + 50 × Capacity, 50,000}. For more information, see [ESSD AutoPL](https://help.aliyun.com/document_detail/368372.html).
+     * If you configure this annotation, the cloud disk that is created by using the specified DataCache is of the ESSD AutoPL type.|
+     * |k8s.aliyun.com/eci-data-cache-burstingEnabled|"true"|Specifies whether the Burst feature is enabled for the ESSD AutoPL disk. For more information, see [ESSD AutoPL](https://help.aliyun.com/document_detail/368372.html).
+     * If you configure this annotation, the cloud disk that is created by using the specified DataCache is of the ESSD AutoPL type.|
+     * |k8s.aliyun.com/eci-custom-tags|"env:test,name:alice"|The tags that you want to add to each elastic container instance. You can add up to three tags for each elastic container instance. Separate a tag key and a tag value with a colon (:). Separate multiple tags with commas (,).|
+     *
+     * @param request ApplyScalingGroupRequest
+     * @return ApplyScalingGroupResponse
+     */
     applyScalingGroup(request: ApplyScalingGroupRequest): Promise<ApplyScalingGroupResponse>;
     /**
-      * Before you associate an ALB server group with a scaling group, make sure that the following requirements are met:
-      * *   The scaling group resides in a virtual private cloud (VPC). The scaling group and the ALB server group must reside in the same VPC.
-      * *   The ALB server group is in the Available state.
-      * *   You can associate only a limited number of ALB server groups with a scaling group. To view the quota or manually request a quota increase, go to [Quota Center](https://quotas.console.aliyun.com/products/ess/quotas).
-      *
-      * @param request AttachAlbServerGroupsRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return AttachAlbServerGroupsResponse
+     * @summary Associates Application Load Balancer (ALB) server groups with a scaling group.
+     *
+     * @description Before you associate an ALB server group with a scaling group, make sure that the following requirements are met:
+     * *   The scaling group resides in a virtual private cloud (VPC). The scaling group and the ALB server group must reside in the same VPC.
+     * *   The ALB server group is in the Available state.
+     * *   You can associate only a limited number of ALB server groups with a scaling group. To view the quota or manually request a quota increase, go to [Quota Center](https://quotas.console.aliyun.com/products/ess/quotas).
+     *
+     * @param request AttachAlbServerGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return AttachAlbServerGroupsResponse
      */
     attachAlbServerGroupsWithOptions(request: AttachAlbServerGroupsRequest, runtime: $Util.RuntimeOptions): Promise<AttachAlbServerGroupsResponse>;
     /**
-      * Before you associate an ALB server group with a scaling group, make sure that the following requirements are met:
-      * *   The scaling group resides in a virtual private cloud (VPC). The scaling group and the ALB server group must reside in the same VPC.
-      * *   The ALB server group is in the Available state.
-      * *   You can associate only a limited number of ALB server groups with a scaling group. To view the quota or manually request a quota increase, go to [Quota Center](https://quotas.console.aliyun.com/products/ess/quotas).
-      *
-      * @param request AttachAlbServerGroupsRequest
-      * @return AttachAlbServerGroupsResponse
+     * @summary Associates Application Load Balancer (ALB) server groups with a scaling group.
+     *
+     * @description Before you associate an ALB server group with a scaling group, make sure that the following requirements are met:
+     * *   The scaling group resides in a virtual private cloud (VPC). The scaling group and the ALB server group must reside in the same VPC.
+     * *   The ALB server group is in the Available state.
+     * *   You can associate only a limited number of ALB server groups with a scaling group. To view the quota or manually request a quota increase, go to [Quota Center](https://quotas.console.aliyun.com/products/ess/quotas).
+     *
+     * @param request AttachAlbServerGroupsRequest
+     * @return AttachAlbServerGroupsResponse
      */
     attachAlbServerGroups(request: AttachAlbServerGroupsRequest): Promise<AttachAlbServerGroupsResponse>;
     /**
-      * Before you associate an ApsaraDB RDS instance with a scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
-      * *   The ApsaraDB RDS instance and the scaling group must belong to the same Alibaba Cloud account.
-      * *   The ApsaraDB RDS instance must be unlocked. For more information about the lock policy, see [ApsaraDB RDS usage notes](~~41872~~).
-      * *   The ApsaraDB RDS instance must be in the Running state.
-      * After an ApsaraDB RDS instance is associated with the scaling group, the default IP address whitelist of the ApsaraDB RDS instance can contain no more than 1,000 IP addresses. For more information, see [Set the whitelist](~~43185~~).
-      *
-      * @param request AttachDBInstancesRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return AttachDBInstancesResponse
+     * @summary Associates one or more ApsaraDB RDS instances with a scaling group.
+     *
+     * @description Before you associate an ApsaraDB RDS instance with a scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
+     * *   The ApsaraDB RDS instance and the scaling group must belong to the same Alibaba Cloud account.
+     * *   The ApsaraDB RDS instance must be unlocked. For more information about the lock policy, see [ApsaraDB RDS usage notes](https://help.aliyun.com/document_detail/41872.html).
+     * *   The ApsaraDB RDS instance must be in the Running state.
+     * After an ApsaraDB RDS instance is associated with the scaling group, the default IP address whitelist of the ApsaraDB RDS instance can contain no more than 1,000 IP addresses. For more information, see [Set the whitelist](https://help.aliyun.com/document_detail/43185.html).
+     *
+     * @param request AttachDBInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return AttachDBInstancesResponse
      */
     attachDBInstancesWithOptions(request: AttachDBInstancesRequest, runtime: $Util.RuntimeOptions): Promise<AttachDBInstancesResponse>;
     /**
-      * Before you associate an ApsaraDB RDS instance with a scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
-      * *   The ApsaraDB RDS instance and the scaling group must belong to the same Alibaba Cloud account.
-      * *   The ApsaraDB RDS instance must be unlocked. For more information about the lock policy, see [ApsaraDB RDS usage notes](~~41872~~).
-      * *   The ApsaraDB RDS instance must be in the Running state.
-      * After an ApsaraDB RDS instance is associated with the scaling group, the default IP address whitelist of the ApsaraDB RDS instance can contain no more than 1,000 IP addresses. For more information, see [Set the whitelist](~~43185~~).
-      *
-      * @param request AttachDBInstancesRequest
-      * @return AttachDBInstancesResponse
+     * @summary Associates one or more ApsaraDB RDS instances with a scaling group.
+     *
+     * @description Before you associate an ApsaraDB RDS instance with a scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
+     * *   The ApsaraDB RDS instance and the scaling group must belong to the same Alibaba Cloud account.
+     * *   The ApsaraDB RDS instance must be unlocked. For more information about the lock policy, see [ApsaraDB RDS usage notes](https://help.aliyun.com/document_detail/41872.html).
+     * *   The ApsaraDB RDS instance must be in the Running state.
+     * After an ApsaraDB RDS instance is associated with the scaling group, the default IP address whitelist of the ApsaraDB RDS instance can contain no more than 1,000 IP addresses. For more information, see [Set the whitelist](https://help.aliyun.com/document_detail/43185.html).
+     *
+     * @param request AttachDBInstancesRequest
+     * @return AttachDBInstancesResponse
      */
     attachDBInstances(request: AttachDBInstancesRequest): Promise<AttachDBInstancesResponse>;
     /**
-      * Before you call this operation, take note of the following items:
-      * *   The scaling group is in the Active state.
-      * *   No scaling activities in the scaling group are in progress.
-      * The ECS instances or the elastic container instances that you want to add to a scaling group must meet the following requirements:
-      * *   The instances reside in the same region as the scaling group.
-      * *   The instances must be in the Running state.
-      * *   The instances are not added to other scaling groups.
-      * *   The instances use the subscription or pay-as-you-go billing method, or are preemptible instances.
-      * *   If the VswitchID parameter is specified for a scaling group, the instances that are in the classic network or those that are not in the same virtual private cloud (VPC) as the specified vSwitch cannot be added to the scaling group.
-      * *   If the VswitchID parameter is not specified for a scaling group, the instances that are in VPCs cannot be added to the scaling group.
-      * If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
-      * If the sum of the number of instances that you want to add and the number of existing instances in the scaling group is greater than the value of the MaxSize parameter, the call fails.
-      * Instances that are manually added by calling the AttachInstances operation are not associated with the active scaling configuration of the scaling group.
-      *
-      * @param request AttachInstancesRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return AttachInstancesResponse
+     * @summary Adds instances to a scaling group. You can call the AttachInstances operation to add independent Elastic Compute Service (ECS) instances, elastic container instances, or non-Alibaba Cloud instances to your scaling group to provide services. You can also call this operation to change the state of ECS instances in your scaling group from Economical Mode to In Service.
+     *
+     * @description Before you call this operation, take note of the following items:
+     * *   The scaling group is in the Active state.
+     * *   No scaling activities in the scaling group are in progress.
+     * The ECS instances or the elastic container instances that you want to add to a scaling group must meet the following requirements:
+     * *   The instances reside in the same region as the scaling group.
+     * *   The instances must be in the Running state.
+     * *   The instances are not added to other scaling groups.
+     * *   The instances use the subscription or pay-as-you-go billing method, or are preemptible instances.
+     * *   If the VswitchID parameter is specified for a scaling group, the instances that are in the classic network or those that are not in the same virtual private cloud (VPC) as the specified vSwitch cannot be added to the scaling group.
+     * *   If the VswitchID parameter is not specified for a scaling group, the instances that are in VPCs cannot be added to the scaling group.
+     * If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
+     * If the sum of the number of instances that you want to add and the number of existing instances in the scaling group is greater than the value of the MaxSize parameter, the call fails.
+     * Instances that are manually added by calling the AttachInstances operation are not associated with the active scaling configuration of the scaling group.
+     *
+     * @param request AttachInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return AttachInstancesResponse
      */
     attachInstancesWithOptions(request: AttachInstancesRequest, runtime: $Util.RuntimeOptions): Promise<AttachInstancesResponse>;
     /**
-      * Before you call this operation, take note of the following items:
-      * *   The scaling group is in the Active state.
-      * *   No scaling activities in the scaling group are in progress.
-      * The ECS instances or the elastic container instances that you want to add to a scaling group must meet the following requirements:
-      * *   The instances reside in the same region as the scaling group.
-      * *   The instances must be in the Running state.
-      * *   The instances are not added to other scaling groups.
-      * *   The instances use the subscription or pay-as-you-go billing method, or are preemptible instances.
-      * *   If the VswitchID parameter is specified for a scaling group, the instances that are in the classic network or those that are not in the same virtual private cloud (VPC) as the specified vSwitch cannot be added to the scaling group.
-      * *   If the VswitchID parameter is not specified for a scaling group, the instances that are in VPCs cannot be added to the scaling group.
-      * If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
-      * If the sum of the number of instances that you want to add and the number of existing instances in the scaling group is greater than the value of the MaxSize parameter, the call fails.
-      * Instances that are manually added by calling the AttachInstances operation are not associated with the active scaling configuration of the scaling group.
-      *
-      * @param request AttachInstancesRequest
-      * @return AttachInstancesResponse
+     * @summary Adds instances to a scaling group. You can call the AttachInstances operation to add independent Elastic Compute Service (ECS) instances, elastic container instances, or non-Alibaba Cloud instances to your scaling group to provide services. You can also call this operation to change the state of ECS instances in your scaling group from Economical Mode to In Service.
+     *
+     * @description Before you call this operation, take note of the following items:
+     * *   The scaling group is in the Active state.
+     * *   No scaling activities in the scaling group are in progress.
+     * The ECS instances or the elastic container instances that you want to add to a scaling group must meet the following requirements:
+     * *   The instances reside in the same region as the scaling group.
+     * *   The instances must be in the Running state.
+     * *   The instances are not added to other scaling groups.
+     * *   The instances use the subscription or pay-as-you-go billing method, or are preemptible instances.
+     * *   If the VswitchID parameter is specified for a scaling group, the instances that are in the classic network or those that are not in the same virtual private cloud (VPC) as the specified vSwitch cannot be added to the scaling group.
+     * *   If the VswitchID parameter is not specified for a scaling group, the instances that are in VPCs cannot be added to the scaling group.
+     * If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
+     * If the sum of the number of instances that you want to add and the number of existing instances in the scaling group is greater than the value of the MaxSize parameter, the call fails.
+     * Instances that are manually added by calling the AttachInstances operation are not associated with the active scaling configuration of the scaling group.
+     *
+     * @param request AttachInstancesRequest
+     * @return AttachInstancesResponse
      */
     attachInstances(request: AttachInstancesRequest): Promise<AttachInstancesResponse>;
     /**
-      * Before you call this operation to attach a CLB instance to your scaling group, take note of the following items:
-      * *   The CLB instance and the scaling group must belong to the same Alibaba Cloud account.
-      * *   The CLB instance and the scaling group must reside in the same region.
-      * *   The CLB instance must be in the Running state.
-      * *   The CLB instance must be configured with at least one listener. Health check is enabled for the CLB instance.
-      * *   The CLB instance and the scaling group must be in the same virtual private cloud (VPC) if their network type is VPC.
-      * *   If the network type of the scaling group is VPC, the network type of the CLB instance is classic network, and the CLB backend server groups contain instances of the VPC network type, the instances and the scaling group must be in the same VPC.
-      * *   You can attach only a limited number of CLB instances to a scaling group. Fore more information, see [Limits](~~25863~~).
-      *
-      * @param request AttachLoadBalancersRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return AttachLoadBalancersResponse
+     * @summary Attaches load balancers to a scaling group. Auto Scaling supports the attachment of load balancers to scaling groups. Load balancers help distribute the access traffic to the instances in scaling groups, which effectively improves the service performance of the scaling groups. You can call the AttachLoadBalancers operation to attach one or more load balancers to your scaling group.
+     *
+     * @description Before you call this operation, make sure that the following requirements are met:
+     * *   The load balancer and the scaling group belong to the same Alibaba Cloud account and region.
+     * *   The load balancer is in the `Running` state.
+     * *   At least one listener is configured for the load balancer, and the health check feature is enabled for the load balancer.
+     * *   If the network type of the load balancer and the scaling group is virtual private cloud (VPC), they use the same VPC.
+     * *   If the network type of the scaling group is VPC, and that of the load balancer is classic network and a backend server of the load balancer uses a VPC, the scaling group and the backend server use the same VPC.
+     * *   The attachment of load balancers ensures that the cumulative number of load balancers attached to the scaling group stays within the predefined maximum limit. For information about the load balancer quota, see [Limits](https://help.aliyun.com/document_detail/25863.html).
+     *
+     * @param request AttachLoadBalancersRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return AttachLoadBalancersResponse
      */
     attachLoadBalancersWithOptions(request: AttachLoadBalancersRequest, runtime: $Util.RuntimeOptions): Promise<AttachLoadBalancersResponse>;
     /**
-      * Before you call this operation to attach a CLB instance to your scaling group, take note of the following items:
-      * *   The CLB instance and the scaling group must belong to the same Alibaba Cloud account.
-      * *   The CLB instance and the scaling group must reside in the same region.
-      * *   The CLB instance must be in the Running state.
-      * *   The CLB instance must be configured with at least one listener. Health check is enabled for the CLB instance.
-      * *   The CLB instance and the scaling group must be in the same virtual private cloud (VPC) if their network type is VPC.
-      * *   If the network type of the scaling group is VPC, the network type of the CLB instance is classic network, and the CLB backend server groups contain instances of the VPC network type, the instances and the scaling group must be in the same VPC.
-      * *   You can attach only a limited number of CLB instances to a scaling group. Fore more information, see [Limits](~~25863~~).
-      *
-      * @param request AttachLoadBalancersRequest
-      * @return AttachLoadBalancersResponse
+     * @summary Attaches load balancers to a scaling group. Auto Scaling supports the attachment of load balancers to scaling groups. Load balancers help distribute the access traffic to the instances in scaling groups, which effectively improves the service performance of the scaling groups. You can call the AttachLoadBalancers operation to attach one or more load balancers to your scaling group.
+     *
+     * @description Before you call this operation, make sure that the following requirements are met:
+     * *   The load balancer and the scaling group belong to the same Alibaba Cloud account and region.
+     * *   The load balancer is in the `Running` state.
+     * *   At least one listener is configured for the load balancer, and the health check feature is enabled for the load balancer.
+     * *   If the network type of the load balancer and the scaling group is virtual private cloud (VPC), they use the same VPC.
+     * *   If the network type of the scaling group is VPC, and that of the load balancer is classic network and a backend server of the load balancer uses a VPC, the scaling group and the backend server use the same VPC.
+     * *   The attachment of load balancers ensures that the cumulative number of load balancers attached to the scaling group stays within the predefined maximum limit. For information about the load balancer quota, see [Limits](https://help.aliyun.com/document_detail/25863.html).
+     *
+     * @param request AttachLoadBalancersRequest
+     * @return AttachLoadBalancersResponse
      */
     attachLoadBalancers(request: AttachLoadBalancersRequest): Promise<AttachLoadBalancersResponse>;
+    /**
+     * @summary Attaches one or more server groups to a scaling group. You can attach the following server groups to a scaling group: Application Load Balancer (ALB) and Network Load Balancer (NLB) server groups.
+     *
+     * @param request AttachServerGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return AttachServerGroupsResponse
+     */
     attachServerGroupsWithOptions(request: AttachServerGroupsRequest, runtime: $Util.RuntimeOptions): Promise<AttachServerGroupsResponse>;
+    /**
+     * @summary Attaches one or more server groups to a scaling group. You can attach the following server groups to a scaling group: Application Load Balancer (ALB) and Network Load Balancer (NLB) server groups.
+     *
+     * @param request AttachServerGroupsRequest
+     * @return AttachServerGroupsResponse
+     */
     attachServerGroups(request: AttachServerGroupsRequest): Promise<AttachServerGroupsResponse>;
     /**
-      * Before you call this operation to attach a vServer group to your scaling group, take note of the following items:
-      * *   The CLB instance and the scaling group must belong to the same Alibaba Cloud account.
-      * *   The CLB instance and the scaling group must reside in the same region.
-      * *   The CLB instance must be in the Running state.
-      * *   The CLB instance must be configured with at least one listener. Health check is enabled for the CLB instance.
-      * *   The CLB instance and the scaling group must be in the same VPC if their network type is VPC.
-      * *   If the network type of the scaling group is VPC, the network type of the CLB instance is classic network, and the vServer groups of the CLB instance contain instances of the VPC network type, the instances and the scaling group must be in the same VPC.
-      * *   The vServer group that you want to attach to your scaling group must belong to the CLB instance.
-      * *   You can attach only a limited number of vServer groups to a scaling group. For information about the quota on vServer groups, see [Limits](~~25863~~).
-      * When you call this operation, you must specify the following parameters:
-      * *   LoadBalancerId: the ID of the CLB instance.
-      * *   VServerGroupId: the ID of the vServer group.
-      * *   Port: the port number of the vServer group.
-      * If a vServer group is attached to a scaling group by using different ports, Auto Scaling considers that more than one vServer group is attached to the scaling group. If multiple vServer groups with the same group ID and port number are specified in the request parameters, only the first vServer group is used. The other vServer groups are ignored.
-      *
-      * @param request AttachVServerGroupsRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return AttachVServerGroupsResponse
+     * @summary Associates Sever Load Balancer (SLB) vServer groups with a scaling group.
+     *
+     * @description Before you call this operation to attach a vServer group to your scaling group, take note of the following items:
+     * *   The CLB instance and the scaling group must belong to the same Alibaba Cloud account.
+     * *   The CLB instance and the scaling group must reside in the same region.
+     * *   The CLB instance must be in the Running state.
+     * *   The CLB instance must be configured with at least one listener. Health check is enabled for the CLB instance.
+     * *   The CLB instance and the scaling group must be in the same VPC if their network type is VPC.
+     * *   If the network type of the scaling group is VPC, the network type of the CLB instance is classic network, and the vServer groups of the CLB instance contain instances of the VPC network type, the instances and the scaling group must be in the same VPC.
+     * *   The vServer group that you want to attach to your scaling group must belong to the CLB instance.
+     * *   You can attach only a limited number of vServer groups to a scaling group. For information about the quota on vServer groups, see [Limits](https://help.aliyun.com/document_detail/25863.html).
+     * When you call this operation, you must specify the following parameters:
+     * *   LoadBalancerId: the ID of the CLB instance.
+     * *   VServerGroupId: the ID of the vServer group.
+     * *   Port: the port number of the vServer group.
+     * If a vServer group is attached to a scaling group by using different ports, Auto Scaling considers that more than one vServer group is attached to the scaling group. If multiple vServer groups with the same group ID and port number are specified in the request parameters, only the first vServer group is used. The other vServer groups are ignored.
+     *
+     * @param request AttachVServerGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return AttachVServerGroupsResponse
      */
     attachVServerGroupsWithOptions(request: AttachVServerGroupsRequest, runtime: $Util.RuntimeOptions): Promise<AttachVServerGroupsResponse>;
     /**
-      * Before you call this operation to attach a vServer group to your scaling group, take note of the following items:
-      * *   The CLB instance and the scaling group must belong to the same Alibaba Cloud account.
-      * *   The CLB instance and the scaling group must reside in the same region.
-      * *   The CLB instance must be in the Running state.
-      * *   The CLB instance must be configured with at least one listener. Health check is enabled for the CLB instance.
-      * *   The CLB instance and the scaling group must be in the same VPC if their network type is VPC.
-      * *   If the network type of the scaling group is VPC, the network type of the CLB instance is classic network, and the vServer groups of the CLB instance contain instances of the VPC network type, the instances and the scaling group must be in the same VPC.
-      * *   The vServer group that you want to attach to your scaling group must belong to the CLB instance.
-      * *   You can attach only a limited number of vServer groups to a scaling group. For information about the quota on vServer groups, see [Limits](~~25863~~).
-      * When you call this operation, you must specify the following parameters:
-      * *   LoadBalancerId: the ID of the CLB instance.
-      * *   VServerGroupId: the ID of the vServer group.
-      * *   Port: the port number of the vServer group.
-      * If a vServer group is attached to a scaling group by using different ports, Auto Scaling considers that more than one vServer group is attached to the scaling group. If multiple vServer groups with the same group ID and port number are specified in the request parameters, only the first vServer group is used. The other vServer groups are ignored.
-      *
-      * @param request AttachVServerGroupsRequest
-      * @return AttachVServerGroupsResponse
+     * @summary Associates Sever Load Balancer (SLB) vServer groups with a scaling group.
+     *
+     * @description Before you call this operation to attach a vServer group to your scaling group, take note of the following items:
+     * *   The CLB instance and the scaling group must belong to the same Alibaba Cloud account.
+     * *   The CLB instance and the scaling group must reside in the same region.
+     * *   The CLB instance must be in the Running state.
+     * *   The CLB instance must be configured with at least one listener. Health check is enabled for the CLB instance.
+     * *   The CLB instance and the scaling group must be in the same VPC if their network type is VPC.
+     * *   If the network type of the scaling group is VPC, the network type of the CLB instance is classic network, and the vServer groups of the CLB instance contain instances of the VPC network type, the instances and the scaling group must be in the same VPC.
+     * *   The vServer group that you want to attach to your scaling group must belong to the CLB instance.
+     * *   You can attach only a limited number of vServer groups to a scaling group. For information about the quota on vServer groups, see [Limits](https://help.aliyun.com/document_detail/25863.html).
+     * When you call this operation, you must specify the following parameters:
+     * *   LoadBalancerId: the ID of the CLB instance.
+     * *   VServerGroupId: the ID of the vServer group.
+     * *   Port: the port number of the vServer group.
+     * If a vServer group is attached to a scaling group by using different ports, Auto Scaling considers that more than one vServer group is attached to the scaling group. If multiple vServer groups with the same group ID and port number are specified in the request parameters, only the first vServer group is used. The other vServer groups are ignored.
+     *
+     * @param request AttachVServerGroupsRequest
+     * @return AttachVServerGroupsResponse
      */
     attachVServerGroups(request: AttachVServerGroupsRequest): Promise<AttachVServerGroupsResponse>;
+    /**
+     * @summary Adds a scaling group to a resource group.
+     *
+     * @param request ChangeResourceGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ChangeResourceGroupResponse
+     */
     changeResourceGroupWithOptions(request: ChangeResourceGroupRequest, runtime: $Util.RuntimeOptions): Promise<ChangeResourceGroupResponse>;
+    /**
+     * @summary Adds a scaling group to a resource group.
+     *
+     * @param request ChangeResourceGroupRequest
+     * @return ChangeResourceGroupResponse
+     */
     changeResourceGroup(request: ChangeResourceGroupRequest): Promise<ChangeResourceGroupResponse>;
     /**
-      * If you set the LifecycleActionResult parameter for a lifecycle hook of a scaling group to CONTINUE in the operation, Auto Scaling continues to complete the scaling activity in the scaling group after the lifecycle hook times out. If you set the LifecycleActionResult parameter to ABANDON, Auto Scaling stops the scaling activity in the scaling group after the lifecycle hook times out.
-      *
-      * @param request CompleteLifecycleActionRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CompleteLifecycleActionResponse
+     * @summary Ends the timeout period of a lifecycle hook ahead of schedule. If you have created a lifecycle hook for your scaling group, you can call the CompleteLifecycleAction operation to end the timeout period of the lifecycle hook ahead of schedule based on your business requirements.
+     *
+     * @description When you manually cut short the timeout period of a lifecycle hook, Auto Scaling proceeds with one of the following actions based on the predefined settings: responding to the scaling request, aborting the scaling request, and initiating a rollback process.
+     *
+     * @param request CompleteLifecycleActionRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CompleteLifecycleActionResponse
      */
     completeLifecycleActionWithOptions(request: CompleteLifecycleActionRequest, runtime: $Util.RuntimeOptions): Promise<CompleteLifecycleActionResponse>;
     /**
-      * If you set the LifecycleActionResult parameter for a lifecycle hook of a scaling group to CONTINUE in the operation, Auto Scaling continues to complete the scaling activity in the scaling group after the lifecycle hook times out. If you set the LifecycleActionResult parameter to ABANDON, Auto Scaling stops the scaling activity in the scaling group after the lifecycle hook times out.
-      *
-      * @param request CompleteLifecycleActionRequest
-      * @return CompleteLifecycleActionResponse
+     * @summary Ends the timeout period of a lifecycle hook ahead of schedule. If you have created a lifecycle hook for your scaling group, you can call the CompleteLifecycleAction operation to end the timeout period of the lifecycle hook ahead of schedule based on your business requirements.
+     *
+     * @description When you manually cut short the timeout period of a lifecycle hook, Auto Scaling proceeds with one of the following actions based on the predefined settings: responding to the scaling request, aborting the scaling request, and initiating a rollback process.
+     *
+     * @param request CompleteLifecycleActionRequest
+     * @return CompleteLifecycleActionResponse
      */
     completeLifecycleAction(request: CompleteLifecycleActionRequest): Promise<CompleteLifecycleActionResponse>;
+    /**
+     * @summary Creates an event-triggered task.
+     *
+     * @description *   If you set the MetricType parameter to custom, you must report your custom metrics to CloudMonitor before you can create event-triggered tasks by using custom metrics. For more information, see [Custom monitoring event-triggered tasks](https://help.aliyun.com/document_detail/74861.html).
+     * *   When you create an event-triggered task, you must specify the MetricName, DimensionKey, and DimensionValue parameters to determine the range of statistics that you want to aggregate for the metrics of the scaling group. For example, you can specify the user_id and scaling_group dimensions for an event-triggered task to aggregate monitoring data of all Elastic Compute Service (ECS) instances or elastic container instances in a scaling group within an Alibaba Cloud account.
+     *     *   If you set the MetricType parameter to custom, the valid values are your custom metrics.
+     *     *   For information about the supported metrics when you set the MetricType parameter to system, see [Event-triggered task for system monitoring](https://help.aliyun.com/document_detail/74854.html).
+     * > The user_id and scaling_group dimensions are automatically populated. You need to only specify the device and state dimensions. For more information, see the `DimensionKey` and `DimensionValue` parameters in the "Request parameters" section of this topic.
+     *
+     * @param request CreateAlarmRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateAlarmResponse
+     */
     createAlarmWithOptions(request: CreateAlarmRequest, runtime: $Util.RuntimeOptions): Promise<CreateAlarmResponse>;
+    /**
+     * @summary Creates an event-triggered task.
+     *
+     * @description *   If you set the MetricType parameter to custom, you must report your custom metrics to CloudMonitor before you can create event-triggered tasks by using custom metrics. For more information, see [Custom monitoring event-triggered tasks](https://help.aliyun.com/document_detail/74861.html).
+     * *   When you create an event-triggered task, you must specify the MetricName, DimensionKey, and DimensionValue parameters to determine the range of statistics that you want to aggregate for the metrics of the scaling group. For example, you can specify the user_id and scaling_group dimensions for an event-triggered task to aggregate monitoring data of all Elastic Compute Service (ECS) instances or elastic container instances in a scaling group within an Alibaba Cloud account.
+     *     *   If you set the MetricType parameter to custom, the valid values are your custom metrics.
+     *     *   For information about the supported metrics when you set the MetricType parameter to system, see [Event-triggered task for system monitoring](https://help.aliyun.com/document_detail/74854.html).
+     * > The user_id and scaling_group dimensions are automatically populated. You need to only specify the device and state dimensions. For more information, see the `DimensionKey` and `DimensionValue` parameters in the "Request parameters" section of this topic.
+     *
+     * @param request CreateAlarmRequest
+     * @return CreateAlarmResponse
+     */
     createAlarm(request: CreateAlarmRequest): Promise<CreateAlarmResponse>;
     /**
-      * A scaling configuration is a template that is used to create elastic container instances during scale-out activities.
-      * You can specify the Cpu and Memory parameters to determine the range of instance types. If you specify the parameters, Auto Scaling determines the available instance types based on factors such as I/O optimization requirements and zones. Auto Scaling preferentially creates elastic container instances of the instance type that is provided at the lowest price. This scaling mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
-      *
-      * @param request CreateEciScalingConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateEciScalingConfigurationResponse
+     * @summary Creates a scaling configuration of the Elastic Container Instance type. Auto Scaling uses the scaling configuration as a template to create elastic container instances to meet your business requirements during scale-outs.
+     *
+     * @description A scaling configuration is a template that is used to create elastic container instances during scale-out activities.
+     * You can specify the Cpu and Memory parameters to determine the range of instance types. If you specify the parameters, Auto Scaling determines the available instance types based on factors such as I/O optimization requirements and zones. Auto Scaling preferentially creates elastic container instances of the instance type that is provided at the lowest price. This scaling mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
+     *
+     * @param request CreateEciScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateEciScalingConfigurationResponse
      */
     createEciScalingConfigurationWithOptions(request: CreateEciScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<CreateEciScalingConfigurationResponse>;
     /**
-      * A scaling configuration is a template that is used to create elastic container instances during scale-out activities.
-      * You can specify the Cpu and Memory parameters to determine the range of instance types. If you specify the parameters, Auto Scaling determines the available instance types based on factors such as I/O optimization requirements and zones. Auto Scaling preferentially creates elastic container instances of the instance type that is provided at the lowest price. This scaling mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
-      *
-      * @param request CreateEciScalingConfigurationRequest
-      * @return CreateEciScalingConfigurationResponse
+     * @summary Creates a scaling configuration of the Elastic Container Instance type. Auto Scaling uses the scaling configuration as a template to create elastic container instances to meet your business requirements during scale-outs.
+     *
+     * @description A scaling configuration is a template that is used to create elastic container instances during scale-out activities.
+     * You can specify the Cpu and Memory parameters to determine the range of instance types. If you specify the parameters, Auto Scaling determines the available instance types based on factors such as I/O optimization requirements and zones. Auto Scaling preferentially creates elastic container instances of the instance type that is provided at the lowest price. This scaling mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
+     *
+     * @param request CreateEciScalingConfigurationRequest
+     * @return CreateEciScalingConfigurationResponse
      */
     createEciScalingConfiguration(request: CreateEciScalingConfigurationRequest): Promise<CreateEciScalingConfigurationResponse>;
     /**
-      * You can create up to six lifecycle hooks for each scaling group. Elastic Compute Service (ECS) instances are not immediately added to or removed from scaling groups that have effective lifecycle hooks during scaling activities. The ECS instances are added to or removed from the scaling groups only after the lifecycle hooks time out. The period of time before the lifecycle hooks time out is specified by the HeartbeatTimeout parameter. Before lifecycle hooks time out, you can initialize the configurations of ECS instances and query data on the ECS instances.
-      * If lifecycle hooks take effect for scale-out activities, the private IP addresses of ECS instances are added to the IP address whitelists of the associated ApsaraDB RDS instances and the ECS instances are added to the backend server groups of the associated Server Load Balancer (SLB) instances only after the lifecycle hooks time out. If lifecycle hooks take effect for scale-in activities, the private IP addresses of ECS instances are removed from the IP address whitelists of the disassociated ApsaraDB RDS instances and the ECS instances are removed from the backend server groups of the disassociated SLB instances only after the lifecycle hooks time out.
-      * You can configure a notification method for a lifecycle hook. When the lifecycle hook takes effect, a notification can be sent by using a Message Service (MNS) topic, an MNS queue, or an Operation Orchestration Service (OOS) template. If you want to configure an OOS template, you must create a RAM role for OOS. For more information, see [Grant RAM permissions to OOS](~~120810~~).
-      * > If your scaling group contains ECS instances and you configure an OOS template to add the private IP addresses of the ECS instances to or remove the private IP addresses of the ECS instances from the IP address whitelists of cloud databases other than ApsaraDB RDS databases, you must manually add the private IP addresses of the ECS instances to the IP address whitelists of the cloud databases.
-      *
-      * @param request CreateLifecycleHookRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateLifecycleHookResponse
+     * @summary Creates one or more lifecycle hooks.
+     *
+     * @description You can create up to six lifecycle hooks for each scaling group. After a lifecycle hook is created for a scaling group, Elastic Compute Service (ECS) instances in the scaling group waits to be added to or removed from the scaling group during scaling activities. You can use the HeartbeatTimeout parameter to specify the timeout period of the lifecycle hook. During the timeout period of a lifecycle hook, you can perform custom operations such as initialize ECS instance configurations and download ECS instance data on the ECS instances for which the lifecycle hook is applied.
+     * During a scale-out activity and the timeout period of a lifecycle hook, the private IP addresses of ECS instances wait to be added to the associated whitelist that manages access to the ApsaraDB RDS instance. The ECS instances also wait to be added to the backend server group of the associated Classic Load Balancer (CLB) instance. After the lifecycle hook times out, the private IP addresses of the ECS instances are added to the whitelist that manages access to the associated ApsaraDB RDS instance. The ECS instances are also added to the backend server group of the associated CLB instance. During a scale-in activity and the timeout period of a lifecycle hook, the private IP addresses of ECS instances wait to be removed from the whitelist that manages access to the associated ApsaraDB RDS instance. The ECS instances also wait to be removed from the backend server group of the associated CLB instance. After the lifecycle hook times out, the private IP addresses of the ECS instances are removed from the whitelist that manages access to the associated ApsaraDB RDS instance. The ECS instances are also removed from the backend server group of the associated CLB instance.
+     * You can configure a notification method for a lifecycle hook. When the lifecycle hook is triggered, a notification can be sent to the specified Message Service (MNS) topic or queue, or an operation can be performed based on the specified Operation Orchestration Service (OOS) template. If you want to configure an OOS template, you must create a Resource Access Management (RAM) role for OOS. For more information, see [Grant RAM permissions to OOS](https://help.aliyun.com/document_detail/120810.html).
+     * > If your scaling group has existing ECS instances and you configured an OOS template that is used to add the private IP addresses of ECS instances to or remove the private IP addresses of ECS instances from the whitelists that manage access to cloud databases that are not ApsaraDB RDS databases, you must manually add the private IP addresses of the ECS instances to or remove the private IP addresses of the ECS instances from the whitelists that manage access to the cloud databases.
+     *
+     * @param request CreateLifecycleHookRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateLifecycleHookResponse
      */
     createLifecycleHookWithOptions(request: CreateLifecycleHookRequest, runtime: $Util.RuntimeOptions): Promise<CreateLifecycleHookResponse>;
     /**
-      * You can create up to six lifecycle hooks for each scaling group. Elastic Compute Service (ECS) instances are not immediately added to or removed from scaling groups that have effective lifecycle hooks during scaling activities. The ECS instances are added to or removed from the scaling groups only after the lifecycle hooks time out. The period of time before the lifecycle hooks time out is specified by the HeartbeatTimeout parameter. Before lifecycle hooks time out, you can initialize the configurations of ECS instances and query data on the ECS instances.
-      * If lifecycle hooks take effect for scale-out activities, the private IP addresses of ECS instances are added to the IP address whitelists of the associated ApsaraDB RDS instances and the ECS instances are added to the backend server groups of the associated Server Load Balancer (SLB) instances only after the lifecycle hooks time out. If lifecycle hooks take effect for scale-in activities, the private IP addresses of ECS instances are removed from the IP address whitelists of the disassociated ApsaraDB RDS instances and the ECS instances are removed from the backend server groups of the disassociated SLB instances only after the lifecycle hooks time out.
-      * You can configure a notification method for a lifecycle hook. When the lifecycle hook takes effect, a notification can be sent by using a Message Service (MNS) topic, an MNS queue, or an Operation Orchestration Service (OOS) template. If you want to configure an OOS template, you must create a RAM role for OOS. For more information, see [Grant RAM permissions to OOS](~~120810~~).
-      * > If your scaling group contains ECS instances and you configure an OOS template to add the private IP addresses of the ECS instances to or remove the private IP addresses of the ECS instances from the IP address whitelists of cloud databases other than ApsaraDB RDS databases, you must manually add the private IP addresses of the ECS instances to the IP address whitelists of the cloud databases.
-      *
-      * @param request CreateLifecycleHookRequest
-      * @return CreateLifecycleHookResponse
+     * @summary Creates one or more lifecycle hooks.
+     *
+     * @description You can create up to six lifecycle hooks for each scaling group. After a lifecycle hook is created for a scaling group, Elastic Compute Service (ECS) instances in the scaling group waits to be added to or removed from the scaling group during scaling activities. You can use the HeartbeatTimeout parameter to specify the timeout period of the lifecycle hook. During the timeout period of a lifecycle hook, you can perform custom operations such as initialize ECS instance configurations and download ECS instance data on the ECS instances for which the lifecycle hook is applied.
+     * During a scale-out activity and the timeout period of a lifecycle hook, the private IP addresses of ECS instances wait to be added to the associated whitelist that manages access to the ApsaraDB RDS instance. The ECS instances also wait to be added to the backend server group of the associated Classic Load Balancer (CLB) instance. After the lifecycle hook times out, the private IP addresses of the ECS instances are added to the whitelist that manages access to the associated ApsaraDB RDS instance. The ECS instances are also added to the backend server group of the associated CLB instance. During a scale-in activity and the timeout period of a lifecycle hook, the private IP addresses of ECS instances wait to be removed from the whitelist that manages access to the associated ApsaraDB RDS instance. The ECS instances also wait to be removed from the backend server group of the associated CLB instance. After the lifecycle hook times out, the private IP addresses of the ECS instances are removed from the whitelist that manages access to the associated ApsaraDB RDS instance. The ECS instances are also removed from the backend server group of the associated CLB instance.
+     * You can configure a notification method for a lifecycle hook. When the lifecycle hook is triggered, a notification can be sent to the specified Message Service (MNS) topic or queue, or an operation can be performed based on the specified Operation Orchestration Service (OOS) template. If you want to configure an OOS template, you must create a Resource Access Management (RAM) role for OOS. For more information, see [Grant RAM permissions to OOS](https://help.aliyun.com/document_detail/120810.html).
+     * > If your scaling group has existing ECS instances and you configured an OOS template that is used to add the private IP addresses of ECS instances to or remove the private IP addresses of ECS instances from the whitelists that manage access to cloud databases that are not ApsaraDB RDS databases, you must manually add the private IP addresses of the ECS instances to or remove the private IP addresses of the ECS instances from the whitelists that manage access to the cloud databases.
+     *
+     * @param request CreateLifecycleHookRequest
+     * @return CreateLifecycleHookResponse
      */
     createLifecycleHook(request: CreateLifecycleHookRequest): Promise<CreateLifecycleHookResponse>;
     /**
-      * ## Description
-      * You can configure CloudMonitor system events, Message Service (MNS) queues, or MNS topics to receive notifications. When a specified type of scaling activity or resource change occurs in a scaling group, Auto Scaling sends notifications by using CloudMonitor or MNS.
-      *
-      * @param request CreateNotificationConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateNotificationConfigurationResponse
+     * @summary Creates a notification rule. You can call the CreateNotificationConfiguration operation to create a notification rule to stay informed about scaling events or resource changes. This helps you learn about the dynamic status of your scaling group in real time and further automates the management of scaling events.
+     *
+     * @description ## Description
+     * You can configure CloudMonitor system events, Message Service (MNS) queues, or MNS topics to receive notifications. When a specified type of scaling activity or resource change occurs in a scaling group, Auto Scaling sends notifications by using CloudMonitor or MNS.
+     *
+     * @param request CreateNotificationConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateNotificationConfigurationResponse
      */
     createNotificationConfigurationWithOptions(request: CreateNotificationConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<CreateNotificationConfigurationResponse>;
     /**
-      * ## Description
-      * You can configure CloudMonitor system events, Message Service (MNS) queues, or MNS topics to receive notifications. When a specified type of scaling activity or resource change occurs in a scaling group, Auto Scaling sends notifications by using CloudMonitor or MNS.
-      *
-      * @param request CreateNotificationConfigurationRequest
-      * @return CreateNotificationConfigurationResponse
+     * @summary Creates a notification rule. You can call the CreateNotificationConfiguration operation to create a notification rule to stay informed about scaling events or resource changes. This helps you learn about the dynamic status of your scaling group in real time and further automates the management of scaling events.
+     *
+     * @description ## Description
+     * You can configure CloudMonitor system events, Message Service (MNS) queues, or MNS topics to receive notifications. When a specified type of scaling activity or resource change occurs in a scaling group, Auto Scaling sends notifications by using CloudMonitor or MNS.
+     *
+     * @param request CreateNotificationConfigurationRequest
+     * @return CreateNotificationConfigurationResponse
      */
     createNotificationConfiguration(request: CreateNotificationConfigurationRequest): Promise<CreateNotificationConfigurationResponse>;
     /**
-      * Auto Scaling automatically creates Elastic Compute Service (ECS) instances based on the specified scaling configuration. ECS instances can be created in the following modes:
-      * *   InstancePatternInfos: intelligent configuration mode. In this mode, you need to only specify the number of vCPUs, memory size, instance family, and maximum price. Auto Scaling selects the instance type that has the lowest price based on the configurations to create ECS instances. This mode is available only for scaling groups that reside in virtual private clouds (VPCs). This mode reduces scale-out failures caused by insufficient inventory of instance types.
-      * *   InstanceType: In this mode, you must specify one instance type.
-      * *   InstanceTypes: In this mode, you can specify more than one instance type.
-      * *   InstanceTypeOverrides: In this mode, you can specify multiple instance types and weights for the instance types.
-      * *   Cpu and Memory: In this mode, you must specify the number of vCPUs and the memory size. Auto Scaling determines the range of available instance types based on factors such as I/O optimization requirements and zones. Then, Auto Scaling creates ECS instances by using the lowest-priced instance type. This mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
-      * > You cannot specify InstanceType, InstanceTypes, InstanceTypeOverrides, and Cpu and Memory at the same time. You can specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfo at the same time. If you specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfos at the same time, Auto Scaling preferentially uses the instance types that are specified by InstanceType or InstanceTypes for scale-outs. If the instance types that are specified by InstanceType or InstanceTypes do not have sufficient inventory, Auto Scaling uses the instance types that are specified by InstancePatternInfos for scale-outs.
-      *
-      * @param tmpReq CreateScalingConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateScalingConfigurationResponse
+     * @summary Creates a scaling configuration.
+     *
+     * @description Auto Scaling automatically creates Elastic Compute Service (ECS) instances based on the specified scaling configuration. ECS instances can be created in the following modes:
+     * *   InstancePatternInfos: intelligent configuration mode. In this mode, you need to only specify the number of vCPUs, memory size, instance family, and maximum price. Auto Scaling selects the instance type that has the lowest price based on the configurations to create ECS instances. This mode is available only for scaling groups that reside in virtual private clouds (VPCs). This mode reduces scale-out failures caused by insufficient inventory of instance types.
+     * *   InstanceType: In this mode, you must specify one instance type.
+     * *   InstanceTypes: In this mode, you can specify more than one instance type.
+     * *   InstanceTypeOverrides: In this mode, you can specify multiple instance types and weights for the instance types.
+     * *   Cpu and Memory: In this mode, you must specify the number of vCPUs and the memory size. Auto Scaling determines the range of available instance types based on factors such as I/O optimization requirements and zones. Then, Auto Scaling creates ECS instances by using the lowest-priced instance type. This mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
+     * > You cannot specify InstanceType, InstanceTypes, InstanceTypeOverrides, and Cpu and Memory at the same time. You can specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfo at the same time. If you specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfos at the same time, Auto Scaling preferentially uses the instance types that are specified by InstanceType or InstanceTypes for scale-outs. If the instance types that are specified by InstanceType or InstanceTypes do not have sufficient inventory, Auto Scaling uses the instance types that are specified by InstancePatternInfos for scale-outs.
+     *
+     * @param tmpReq CreateScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateScalingConfigurationResponse
      */
     createScalingConfigurationWithOptions(tmpReq: CreateScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<CreateScalingConfigurationResponse>;
     /**
-      * Auto Scaling automatically creates Elastic Compute Service (ECS) instances based on the specified scaling configuration. ECS instances can be created in the following modes:
-      * *   InstancePatternInfos: intelligent configuration mode. In this mode, you need to only specify the number of vCPUs, memory size, instance family, and maximum price. Auto Scaling selects the instance type that has the lowest price based on the configurations to create ECS instances. This mode is available only for scaling groups that reside in virtual private clouds (VPCs). This mode reduces scale-out failures caused by insufficient inventory of instance types.
-      * *   InstanceType: In this mode, you must specify one instance type.
-      * *   InstanceTypes: In this mode, you can specify more than one instance type.
-      * *   InstanceTypeOverrides: In this mode, you can specify multiple instance types and weights for the instance types.
-      * *   Cpu and Memory: In this mode, you must specify the number of vCPUs and the memory size. Auto Scaling determines the range of available instance types based on factors such as I/O optimization requirements and zones. Then, Auto Scaling creates ECS instances by using the lowest-priced instance type. This mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
-      * > You cannot specify InstanceType, InstanceTypes, InstanceTypeOverrides, and Cpu and Memory at the same time. You can specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfo at the same time. If you specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfos at the same time, Auto Scaling preferentially uses the instance types that are specified by InstanceType or InstanceTypes for scale-outs. If the instance types that are specified by InstanceType or InstanceTypes do not have sufficient inventory, Auto Scaling uses the instance types that are specified by InstancePatternInfos for scale-outs.
-      *
-      * @param request CreateScalingConfigurationRequest
-      * @return CreateScalingConfigurationResponse
+     * @summary Creates a scaling configuration.
+     *
+     * @description Auto Scaling automatically creates Elastic Compute Service (ECS) instances based on the specified scaling configuration. ECS instances can be created in the following modes:
+     * *   InstancePatternInfos: intelligent configuration mode. In this mode, you need to only specify the number of vCPUs, memory size, instance family, and maximum price. Auto Scaling selects the instance type that has the lowest price based on the configurations to create ECS instances. This mode is available only for scaling groups that reside in virtual private clouds (VPCs). This mode reduces scale-out failures caused by insufficient inventory of instance types.
+     * *   InstanceType: In this mode, you must specify one instance type.
+     * *   InstanceTypes: In this mode, you can specify more than one instance type.
+     * *   InstanceTypeOverrides: In this mode, you can specify multiple instance types and weights for the instance types.
+     * *   Cpu and Memory: In this mode, you must specify the number of vCPUs and the memory size. Auto Scaling determines the range of available instance types based on factors such as I/O optimization requirements and zones. Then, Auto Scaling creates ECS instances by using the lowest-priced instance type. This mode is available only if Scaling Policy is set to Cost Optimization Policy and no instance type is specified in the scaling configuration.
+     * > You cannot specify InstanceType, InstanceTypes, InstanceTypeOverrides, and Cpu and Memory at the same time. You can specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfo at the same time. If you specify InstanceType and InstancePatternInfos or specify InstanceTypes and InstancePatternInfos at the same time, Auto Scaling preferentially uses the instance types that are specified by InstanceType or InstanceTypes for scale-outs. If the instance types that are specified by InstanceType or InstanceTypes do not have sufficient inventory, Auto Scaling uses the instance types that are specified by InstancePatternInfos for scale-outs.
+     *
+     * @param request CreateScalingConfigurationRequest
+     * @return CreateScalingConfigurationResponse
      */
     createScalingConfiguration(request: CreateScalingConfigurationRequest): Promise<CreateScalingConfigurationResponse>;
     /**
-      * A scaling group is a group of Elastic Compute Service (ECS) instances that can be used in similar business scenarios.
-      * You can create only a limited number of scaling groups in a region. Go to Quota Center to check the quota of the scaling groups.
-      * A scaling group does not immediately take effect after you create the scaling group. You must call the EnableScalingGroup operation to enable the scaling group. After you enable the scaling group, Auto Scaling can execute scaling rules to trigger scaling activities in the scaling group.
-      * The Classic Load Balancer (CLB) instances and ApsaraDB RDS instances that you want to associate with a scaling group must reside in the same region as the scaling group. CLB instances are formerly known as Server Load Balancer (SLB) instances. For more information, see the [Regions and zones](~~40654~~) topic.
-      * If you associate a CLB instance when you create a scaling group, Auto Scaling automatically adds ECS instances in the scaling group to the backend server group of the associated CLB instance. You can specify a server group to which ECS instances can be added. You can add ECS instances to the following types of server groups:
-      * *   Default server group: a group of ECS instances that are used to receive requests. If you do not specify a vServer group or a primary/secondary server group for a listener, requests are forwarded to the ECS instances in the default server group.
-      * *   vServer group: If you want to forward requests to backend servers that are not in the default server group or configure domain name-based or URL-based forwarding rules, you can use vServer groups.
-      * > If you specify the default server group and multiple vServer groups at the same time, ECS instances are added to all specified server groups.
-      * The default weight of an ECS instance that is added as a backend server of a CLB instance is 50. The CLB instance that you want to associate with your scaling group must meet the following requirements:
-      * *   The CLB instance must be in the Active state. You can call the DescribeLoadBalancers operation to query the state of the CLB instance.
-      * *   The health check feature must be enabled on all listener ports that are configured for the CLB instance. Otherwise, the scaling group fails to be created.
-      * If you associate an Application Load Balancer (ALB) server group with a scaling group, Auto Scaling automatically adds ECS instances that are in the scaling group to the ALB server group to process requests distributed by the ALB instance to which the ALB server group belongs. You can specify multiple ALB server groups. The server groups must reside in the same virtual private cloud (VPC) as the scaling group. For more information, see the "AttachAlbServerGroups" topic.
-      * If you associate an ApsaraDB RDS instance with a scaling group, Auto Scaling automatically adds the private IP addresses of the ECS instances in the scaling group to the IP address whitelist of the ApsaraDB RDS instance. The ApsaraDB RDS instance that you want to associate with your scaling group must meet the following requirements:
-      * *   The ApsaraDB RDS instance must be in the Running state. You can call the DescribeDBInstances operation to query the state of the ApsaraDB RDS instance.
-      * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance cannot exceed the upper limit. For more information, see the "Configure whitelists" topic.
-      * If you set the MultiAZPolicy parameter of the scaling group to COST_OPTIMIZED, take note of the following items:
-      * *   You can use the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters to specify the instance allocation method based on the cost optimization policy. This instance allocation method is prioritized during scaling.
-      * *   If you do not specify the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools parameter, the instance types that are provided at the lowest price are used to create instances based on the cost optimization policy.
-      * If you set the `Tags.Propagate` parameter of the scaling group to true, the following rules apply:
-      * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
-      * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
-      * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
-      *
-      * @param request CreateScalingGroupRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateScalingGroupResponse
+     * @summary Creates a scaling group.
+     *
+     * @description A scaling group is a group of Elastic Compute Service (ECS) instances that can be used in similar business scenarios.
+     * You can create only a limited number of scaling groups in a region. Go to Quota Center to check the quota of the scaling groups.
+     * A scaling group does not immediately take effect after you create the scaling group. You must call the EnableScalingGroup operation to enable the scaling group. After you enable the scaling group, Auto Scaling can execute scaling rules to trigger scaling activities in the scaling group.
+     * The Classic Load Balancer (CLB) instances and ApsaraDB RDS instances that you want to associate with a scaling group must reside in the same region as the scaling group. CLB instances are formerly known as Server Load Balancer (SLB) instances. For more information, see the [Regions and zones](https://help.aliyun.com/document_detail/40654.html) topic.
+     * If you associate a CLB instance when you create a scaling group, Auto Scaling automatically adds ECS instances in the scaling group to the backend server group of the associated CLB instance. You can specify a server group to which ECS instances can be added. You can add ECS instances to the following types of server groups:
+     * *   Default server group: a group of ECS instances that are used to receive requests. If you do not specify a vServer group or a primary/secondary server group for a listener, requests are forwarded to the ECS instances in the default server group.
+     * *   vServer group: If you want to forward requests to backend servers that are not in the default server group or configure domain name-based or URL-based forwarding rules, you can use vServer groups.
+     * > If you specify the default server group and multiple vServer groups at the same time, ECS instances are added to all specified server groups.
+     * The default weight of an ECS instance that is added as a backend server of a CLB instance is 50. The CLB instance that you want to associate with your scaling group must meet the following requirements:
+     * *   The CLB instance must be in the Active state. You can call the DescribeLoadBalancers operation to query the state of the CLB instance.
+     * *   The health check feature must be enabled on all listener ports that are configured for the CLB instance. Otherwise, the scaling group fails to be created.
+     * If you associate an Application Load Balancer (ALB) server group with a scaling group, Auto Scaling automatically adds ECS instances that are in the scaling group to the ALB server group to process requests distributed by the ALB instance to which the ALB server group belongs. You can specify multiple ALB server groups. The server groups must reside in the same virtual private cloud (VPC) as the scaling group. For more information, see the "AttachAlbServerGroups" topic.
+     * If you associate an ApsaraDB RDS instance with a scaling group, Auto Scaling automatically adds the private IP addresses of the ECS instances in the scaling group to the IP address whitelist of the ApsaraDB RDS instance. The ApsaraDB RDS instance that you want to associate with your scaling group must meet the following requirements:
+     * *   The ApsaraDB RDS instance must be in the Running state. You can call the DescribeDBInstances operation to query the state of the ApsaraDB RDS instance.
+     * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance cannot exceed the upper limit. For more information, see the "Configure whitelists" topic.
+     * If you set the MultiAZPolicy parameter of the scaling group to COST_OPTIMIZED, take note of the following items:
+     * *   You can use the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters to specify the instance allocation method based on the cost optimization policy. This instance allocation method is prioritized during scaling.
+     * *   If you do not specify the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools parameter, the instance types that are provided at the lowest price are used to create instances based on the cost optimization policy.
+     * If you set the `Tags.Propagate` parameter of the scaling group to true, the following rules apply:
+     * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
+     * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
+     * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
+     *
+     * @param request CreateScalingGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateScalingGroupResponse
      */
     createScalingGroupWithOptions(request: CreateScalingGroupRequest, runtime: $Util.RuntimeOptions): Promise<CreateScalingGroupResponse>;
     /**
-      * A scaling group is a group of Elastic Compute Service (ECS) instances that can be used in similar business scenarios.
-      * You can create only a limited number of scaling groups in a region. Go to Quota Center to check the quota of the scaling groups.
-      * A scaling group does not immediately take effect after you create the scaling group. You must call the EnableScalingGroup operation to enable the scaling group. After you enable the scaling group, Auto Scaling can execute scaling rules to trigger scaling activities in the scaling group.
-      * The Classic Load Balancer (CLB) instances and ApsaraDB RDS instances that you want to associate with a scaling group must reside in the same region as the scaling group. CLB instances are formerly known as Server Load Balancer (SLB) instances. For more information, see the [Regions and zones](~~40654~~) topic.
-      * If you associate a CLB instance when you create a scaling group, Auto Scaling automatically adds ECS instances in the scaling group to the backend server group of the associated CLB instance. You can specify a server group to which ECS instances can be added. You can add ECS instances to the following types of server groups:
-      * *   Default server group: a group of ECS instances that are used to receive requests. If you do not specify a vServer group or a primary/secondary server group for a listener, requests are forwarded to the ECS instances in the default server group.
-      * *   vServer group: If you want to forward requests to backend servers that are not in the default server group or configure domain name-based or URL-based forwarding rules, you can use vServer groups.
-      * > If you specify the default server group and multiple vServer groups at the same time, ECS instances are added to all specified server groups.
-      * The default weight of an ECS instance that is added as a backend server of a CLB instance is 50. The CLB instance that you want to associate with your scaling group must meet the following requirements:
-      * *   The CLB instance must be in the Active state. You can call the DescribeLoadBalancers operation to query the state of the CLB instance.
-      * *   The health check feature must be enabled on all listener ports that are configured for the CLB instance. Otherwise, the scaling group fails to be created.
-      * If you associate an Application Load Balancer (ALB) server group with a scaling group, Auto Scaling automatically adds ECS instances that are in the scaling group to the ALB server group to process requests distributed by the ALB instance to which the ALB server group belongs. You can specify multiple ALB server groups. The server groups must reside in the same virtual private cloud (VPC) as the scaling group. For more information, see the "AttachAlbServerGroups" topic.
-      * If you associate an ApsaraDB RDS instance with a scaling group, Auto Scaling automatically adds the private IP addresses of the ECS instances in the scaling group to the IP address whitelist of the ApsaraDB RDS instance. The ApsaraDB RDS instance that you want to associate with your scaling group must meet the following requirements:
-      * *   The ApsaraDB RDS instance must be in the Running state. You can call the DescribeDBInstances operation to query the state of the ApsaraDB RDS instance.
-      * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance cannot exceed the upper limit. For more information, see the "Configure whitelists" topic.
-      * If you set the MultiAZPolicy parameter of the scaling group to COST_OPTIMIZED, take note of the following items:
-      * *   You can use the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters to specify the instance allocation method based on the cost optimization policy. This instance allocation method is prioritized during scaling.
-      * *   If you do not specify the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools parameter, the instance types that are provided at the lowest price are used to create instances based on the cost optimization policy.
-      * If you set the `Tags.Propagate` parameter of the scaling group to true, the following rules apply:
-      * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
-      * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
-      * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
-      *
-      * @param request CreateScalingGroupRequest
-      * @return CreateScalingGroupResponse
+     * @summary Creates a scaling group.
+     *
+     * @description A scaling group is a group of Elastic Compute Service (ECS) instances that can be used in similar business scenarios.
+     * You can create only a limited number of scaling groups in a region. Go to Quota Center to check the quota of the scaling groups.
+     * A scaling group does not immediately take effect after you create the scaling group. You must call the EnableScalingGroup operation to enable the scaling group. After you enable the scaling group, Auto Scaling can execute scaling rules to trigger scaling activities in the scaling group.
+     * The Classic Load Balancer (CLB) instances and ApsaraDB RDS instances that you want to associate with a scaling group must reside in the same region as the scaling group. CLB instances are formerly known as Server Load Balancer (SLB) instances. For more information, see the [Regions and zones](https://help.aliyun.com/document_detail/40654.html) topic.
+     * If you associate a CLB instance when you create a scaling group, Auto Scaling automatically adds ECS instances in the scaling group to the backend server group of the associated CLB instance. You can specify a server group to which ECS instances can be added. You can add ECS instances to the following types of server groups:
+     * *   Default server group: a group of ECS instances that are used to receive requests. If you do not specify a vServer group or a primary/secondary server group for a listener, requests are forwarded to the ECS instances in the default server group.
+     * *   vServer group: If you want to forward requests to backend servers that are not in the default server group or configure domain name-based or URL-based forwarding rules, you can use vServer groups.
+     * > If you specify the default server group and multiple vServer groups at the same time, ECS instances are added to all specified server groups.
+     * The default weight of an ECS instance that is added as a backend server of a CLB instance is 50. The CLB instance that you want to associate with your scaling group must meet the following requirements:
+     * *   The CLB instance must be in the Active state. You can call the DescribeLoadBalancers operation to query the state of the CLB instance.
+     * *   The health check feature must be enabled on all listener ports that are configured for the CLB instance. Otherwise, the scaling group fails to be created.
+     * If you associate an Application Load Balancer (ALB) server group with a scaling group, Auto Scaling automatically adds ECS instances that are in the scaling group to the ALB server group to process requests distributed by the ALB instance to which the ALB server group belongs. You can specify multiple ALB server groups. The server groups must reside in the same virtual private cloud (VPC) as the scaling group. For more information, see the "AttachAlbServerGroups" topic.
+     * If you associate an ApsaraDB RDS instance with a scaling group, Auto Scaling automatically adds the private IP addresses of the ECS instances in the scaling group to the IP address whitelist of the ApsaraDB RDS instance. The ApsaraDB RDS instance that you want to associate with your scaling group must meet the following requirements:
+     * *   The ApsaraDB RDS instance must be in the Running state. You can call the DescribeDBInstances operation to query the state of the ApsaraDB RDS instance.
+     * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance cannot exceed the upper limit. For more information, see the "Configure whitelists" topic.
+     * If you set the MultiAZPolicy parameter of the scaling group to COST_OPTIMIZED, take note of the following items:
+     * *   You can use the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters to specify the instance allocation method based on the cost optimization policy. This instance allocation method is prioritized during scaling.
+     * *   If you do not specify the OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools parameter, the instance types that are provided at the lowest price are used to create instances based on the cost optimization policy.
+     * If you set the `Tags.Propagate` parameter of the scaling group to true, the following rules apply:
+     * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
+     * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
+     * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
+     *
+     * @param request CreateScalingGroupRequest
+     * @return CreateScalingGroupResponse
      */
     createScalingGroup(request: CreateScalingGroupRequest): Promise<CreateScalingGroupResponse>;
     /**
-      * ## Description
-      * A scaling rule defines a specific scaling activity, such as adding or removing N instances. If the number of Elastic Compute Service (ECS) instances in a scaling group is less than the minimum number allowed or greater than the maximum number allowed after a scaling rule is executed, Auto Scaling adjusts the number of ECS instances that you want to add or remove. This way, the number of ECS instances can be maintained within the valid range after the scaling rule is executed. The number of ECS instances that is specified in the scaling rule remains unchanged. Example:
-      * *   If your scaling group contains two ECS instances and allows up to three ECS instances, only one ECS instance is added to your scaling group after you execute a scale-out rule in which three ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
-      * *   If your scaling group contains three ECS instances and requires at least two ECS instances, only one ECS instance is removed from your scaling group after you execute a scale-in rule in which five ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
-      * Before you call this operation, take note of the following items:
-      * *   If you set the AdjustmentType parameter to TotalCapacity, the number of ECS instances in the scaling group is adjusted to the specified value. The value of the AdjustmentValue parameter must be greater than or equal to 0.
-      * *   If you set the AdjustmentType parameter to QuantityChangeInCapacity or PercentChangeInCapacity, a positive value of AdjustmentValue specifies the number of ECS instances that are added to the scaling group, and a negative value of AdjustmentValue specifies the number of ECS instances that are removed from the scaling group.
-      * *   If you set the AdjustmentType parameter to PercentChangeInCapacity, Auto Scaling uses the following formula to calculate a value, and then rounds the value to the nearest integer to obtain the number of ECS instances that need to be scaled: Value of TotalCapacity × Value of AdjustmentValue/100.
-      * *   If the cooldown time is specified in a scaling rule, the specified time applies to the scaling group after the rule is executed. Otherwise, the value of the DefaultCooldown parameter of the scaling group applies to the scaling group.
-      * *   You can create only a limited number of scaling rules for a scaling group. For more information, see the "Limits" topic.
-      * *   The unique identifier (ScalingRuleAri) of a scaling rule can be used by the following operations:
-      *     *   ExecuteScalingRule: You can call this operation to manually execute a specific scaling rule by setting the ScalingRuleAri parameter to the unique identifier of the scaling rule.
-      *     *   CreateScheduledTask: You can call this operation to create a scheduled task for a specific scaling rule by setting the ScheduledAction parameter to the unique identifier of the scaling rule.
-      *
-      * @param request CreateScalingRuleRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateScalingRuleResponse
+     * @summary Creates a scaling rule.
+     *
+     * @description ## Description
+     * A scaling rule defines a specific scaling activity, such as adding or removing N instances. If the number of Elastic Compute Service (ECS) instances in a scaling group is less than the minimum number allowed or greater than the maximum number allowed after a scaling rule is executed, Auto Scaling adjusts the number of ECS instances that you want to add or remove. This way, the number of ECS instances can be maintained within the valid range after the scaling rule is executed. The number of ECS instances that is specified in the scaling rule remains unchanged. Example:
+     * *   If your scaling group contains two ECS instances and allows up to three ECS instances, only one ECS instance is added to your scaling group after you execute a scale-out rule in which three ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
+     * *   If your scaling group contains three ECS instances and requires at least two ECS instances, only one ECS instance is removed from your scaling group after you execute a scale-in rule in which five ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
+     * Before you call this operation, take note of the following items:
+     * *   If you set the AdjustmentType parameter to TotalCapacity, the number of ECS instances in the scaling group is adjusted to the specified value. The value of the AdjustmentValue parameter must be greater than or equal to 0.
+     * *   If you set the AdjustmentType parameter to QuantityChangeInCapacity or PercentChangeInCapacity, a positive value of AdjustmentValue specifies the number of ECS instances that are added to the scaling group, and a negative value of AdjustmentValue specifies the number of ECS instances that are removed from the scaling group.
+     * *   If you set the AdjustmentType parameter to PercentChangeInCapacity, Auto Scaling uses the following formula to calculate a value, and then rounds the value to the nearest integer to obtain the number of ECS instances that need to be scaled: Value of TotalCapacity × Value of AdjustmentValue/100.
+     * *   If the cooldown time is specified in a scaling rule, the specified time applies to the scaling group after the rule is executed. Otherwise, the value of the DefaultCooldown parameter of the scaling group applies to the scaling group.
+     * *   You can create only a limited number of scaling rules for a scaling group. For more information, see the "Limits" topic.
+     * *   The unique identifier (ScalingRuleAri) of a scaling rule can be used by the following operations:
+     *     *   ExecuteScalingRule: You can call this operation to manually execute a specific scaling rule by setting the ScalingRuleAri parameter to the unique identifier of the scaling rule.
+     *     *   CreateScheduledTask: You can call this operation to create a scheduled task for a specific scaling rule by setting the ScheduledAction parameter to the unique identifier of the scaling rule.
+     *
+     * @param request CreateScalingRuleRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateScalingRuleResponse
      */
     createScalingRuleWithOptions(request: CreateScalingRuleRequest, runtime: $Util.RuntimeOptions): Promise<CreateScalingRuleResponse>;
     /**
-      * ## Description
-      * A scaling rule defines a specific scaling activity, such as adding or removing N instances. If the number of Elastic Compute Service (ECS) instances in a scaling group is less than the minimum number allowed or greater than the maximum number allowed after a scaling rule is executed, Auto Scaling adjusts the number of ECS instances that you want to add or remove. This way, the number of ECS instances can be maintained within the valid range after the scaling rule is executed. The number of ECS instances that is specified in the scaling rule remains unchanged. Example:
-      * *   If your scaling group contains two ECS instances and allows up to three ECS instances, only one ECS instance is added to your scaling group after you execute a scale-out rule in which three ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
-      * *   If your scaling group contains three ECS instances and requires at least two ECS instances, only one ECS instance is removed from your scaling group after you execute a scale-in rule in which five ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
-      * Before you call this operation, take note of the following items:
-      * *   If you set the AdjustmentType parameter to TotalCapacity, the number of ECS instances in the scaling group is adjusted to the specified value. The value of the AdjustmentValue parameter must be greater than or equal to 0.
-      * *   If you set the AdjustmentType parameter to QuantityChangeInCapacity or PercentChangeInCapacity, a positive value of AdjustmentValue specifies the number of ECS instances that are added to the scaling group, and a negative value of AdjustmentValue specifies the number of ECS instances that are removed from the scaling group.
-      * *   If you set the AdjustmentType parameter to PercentChangeInCapacity, Auto Scaling uses the following formula to calculate a value, and then rounds the value to the nearest integer to obtain the number of ECS instances that need to be scaled: Value of TotalCapacity × Value of AdjustmentValue/100.
-      * *   If the cooldown time is specified in a scaling rule, the specified time applies to the scaling group after the rule is executed. Otherwise, the value of the DefaultCooldown parameter of the scaling group applies to the scaling group.
-      * *   You can create only a limited number of scaling rules for a scaling group. For more information, see the "Limits" topic.
-      * *   The unique identifier (ScalingRuleAri) of a scaling rule can be used by the following operations:
-      *     *   ExecuteScalingRule: You can call this operation to manually execute a specific scaling rule by setting the ScalingRuleAri parameter to the unique identifier of the scaling rule.
-      *     *   CreateScheduledTask: You can call this operation to create a scheduled task for a specific scaling rule by setting the ScheduledAction parameter to the unique identifier of the scaling rule.
-      *
-      * @param request CreateScalingRuleRequest
-      * @return CreateScalingRuleResponse
+     * @summary Creates a scaling rule.
+     *
+     * @description ## Description
+     * A scaling rule defines a specific scaling activity, such as adding or removing N instances. If the number of Elastic Compute Service (ECS) instances in a scaling group is less than the minimum number allowed or greater than the maximum number allowed after a scaling rule is executed, Auto Scaling adjusts the number of ECS instances that you want to add or remove. This way, the number of ECS instances can be maintained within the valid range after the scaling rule is executed. The number of ECS instances that is specified in the scaling rule remains unchanged. Example:
+     * *   If your scaling group contains two ECS instances and allows up to three ECS instances, only one ECS instance is added to your scaling group after you execute a scale-out rule in which three ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
+     * *   If your scaling group contains three ECS instances and requires at least two ECS instances, only one ECS instance is removed from your scaling group after you execute a scale-in rule in which five ECS instances are specified. The number of ECS instances that is specified in the scaling rule remains unchanged.
+     * Before you call this operation, take note of the following items:
+     * *   If you set the AdjustmentType parameter to TotalCapacity, the number of ECS instances in the scaling group is adjusted to the specified value. The value of the AdjustmentValue parameter must be greater than or equal to 0.
+     * *   If you set the AdjustmentType parameter to QuantityChangeInCapacity or PercentChangeInCapacity, a positive value of AdjustmentValue specifies the number of ECS instances that are added to the scaling group, and a negative value of AdjustmentValue specifies the number of ECS instances that are removed from the scaling group.
+     * *   If you set the AdjustmentType parameter to PercentChangeInCapacity, Auto Scaling uses the following formula to calculate a value, and then rounds the value to the nearest integer to obtain the number of ECS instances that need to be scaled: Value of TotalCapacity × Value of AdjustmentValue/100.
+     * *   If the cooldown time is specified in a scaling rule, the specified time applies to the scaling group after the rule is executed. Otherwise, the value of the DefaultCooldown parameter of the scaling group applies to the scaling group.
+     * *   You can create only a limited number of scaling rules for a scaling group. For more information, see the "Limits" topic.
+     * *   The unique identifier (ScalingRuleAri) of a scaling rule can be used by the following operations:
+     *     *   ExecuteScalingRule: You can call this operation to manually execute a specific scaling rule by setting the ScalingRuleAri parameter to the unique identifier of the scaling rule.
+     *     *   CreateScheduledTask: You can call this operation to create a scheduled task for a specific scaling rule by setting the ScheduledAction parameter to the unique identifier of the scaling rule.
+     *
+     * @param request CreateScalingRuleRequest
+     * @return CreateScalingRuleResponse
      */
     createScalingRule(request: CreateScalingRuleRequest): Promise<CreateScalingRuleResponse>;
     /**
-      * *   If a scheduled task fails to trigger a scaling activity due to an ongoing scaling activity in a scaling group or because the scaling group is disabled, the scheduled task is automatically retried during the period that is specified by the LaunchExpirationTime parameter. If the scheduled task still fails to trigger a scaling activity after the period ends, the task is automatically skipped.
-      * *   If multiple tasks are scheduled at similar points in time to trigger scaling activities in the same scaling group, the earliest task triggers the scaling activity first. Other tasks trigger scaling activities within their launch expiration time. Only one scaling activity can be triggered in a scaling group at a time.`` If the previous scaling activity is complete and another scheduled task attempts to trigger a scaling activity, Auto Scaling executes the scaling rule that is specified in the scheduled task and then triggers a scaling activity.``
-      * *   A scheduled task supports the following scaling methods:
-      *     *   `ScheduledAction`: Specify an existing scaling rule that you want Auto Scaling to execute when the scheduled task is triggered.
-      *     *   `ScalingGroupId`: Specify the minimum number, maximum number, or expected number of instances for the scaling group for which you created the scheduled task.
-      * > You cannot specify the `ScheduledAction` and ScalingGroupId parameters at the same time.
-      *
-      * @param request CreateScheduledTaskRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return CreateScheduledTaskResponse
+     * @summary Creates a scheduled task. A scheduled task is a type of scaling task that enables automatic execution of a specific scaling rule at a specified point in time. You can call the CreateScheduledTask operation to create a scheduled task to implement automatic scaling of computing resources. This ensures your business continuity and minimizes resource costs.
+     *
+     * @description *   If a scheduled task fails to trigger a scaling activity due to an ongoing scaling activity in a scaling group or because the scaling group is disabled, the scheduled task is automatically retried during the period that is specified by the LaunchExpirationTime parameter. If the scheduled task still fails to trigger a scaling activity after the period ends, the task is automatically skipped.
+     * *   If multiple tasks are scheduled at similar points in time to trigger scaling activities in the same scaling group, the earliest task triggers the scaling activity first. Other tasks trigger scaling activities within their launch expiration time. Only one scaling activity can be triggered in a scaling group at a time.`` If the previous scaling activity is complete and another scheduled task attempts to trigger a scaling activity, Auto Scaling executes the scaling rule that is specified in the scheduled task and then triggers a scaling activity.``
+     * *   A scheduled task supports the following scaling methods:
+     *     *   `ScheduledAction`: Specify an existing scaling rule that you want Auto Scaling to execute when the scheduled task is triggered.
+     *     *   `ScalingGroupId`: Specify the minimum number, maximum number, or expected number of instances for the scaling group for which you created the scheduled task.
+     * > You cannot specify the `ScheduledAction` and ScalingGroupId parameters at the same time.
+     *
+     * @param request CreateScheduledTaskRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return CreateScheduledTaskResponse
      */
     createScheduledTaskWithOptions(request: CreateScheduledTaskRequest, runtime: $Util.RuntimeOptions): Promise<CreateScheduledTaskResponse>;
     /**
-      * *   If a scheduled task fails to trigger a scaling activity due to an ongoing scaling activity in a scaling group or because the scaling group is disabled, the scheduled task is automatically retried during the period that is specified by the LaunchExpirationTime parameter. If the scheduled task still fails to trigger a scaling activity after the period ends, the task is automatically skipped.
-      * *   If multiple tasks are scheduled at similar points in time to trigger scaling activities in the same scaling group, the earliest task triggers the scaling activity first. Other tasks trigger scaling activities within their launch expiration time. Only one scaling activity can be triggered in a scaling group at a time.`` If the previous scaling activity is complete and another scheduled task attempts to trigger a scaling activity, Auto Scaling executes the scaling rule that is specified in the scheduled task and then triggers a scaling activity.``
-      * *   A scheduled task supports the following scaling methods:
-      *     *   `ScheduledAction`: Specify an existing scaling rule that you want Auto Scaling to execute when the scheduled task is triggered.
-      *     *   `ScalingGroupId`: Specify the minimum number, maximum number, or expected number of instances for the scaling group for which you created the scheduled task.
-      * > You cannot specify the `ScheduledAction` and ScalingGroupId parameters at the same time.
-      *
-      * @param request CreateScheduledTaskRequest
-      * @return CreateScheduledTaskResponse
+     * @summary Creates a scheduled task. A scheduled task is a type of scaling task that enables automatic execution of a specific scaling rule at a specified point in time. You can call the CreateScheduledTask operation to create a scheduled task to implement automatic scaling of computing resources. This ensures your business continuity and minimizes resource costs.
+     *
+     * @description *   If a scheduled task fails to trigger a scaling activity due to an ongoing scaling activity in a scaling group or because the scaling group is disabled, the scheduled task is automatically retried during the period that is specified by the LaunchExpirationTime parameter. If the scheduled task still fails to trigger a scaling activity after the period ends, the task is automatically skipped.
+     * *   If multiple tasks are scheduled at similar points in time to trigger scaling activities in the same scaling group, the earliest task triggers the scaling activity first. Other tasks trigger scaling activities within their launch expiration time. Only one scaling activity can be triggered in a scaling group at a time.`` If the previous scaling activity is complete and another scheduled task attempts to trigger a scaling activity, Auto Scaling executes the scaling rule that is specified in the scheduled task and then triggers a scaling activity.``
+     * *   A scheduled task supports the following scaling methods:
+     *     *   `ScheduledAction`: Specify an existing scaling rule that you want Auto Scaling to execute when the scheduled task is triggered.
+     *     *   `ScalingGroupId`: Specify the minimum number, maximum number, or expected number of instances for the scaling group for which you created the scheduled task.
+     * > You cannot specify the `ScheduledAction` and ScalingGroupId parameters at the same time.
+     *
+     * @param request CreateScheduledTaskRequest
+     * @return CreateScheduledTaskResponse
      */
     createScheduledTask(request: CreateScheduledTaskRequest): Promise<CreateScheduledTaskResponse>;
+    /**
+     * @summary Deactivates a scaling configuration.
+     *
+     * @description *   You can call this operation to deactivate a scaling configuration only in a disabled scaling group.
+     *
+     * @param request DeactivateScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeactivateScalingConfigurationResponse
+     */
     deactivateScalingConfigurationWithOptions(request: DeactivateScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<DeactivateScalingConfigurationResponse>;
+    /**
+     * @summary Deactivates a scaling configuration.
+     *
+     * @description *   You can call this operation to deactivate a scaling configuration only in a disabled scaling group.
+     *
+     * @param request DeactivateScalingConfigurationRequest
+     * @return DeactivateScalingConfigurationResponse
+     */
     deactivateScalingConfiguration(request: DeactivateScalingConfigurationRequest): Promise<DeactivateScalingConfigurationResponse>;
+    /**
+     * @summary Deletes an event-triggered task. If your business pattern is unpredictable or prone to unforeseen traffic spikes, you can create event-triggered tasks by associating CloudMonitor metrics to effectively monitor fluctuations in your business workload. Upon detecting that the criteria for alerts, as specified in event-triggered tasks, are fulfilled, Auto Scaling promptly issues alerts and executes the scaling rules predefined within those tasks. This process occurs within the predefined effective time windows of the tasks, thereby facilitating the automatic increase or decrease of Elastic Compute Service (ECS) instances or elastic container instances within your scaling groups. Ultimately, this mechanism ensures the dynamic optimization of resources based on real-time workload demands. If you no longer need an event-triggered task, you can call the DeleteAlarm operation to delete it.
+     *
+     * @param request DeleteAlarmRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteAlarmResponse
+     */
     deleteAlarmWithOptions(request: DeleteAlarmRequest, runtime: $Util.RuntimeOptions): Promise<DeleteAlarmResponse>;
+    /**
+     * @summary Deletes an event-triggered task. If your business pattern is unpredictable or prone to unforeseen traffic spikes, you can create event-triggered tasks by associating CloudMonitor metrics to effectively monitor fluctuations in your business workload. Upon detecting that the criteria for alerts, as specified in event-triggered tasks, are fulfilled, Auto Scaling promptly issues alerts and executes the scaling rules predefined within those tasks. This process occurs within the predefined effective time windows of the tasks, thereby facilitating the automatic increase or decrease of Elastic Compute Service (ECS) instances or elastic container instances within your scaling groups. Ultimately, this mechanism ensures the dynamic optimization of resources based on real-time workload demands. If you no longer need an event-triggered task, you can call the DeleteAlarm operation to delete it.
+     *
+     * @param request DeleteAlarmRequest
+     * @return DeleteAlarmResponse
+     */
     deleteAlarm(request: DeleteAlarmRequest): Promise<DeleteAlarmResponse>;
     /**
-      * You cannot delete a scaling configuration that is used to create elastic container instances in the following scenarios:
-      * *   The scaling configuration is in the Active state.
-      * *   The scaling group contains elastic container instances that are created based on the scaling configuration.
-      *
-      * @param request DeleteEciScalingConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DeleteEciScalingConfigurationResponse
+     * @summary Deletes a scaling configuration of the Elastic Container Instance type. If the scaling configuration of a scaling group is in the Inactive state and the scaling group contains no elastic container instances created from the scaling configuration, you can call the DeleteEciScalingConfiguration operation to delete the scaling configuration to free up the scaling configuration quota.
+     *
+     * @description You cannot call this operation to delete a scaling configuration in the following scenarios:
+     * *   The scaling configuration is in the Active state.
+     * *   The scaling group contains elastic container instances created from the scaling configuration.
+     *
+     * @param request DeleteEciScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteEciScalingConfigurationResponse
      */
     deleteEciScalingConfigurationWithOptions(request: DeleteEciScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<DeleteEciScalingConfigurationResponse>;
     /**
-      * You cannot delete a scaling configuration that is used to create elastic container instances in the following scenarios:
-      * *   The scaling configuration is in the Active state.
-      * *   The scaling group contains elastic container instances that are created based on the scaling configuration.
-      *
-      * @param request DeleteEciScalingConfigurationRequest
-      * @return DeleteEciScalingConfigurationResponse
+     * @summary Deletes a scaling configuration of the Elastic Container Instance type. If the scaling configuration of a scaling group is in the Inactive state and the scaling group contains no elastic container instances created from the scaling configuration, you can call the DeleteEciScalingConfiguration operation to delete the scaling configuration to free up the scaling configuration quota.
+     *
+     * @description You cannot call this operation to delete a scaling configuration in the following scenarios:
+     * *   The scaling configuration is in the Active state.
+     * *   The scaling group contains elastic container instances created from the scaling configuration.
+     *
+     * @param request DeleteEciScalingConfigurationRequest
+     * @return DeleteEciScalingConfigurationResponse
      */
     deleteEciScalingConfiguration(request: DeleteEciScalingConfigurationRequest): Promise<DeleteEciScalingConfigurationResponse>;
+    /**
+     * @summary Deletes a lifecycle hook.
+     *
+     * @description If you delete a lifecycle hook that is in effect in a scaling group, instances exit the Pending state in advance. You can use one of the following methods to specify the lifecycle hooks that you want to delete:
+     * *   Specify the scaling group ID of the lifecycle hook that you want to delete by using the ScalingGroupId parameter and the lifecycle hook name by using the LifecycleHookName parameter.
+     * *   Specify the lifecycle hook ID by using the LifecycleHookId parameter. In this case, the ScalingGroupId parameter and the LifecycleHookName parameter are ignored.
+     *
+     * @param request DeleteLifecycleHookRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteLifecycleHookResponse
+     */
     deleteLifecycleHookWithOptions(request: DeleteLifecycleHookRequest, runtime: $Util.RuntimeOptions): Promise<DeleteLifecycleHookResponse>;
+    /**
+     * @summary Deletes a lifecycle hook.
+     *
+     * @description If you delete a lifecycle hook that is in effect in a scaling group, instances exit the Pending state in advance. You can use one of the following methods to specify the lifecycle hooks that you want to delete:
+     * *   Specify the scaling group ID of the lifecycle hook that you want to delete by using the ScalingGroupId parameter and the lifecycle hook name by using the LifecycleHookName parameter.
+     * *   Specify the lifecycle hook ID by using the LifecycleHookId parameter. In this case, the ScalingGroupId parameter and the LifecycleHookName parameter are ignored.
+     *
+     * @param request DeleteLifecycleHookRequest
+     * @return DeleteLifecycleHookResponse
+     */
     deleteLifecycleHook(request: DeleteLifecycleHookRequest): Promise<DeleteLifecycleHookResponse>;
+    /**
+     * @summary Deletes event notification rules. The event notification feature facilitates efficient issue identification and event management by automatically forwarding notifications from Auto Scaling to designated endpoints such as CloudMonitor or Message Service (MNS) topics and queues. If you no longer require an event notification rule, you can call the DeleteNotificationConfiguration operation to delete it.
+     *
+     * @param request DeleteNotificationConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteNotificationConfigurationResponse
+     */
     deleteNotificationConfigurationWithOptions(request: DeleteNotificationConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<DeleteNotificationConfigurationResponse>;
+    /**
+     * @summary Deletes event notification rules. The event notification feature facilitates efficient issue identification and event management by automatically forwarding notifications from Auto Scaling to designated endpoints such as CloudMonitor or Message Service (MNS) topics and queues. If you no longer require an event notification rule, you can call the DeleteNotificationConfiguration operation to delete it.
+     *
+     * @param request DeleteNotificationConfigurationRequest
+     * @return DeleteNotificationConfigurationResponse
+     */
     deleteNotificationConfiguration(request: DeleteNotificationConfigurationRequest): Promise<DeleteNotificationConfigurationResponse>;
     /**
-      * You cannot delete a scaling configuration in one of the following scenarios:
-      * *   The scaling configuration in your scaling group is in the Active state.
-      * *   The scaling group contains ECS instances that were created based on the scaling configuration.
-      *
-      * @param request DeleteScalingConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DeleteScalingConfigurationResponse
+     * @summary Deletes a scaling configuration that is used to create Elastic Compute Service (ECS) instances.
+     *
+     * @description You cannot delete a scaling configuration in one of the following scenarios:
+     * *   The scaling configuration in your scaling group is in the Active state.
+     * *   The scaling group contains ECS instances that were created based on the scaling configuration.
+     *
+     * @param request DeleteScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteScalingConfigurationResponse
      */
     deleteScalingConfigurationWithOptions(request: DeleteScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<DeleteScalingConfigurationResponse>;
     /**
-      * You cannot delete a scaling configuration in one of the following scenarios:
-      * *   The scaling configuration in your scaling group is in the Active state.
-      * *   The scaling group contains ECS instances that were created based on the scaling configuration.
-      *
-      * @param request DeleteScalingConfigurationRequest
-      * @return DeleteScalingConfigurationResponse
+     * @summary Deletes a scaling configuration that is used to create Elastic Compute Service (ECS) instances.
+     *
+     * @description You cannot delete a scaling configuration in one of the following scenarios:
+     * *   The scaling configuration in your scaling group is in the Active state.
+     * *   The scaling group contains ECS instances that were created based on the scaling configuration.
+     *
+     * @param request DeleteScalingConfigurationRequest
+     * @return DeleteScalingConfigurationResponse
      */
     deleteScalingConfiguration(request: DeleteScalingConfigurationRequest): Promise<DeleteScalingConfigurationResponse>;
+    /**
+     * @summary Deletes a scaling group. If you want to enable policy-based automatic addition or removal of instances of a specific type to meet evolving business requirements, you can create scaling groups to manage your computing power with ease. The computing power refers to the instances that provide the computing capability. If you no longer require a scaling group, you can call the DeleteScalingGroup operation to delete it to free up the scaling group quota.
+     *
+     * @description Before you call the DeleteScalingGroup operation, take note of the following items:
+     * *   If you delete a scaling group, the scaling configurations, scaling rules, scaling activities, and scaling requests related to the scaling group are also deleted.
+     * *   If you delete a scaling group, the scheduled tasks and event-triggered tasks of the scaling group are not deleted. The Server Load Balancer (SLB) instances and ApsaraDB RDS instances that are attached to the scaling group are also not deleted.
+     * *   If the scaling group that you want to delete contains ECS instances or elastic container instances that are in the In Service state, Auto Scaling stops the instances and then removes all manually added instances from the scaling group or releases all automatically created instances in the scaling group before the scaling group is deleted.
+     *     **
+     *     **Note** Before you delete a scaling group, make sure that the Deletion Protection feature is disabled. If you have enabled the Deletion Protection feature for a scaling group, disable the feature on the Modify Scaling Group page before you delete the scaling group.
+     * *   If you do not disable the Deletion Protection feature for a scaling group, you cannot delete the scaling group by using the Auto Scaling console or calling this operation. The Deletion Protection feature is an effective measure to safeguard scaling groups against unintended deletion.
+     * *   Prior to deleting a scaling group, make sure that your ECS instances within the scaling group are safeguarded against unintended release. Even if you have already enabled the Release Protection feature for the ECS instances, you must manually put these ECS instances into the Protected state. Doing so guarantees that the ECS instances will not be forcibly released during the deletion process of the scaling group, providing an extra layer of security.
+     *     **
+     *     **Note** Before you delete a scaling group, we recommend that you enable the Deletion Protection feature for ECS instances that you want to retain. This action guarantees that the ECS instances are not forcibly released after you delete the scaling group. For more information, see [SetInstancesProtection](https://help.aliyun.com/document_detail/459342.html).
+     *
+     * @param request DeleteScalingGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteScalingGroupResponse
+     */
     deleteScalingGroupWithOptions(request: DeleteScalingGroupRequest, runtime: $Util.RuntimeOptions): Promise<DeleteScalingGroupResponse>;
+    /**
+     * @summary Deletes a scaling group. If you want to enable policy-based automatic addition or removal of instances of a specific type to meet evolving business requirements, you can create scaling groups to manage your computing power with ease. The computing power refers to the instances that provide the computing capability. If you no longer require a scaling group, you can call the DeleteScalingGroup operation to delete it to free up the scaling group quota.
+     *
+     * @description Before you call the DeleteScalingGroup operation, take note of the following items:
+     * *   If you delete a scaling group, the scaling configurations, scaling rules, scaling activities, and scaling requests related to the scaling group are also deleted.
+     * *   If you delete a scaling group, the scheduled tasks and event-triggered tasks of the scaling group are not deleted. The Server Load Balancer (SLB) instances and ApsaraDB RDS instances that are attached to the scaling group are also not deleted.
+     * *   If the scaling group that you want to delete contains ECS instances or elastic container instances that are in the In Service state, Auto Scaling stops the instances and then removes all manually added instances from the scaling group or releases all automatically created instances in the scaling group before the scaling group is deleted.
+     *     **
+     *     **Note** Before you delete a scaling group, make sure that the Deletion Protection feature is disabled. If you have enabled the Deletion Protection feature for a scaling group, disable the feature on the Modify Scaling Group page before you delete the scaling group.
+     * *   If you do not disable the Deletion Protection feature for a scaling group, you cannot delete the scaling group by using the Auto Scaling console or calling this operation. The Deletion Protection feature is an effective measure to safeguard scaling groups against unintended deletion.
+     * *   Prior to deleting a scaling group, make sure that your ECS instances within the scaling group are safeguarded against unintended release. Even if you have already enabled the Release Protection feature for the ECS instances, you must manually put these ECS instances into the Protected state. Doing so guarantees that the ECS instances will not be forcibly released during the deletion process of the scaling group, providing an extra layer of security.
+     *     **
+     *     **Note** Before you delete a scaling group, we recommend that you enable the Deletion Protection feature for ECS instances that you want to retain. This action guarantees that the ECS instances are not forcibly released after you delete the scaling group. For more information, see [SetInstancesProtection](https://help.aliyun.com/document_detail/459342.html).
+     *
+     * @param request DeleteScalingGroupRequest
+     * @return DeleteScalingGroupResponse
+     */
     deleteScalingGroup(request: DeleteScalingGroupRequest): Promise<DeleteScalingGroupResponse>;
+    /**
+     * @summary Deletes a scaling rule.
+     *
+     * @param request DeleteScalingRuleRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteScalingRuleResponse
+     */
     deleteScalingRuleWithOptions(request: DeleteScalingRuleRequest, runtime: $Util.RuntimeOptions): Promise<DeleteScalingRuleResponse>;
+    /**
+     * @summary Deletes a scaling rule.
+     *
+     * @param request DeleteScalingRuleRequest
+     * @return DeleteScalingRuleResponse
+     */
     deleteScalingRule(request: DeleteScalingRuleRequest): Promise<DeleteScalingRuleResponse>;
+    /**
+     * @summary Deletes scheduled tasks. For workloads with predictable patterns, you can create scheduled tasks to align with your business requirements and optimize resource utilization for cost savings. These tasks automatically ensure that sufficient computing resources are provisioned in anticipation of peak hours and efficiently release unused resources during off-peak hours, thereby streamlining operational efficiency and reducing expenses. If you no longer require a scheduled task, you can call the DeleteScheduledTask operation to delete it.
+     *
+     * @param request DeleteScheduledTaskRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DeleteScheduledTaskResponse
+     */
     deleteScheduledTaskWithOptions(request: DeleteScheduledTaskRequest, runtime: $Util.RuntimeOptions): Promise<DeleteScheduledTaskResponse>;
+    /**
+     * @summary Deletes scheduled tasks. For workloads with predictable patterns, you can create scheduled tasks to align with your business requirements and optimize resource utilization for cost savings. These tasks automatically ensure that sufficient computing resources are provisioned in anticipation of peak hours and efficiently release unused resources during off-peak hours, thereby streamlining operational efficiency and reducing expenses. If you no longer require a scheduled task, you can call the DeleteScheduledTask operation to delete it.
+     *
+     * @param request DeleteScheduledTaskRequest
+     * @return DeleteScheduledTaskResponse
+     */
     deleteScheduledTask(request: DeleteScheduledTaskRequest): Promise<DeleteScheduledTaskResponse>;
+    /**
+     * @summary Queries event-triggered tasks.
+     *
+     * @param request DescribeAlarmsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeAlarmsResponse
+     */
     describeAlarmsWithOptions(request: DescribeAlarmsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeAlarmsResponse>;
+    /**
+     * @summary Queries event-triggered tasks.
+     *
+     * @param request DescribeAlarmsRequest
+     * @return DescribeAlarmsResponse
+     */
     describeAlarms(request: DescribeAlarmsRequest): Promise<DescribeAlarmsResponse>;
+    /**
+     * @summary Queries scaling configurations of the Elastic Container Instance type to learn the scaling configuration details. This allows you to select an appropriate template when you create elastic container instances. If you set OutputFormat to yaml, the output is a Kubernetes Deployment file in the YAML format.
+     *
+     * @param request DescribeEciScalingConfigurationDetailRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeEciScalingConfigurationDetailResponse
+     */
     describeEciScalingConfigurationDetailWithOptions(request: DescribeEciScalingConfigurationDetailRequest, runtime: $Util.RuntimeOptions): Promise<DescribeEciScalingConfigurationDetailResponse>;
+    /**
+     * @summary Queries scaling configurations of the Elastic Container Instance type to learn the scaling configuration details. This allows you to select an appropriate template when you create elastic container instances. If you set OutputFormat to yaml, the output is a Kubernetes Deployment file in the YAML format.
+     *
+     * @param request DescribeEciScalingConfigurationDetailRequest
+     * @return DescribeEciScalingConfigurationDetailResponse
+     */
     describeEciScalingConfigurationDetail(request: DescribeEciScalingConfigurationDetailRequest): Promise<DescribeEciScalingConfigurationDetailResponse>;
+    /**
+     * @summary Queries scaling configurations of the Elastic Container Instance type to learn the scaling configuration details. This allows you to select an appropriate template when you create elastic container instances.
+     *
+     * @param request DescribeEciScalingConfigurationsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeEciScalingConfigurationsResponse
+     */
     describeEciScalingConfigurationsWithOptions(request: DescribeEciScalingConfigurationsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeEciScalingConfigurationsResponse>;
+    /**
+     * @summary Queries scaling configurations of the Elastic Container Instance type to learn the scaling configuration details. This allows you to select an appropriate template when you create elastic container instances.
+     *
+     * @param request DescribeEciScalingConfigurationsRequest
+     * @return DescribeEciScalingConfigurationsResponse
+     */
     describeEciScalingConfigurations(request: DescribeEciScalingConfigurationsRequest): Promise<DescribeEciScalingConfigurationsResponse>;
     /**
-      * If a scaling activity is executed and a lifecycle hook is created for the scaling activity, the lifecycle hook triggers a lifecycle action. A lifecycle action can be in one of the following states:
-      * *   If a lifecycle action is in the Pending state, Elastic Compute Service (ECS) instances are waiting to be added to a scaling group or waiting to be removed from a scaling group.
-      * *   If a lifecycle action is in the Timeout state, the lifecycle hook that triggers the lifecycle action expires and ECS instances are added to or removed from a scaling group.
-      * *   If a lifecycle action is in the Completed state, you manually end the lifecycle hook that triggers the lifecycle action ahead of schedule.
-      * If you do not specify the action to perform, such as execute a specific OOS template, after a lifecycle hook ends, you can call this operation to obtain the token of the lifecycle action that corresponds to the lifecycle hook. Then, you can specify a custom action to perform after the lifecycle hook ends.
-      *
-      * @param request DescribeLifecycleActionsRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DescribeLifecycleActionsResponse
+     * @summary Queries lifecycle actions.
+     *
+     * @description If a scaling activity is executed and a lifecycle hook is created for the scaling activity, the lifecycle hook triggers a lifecycle action. A lifecycle action can be in one of the following states:
+     * *   If a lifecycle action is in the Pending state, Elastic Compute Service (ECS) instances are waiting to be added to a scaling group or waiting to be removed from a scaling group.
+     * *   If a lifecycle action is in the Timeout state, the lifecycle hook that triggers the lifecycle action expires and ECS instances are added to or removed from a scaling group.
+     * *   If a lifecycle action is in the Completed state, you manually end the lifecycle hook that triggers the lifecycle action ahead of schedule.
+     * If you do not specify the action to perform, such as execute a specific OOS template, after a lifecycle hook ends, you can call this operation to obtain the token of the lifecycle action that corresponds to the lifecycle hook. Then, you can specify a custom action to perform after the lifecycle hook ends.
+     *
+     * @param request DescribeLifecycleActionsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeLifecycleActionsResponse
      */
     describeLifecycleActionsWithOptions(request: DescribeLifecycleActionsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeLifecycleActionsResponse>;
     /**
-      * If a scaling activity is executed and a lifecycle hook is created for the scaling activity, the lifecycle hook triggers a lifecycle action. A lifecycle action can be in one of the following states:
-      * *   If a lifecycle action is in the Pending state, Elastic Compute Service (ECS) instances are waiting to be added to a scaling group or waiting to be removed from a scaling group.
-      * *   If a lifecycle action is in the Timeout state, the lifecycle hook that triggers the lifecycle action expires and ECS instances are added to or removed from a scaling group.
-      * *   If a lifecycle action is in the Completed state, you manually end the lifecycle hook that triggers the lifecycle action ahead of schedule.
-      * If you do not specify the action to perform, such as execute a specific OOS template, after a lifecycle hook ends, you can call this operation to obtain the token of the lifecycle action that corresponds to the lifecycle hook. Then, you can specify a custom action to perform after the lifecycle hook ends.
-      *
-      * @param request DescribeLifecycleActionsRequest
-      * @return DescribeLifecycleActionsResponse
+     * @summary Queries lifecycle actions.
+     *
+     * @description If a scaling activity is executed and a lifecycle hook is created for the scaling activity, the lifecycle hook triggers a lifecycle action. A lifecycle action can be in one of the following states:
+     * *   If a lifecycle action is in the Pending state, Elastic Compute Service (ECS) instances are waiting to be added to a scaling group or waiting to be removed from a scaling group.
+     * *   If a lifecycle action is in the Timeout state, the lifecycle hook that triggers the lifecycle action expires and ECS instances are added to or removed from a scaling group.
+     * *   If a lifecycle action is in the Completed state, you manually end the lifecycle hook that triggers the lifecycle action ahead of schedule.
+     * If you do not specify the action to perform, such as execute a specific OOS template, after a lifecycle hook ends, you can call this operation to obtain the token of the lifecycle action that corresponds to the lifecycle hook. Then, you can specify a custom action to perform after the lifecycle hook ends.
+     *
+     * @param request DescribeLifecycleActionsRequest
+     * @return DescribeLifecycleActionsResponse
      */
     describeLifecycleActions(request: DescribeLifecycleActionsRequest): Promise<DescribeLifecycleActionsResponse>;
+    /**
+     * @summary Queries lifecycle hooks.
+     *
+     * @description You can use one of the following methods to query lifecycle hooks:
+     * *   Specify a list of lifecycle hook IDs by using the LifecycleHookIds parameter. In this case, you do not need to specify the ScalingGroupId and LifecycleHookName parameters.
+     * *   Specify the scaling group ID by using the ScalingGroupId parameter.
+     * *   Specify the scaling group ID by using the ScalingGroupId parameter and the lifecycle hook name by using the LifecycleHookName parameter at the same time.
+     *
+     * @param request DescribeLifecycleHooksRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeLifecycleHooksResponse
+     */
     describeLifecycleHooksWithOptions(request: DescribeLifecycleHooksRequest, runtime: $Util.RuntimeOptions): Promise<DescribeLifecycleHooksResponse>;
+    /**
+     * @summary Queries lifecycle hooks.
+     *
+     * @description You can use one of the following methods to query lifecycle hooks:
+     * *   Specify a list of lifecycle hook IDs by using the LifecycleHookIds parameter. In this case, you do not need to specify the ScalingGroupId and LifecycleHookName parameters.
+     * *   Specify the scaling group ID by using the ScalingGroupId parameter.
+     * *   Specify the scaling group ID by using the ScalingGroupId parameter and the lifecycle hook name by using the LifecycleHookName parameter at the same time.
+     *
+     * @param request DescribeLifecycleHooksRequest
+     * @return DescribeLifecycleHooksResponse
+     */
     describeLifecycleHooks(request: DescribeLifecycleHooksRequest): Promise<DescribeLifecycleHooksResponse>;
+    /**
+     * @summary Queries resource quotas. You can call the DescribeLimitation operation to query the upper limits on resources such as scheduled tasks that can be created in a scaling group, load balancers that can be attached to a scaling group, instances that can be contained in a scaling group, and scaling configurations that can be created in a scaling group.
+     *
+     * @param request DescribeLimitationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeLimitationResponse
+     */
     describeLimitationWithOptions(request: DescribeLimitationRequest, runtime: $Util.RuntimeOptions): Promise<DescribeLimitationResponse>;
+    /**
+     * @summary Queries resource quotas. You can call the DescribeLimitation operation to query the upper limits on resources such as scheduled tasks that can be created in a scaling group, load balancers that can be attached to a scaling group, instances that can be contained in a scaling group, and scaling configurations that can be created in a scaling group.
+     *
+     * @param request DescribeLimitationRequest
+     * @return DescribeLimitationResponse
+     */
     describeLimitation(request: DescribeLimitationRequest): Promise<DescribeLimitationResponse>;
+    /**
+     * @summary Queries event notifications.
+     *
+     * @param request DescribeNotificationConfigurationsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeNotificationConfigurationsResponse
+     */
     describeNotificationConfigurationsWithOptions(request: DescribeNotificationConfigurationsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeNotificationConfigurationsResponse>;
+    /**
+     * @summary Queries event notifications.
+     *
+     * @param request DescribeNotificationConfigurationsRequest
+     * @return DescribeNotificationConfigurationsResponse
+     */
     describeNotificationConfigurations(request: DescribeNotificationConfigurationsRequest): Promise<DescribeNotificationConfigurationsResponse>;
+    /**
+     * @summary Queries notification types.
+     *
+     * @param request DescribeNotificationTypesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeNotificationTypesResponse
+     */
     describeNotificationTypesWithOptions(request: DescribeNotificationTypesRequest, runtime: $Util.RuntimeOptions): Promise<DescribeNotificationTypesResponse>;
+    /**
+     * @summary Queries notification types.
+     *
+     * @param request DescribeNotificationTypesRequest
+     * @return DescribeNotificationTypesResponse
+     */
     describeNotificationTypes(request: DescribeNotificationTypesRequest): Promise<DescribeNotificationTypesResponse>;
+    /**
+     * @summary DescribePatternTypes
+     *
+     * @param request DescribePatternTypesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribePatternTypesResponse
+     */
+    describePatternTypesWithOptions(request: DescribePatternTypesRequest, runtime: $Util.RuntimeOptions): Promise<DescribePatternTypesResponse>;
+    /**
+     * @summary DescribePatternTypes
+     *
+     * @param request DescribePatternTypesRequest
+     * @return DescribePatternTypesResponse
+     */
+    describePatternTypes(request: DescribePatternTypesRequest): Promise<DescribePatternTypesResponse>;
+    /**
+     * @summary Queries regions. Before you activate Auto Scaling, you can call the DescribeRegions operation to query the regions where Auto Scaling is officially launched. This preliminary step facilitates the strategic selection of both the optimal region and availability zones for activating Auto Scaling, thereby guaranteeing the finest access speeds and operational efficiency within your chosen geographical area.
+     *
+     * @param request DescribeRegionsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeRegionsResponse
+     */
     describeRegionsWithOptions(request: DescribeRegionsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeRegionsResponse>;
+    /**
+     * @summary Queries regions. Before you activate Auto Scaling, you can call the DescribeRegions operation to query the regions where Auto Scaling is officially launched. This preliminary step facilitates the strategic selection of both the optimal region and availability zones for activating Auto Scaling, thereby guaranteeing the finest access speeds and operational efficiency within your chosen geographical area.
+     *
+     * @param request DescribeRegionsRequest
+     * @return DescribeRegionsResponse
+     */
     describeRegions(request: DescribeRegionsRequest): Promise<DescribeRegionsResponse>;
     /**
-      * You can specify a scaling group ID to query all scaling activities in the scaling group.
-      * You can filter query results based on the status of scaling activities.
-      * You can query scaling activities that are executed in the previous 30 days.
-      *
-      * @param request DescribeScalingActivitiesRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DescribeScalingActivitiesResponse
+     * @summary Queries scaling activities.
+     *
+     * @description You can specify a scaling group ID to query all scaling activities in the scaling group.
+     * You can filter query results based on the status of scaling activities.
+     * You can query scaling activities that are executed in the previous 30 days.
+     *
+     * @param request DescribeScalingActivitiesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingActivitiesResponse
      */
     describeScalingActivitiesWithOptions(request: DescribeScalingActivitiesRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingActivitiesResponse>;
     /**
-      * You can specify a scaling group ID to query all scaling activities in the scaling group.
-      * You can filter query results based on the status of scaling activities.
-      * You can query scaling activities that are executed in the previous 30 days.
-      *
-      * @param request DescribeScalingActivitiesRequest
-      * @return DescribeScalingActivitiesResponse
+     * @summary Queries scaling activities.
+     *
+     * @description You can specify a scaling group ID to query all scaling activities in the scaling group.
+     * You can filter query results based on the status of scaling activities.
+     * You can query scaling activities that are executed in the previous 30 days.
+     *
+     * @param request DescribeScalingActivitiesRequest
+     * @return DescribeScalingActivitiesResponse
      */
     describeScalingActivities(request: DescribeScalingActivitiesRequest): Promise<DescribeScalingActivitiesResponse>;
+    /**
+     * @summary Queries the details about a scaling activity.
+     *
+     * @param request DescribeScalingActivityDetailRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingActivityDetailResponse
+     */
     describeScalingActivityDetailWithOptions(request: DescribeScalingActivityDetailRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingActivityDetailResponse>;
+    /**
+     * @summary Queries the details about a scaling activity.
+     *
+     * @param request DescribeScalingActivityDetailRequest
+     * @return DescribeScalingActivityDetailResponse
+     */
     describeScalingActivityDetail(request: DescribeScalingActivityDetailRequest): Promise<DescribeScalingActivityDetailResponse>;
+    /**
+     * @summary Queries scaling configurations.
+     *
+     * @param request DescribeScalingConfigurationsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingConfigurationsResponse
+     */
     describeScalingConfigurationsWithOptions(request: DescribeScalingConfigurationsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingConfigurationsResponse>;
+    /**
+     * @summary Queries scaling configurations.
+     *
+     * @param request DescribeScalingConfigurationsRequest
+     * @return DescribeScalingConfigurationsResponse
+     */
     describeScalingConfigurations(request: DescribeScalingConfigurationsRequest): Promise<DescribeScalingConfigurationsResponse>;
+    /**
+     * @summary Queries a scaling group. You can call the DescribeScalingGroupDetail operation to query the basic information, instances, and scaling configurations of a scaling group. If you set OutputFormat to yaml, a Kubernetes Deployment file that is in the YAML format is returned.
+     *
+     * @param request DescribeScalingGroupDetailRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingGroupDetailResponse
+     */
     describeScalingGroupDetailWithOptions(request: DescribeScalingGroupDetailRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingGroupDetailResponse>;
+    /**
+     * @summary Queries a scaling group. You can call the DescribeScalingGroupDetail operation to query the basic information, instances, and scaling configurations of a scaling group. If you set OutputFormat to yaml, a Kubernetes Deployment file that is in the YAML format is returned.
+     *
+     * @param request DescribeScalingGroupDetailRequest
+     * @return DescribeScalingGroupDetailResponse
+     */
     describeScalingGroupDetail(request: DescribeScalingGroupDetailRequest): Promise<DescribeScalingGroupDetailResponse>;
+    /**
+     * @summary Queries scaling groups. If you want to query the basic information, instances, and scaling configurations of a scaling group, you can call the DescribeScalingGroups operation.
+     *
+     * @param request DescribeScalingGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingGroupsResponse
+     */
     describeScalingGroupsWithOptions(request: DescribeScalingGroupsRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingGroupsResponse>;
+    /**
+     * @summary Queries scaling groups. If you want to query the basic information, instances, and scaling configurations of a scaling group, you can call the DescribeScalingGroups operation.
+     *
+     * @param request DescribeScalingGroupsRequest
+     * @return DescribeScalingGroupsResponse
+     */
     describeScalingGroups(request: DescribeScalingGroupsRequest): Promise<DescribeScalingGroupsResponse>;
+    /**
+     * @summary Queries the Elastic Compute Service (ECS) instances in a scaling group
+     *
+     * @param request DescribeScalingInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingInstancesResponse
+     */
     describeScalingInstancesWithOptions(request: DescribeScalingInstancesRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingInstancesResponse>;
+    /**
+     * @summary Queries the Elastic Compute Service (ECS) instances in a scaling group
+     *
+     * @param request DescribeScalingInstancesRequest
+     * @return DescribeScalingInstancesResponse
+     */
     describeScalingInstances(request: DescribeScalingInstancesRequest): Promise<DescribeScalingInstancesResponse>;
     /**
-      * You can specify a scaling group ID to query all scaling rules in the scaling group. You can also specify the scaling rule ID, name, unique identifier, and type in the request parameters as filter conditions.
-      *
-      * @param request DescribeScalingRulesRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DescribeScalingRulesResponse
+     * @summary Queries all scaling rules in a scaling group.
+     *
+     * @description You can specify a scaling group ID to query all scaling rules in the scaling group. You can also specify the scaling rule ID, name, unique identifier, and type in the request parameters as filter conditions.
+     *
+     * @param request DescribeScalingRulesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScalingRulesResponse
      */
     describeScalingRulesWithOptions(request: DescribeScalingRulesRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScalingRulesResponse>;
     /**
-      * You can specify a scaling group ID to query all scaling rules in the scaling group. You can also specify the scaling rule ID, name, unique identifier, and type in the request parameters as filter conditions.
-      *
-      * @param request DescribeScalingRulesRequest
-      * @return DescribeScalingRulesResponse
+     * @summary Queries all scaling rules in a scaling group.
+     *
+     * @description You can specify a scaling group ID to query all scaling rules in the scaling group. You can also specify the scaling rule ID, name, unique identifier, and type in the request parameters as filter conditions.
+     *
+     * @param request DescribeScalingRulesRequest
+     * @return DescribeScalingRulesResponse
      */
     describeScalingRules(request: DescribeScalingRulesRequest): Promise<DescribeScalingRulesResponse>;
+    /**
+     * @summary Queries scheduled tasks.
+     *
+     * @description You can query scheduled tasks by scaling rule, task ID, or task name.
+     *
+     * @param request DescribeScheduledTasksRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DescribeScheduledTasksResponse
+     */
     describeScheduledTasksWithOptions(request: DescribeScheduledTasksRequest, runtime: $Util.RuntimeOptions): Promise<DescribeScheduledTasksResponse>;
+    /**
+     * @summary Queries scheduled tasks.
+     *
+     * @description You can query scheduled tasks by scaling rule, task ID, or task name.
+     *
+     * @param request DescribeScheduledTasksRequest
+     * @return DescribeScheduledTasksResponse
+     */
     describeScheduledTasks(request: DescribeScheduledTasksRequest): Promise<DescribeScheduledTasksResponse>;
+    /**
+     * @summary Disassociates one or more Application Load Balancer (ALB) server groups from a scaling group.
+     *
+     * @param request DetachAlbServerGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DetachAlbServerGroupsResponse
+     */
     detachAlbServerGroupsWithOptions(request: DetachAlbServerGroupsRequest, runtime: $Util.RuntimeOptions): Promise<DetachAlbServerGroupsResponse>;
+    /**
+     * @summary Disassociates one or more Application Load Balancer (ALB) server groups from a scaling group.
+     *
+     * @param request DetachAlbServerGroupsRequest
+     * @return DetachAlbServerGroupsResponse
+     */
     detachAlbServerGroups(request: DetachAlbServerGroupsRequest): Promise<DetachAlbServerGroupsResponse>;
+    /**
+     * @summary Disassociates one or more ApsaraDB RDS instances from a scaling group.
+     *
+     * @param request DetachDBInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DetachDBInstancesResponse
+     */
     detachDBInstancesWithOptions(request: DetachDBInstancesRequest, runtime: $Util.RuntimeOptions): Promise<DetachDBInstancesResponse>;
+    /**
+     * @summary Disassociates one or more ApsaraDB RDS instances from a scaling group.
+     *
+     * @param request DetachDBInstancesRequest
+     * @return DetachDBInstancesResponse
+     */
     detachDBInstances(request: DetachDBInstancesRequest): Promise<DetachDBInstancesResponse>;
     /**
-      * After ECS instances or elastic container instances are removed from a scaling group, you can call the AttachInstances operation to add the ECS instances or elastic container instances that are removed from the scaling group to other scaling groups.
-      * After you remove an ECS instance or elastic container instance by calling the DetachInstances operation, the instance is not stopped or released.
-      * Before you call this operation, make sure that the following conditions are met:
-      * *   The specified scaling group is enabled.
-      * *   No scaling activities in the specified scaling group are in progress.
-      * > If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * A successful call indicates only that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
-      * The number of ECS instances or elastic container instances in a scaling group after you remove a specific number of instances from the scaling group must be equal to or greater than the value of the MinSize parameter. Otherwise, an error is reported when you call the DetachInstances operation.
-      *
-      * @param request DetachInstancesRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DetachInstancesResponse
+     * @summary Removes one or more Elastic Compute Service (ECS) instances or elastic container instances from a scaling group.
+     *
+     * @description After ECS instances or elastic container instances are removed from a scaling group, you can call the AttachInstances operation to add the ECS instances or elastic container instances that are removed from the scaling group to other scaling groups.
+     * After you remove an ECS instance or elastic container instance by calling the DetachInstances operation, the instance is not stopped or released.
+     * Before you call this operation, make sure that the following conditions are met:
+     * *   The specified scaling group is enabled.
+     * *   No scaling activities in the specified scaling group are in progress.
+     * > If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * A successful call indicates only that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
+     * The number of ECS instances or elastic container instances in a scaling group after you remove a specific number of instances from the scaling group must be equal to or greater than the value of the MinSize parameter. Otherwise, an error is reported when you call the DetachInstances operation.
+     *
+     * @param request DetachInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DetachInstancesResponse
      */
     detachInstancesWithOptions(request: DetachInstancesRequest, runtime: $Util.RuntimeOptions): Promise<DetachInstancesResponse>;
     /**
-      * After ECS instances or elastic container instances are removed from a scaling group, you can call the AttachInstances operation to add the ECS instances or elastic container instances that are removed from the scaling group to other scaling groups.
-      * After you remove an ECS instance or elastic container instance by calling the DetachInstances operation, the instance is not stopped or released.
-      * Before you call this operation, make sure that the following conditions are met:
-      * *   The specified scaling group is enabled.
-      * *   No scaling activities in the specified scaling group are in progress.
-      * > If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * A successful call indicates only that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
-      * The number of ECS instances or elastic container instances in a scaling group after you remove a specific number of instances from the scaling group must be equal to or greater than the value of the MinSize parameter. Otherwise, an error is reported when you call the DetachInstances operation.
-      *
-      * @param request DetachInstancesRequest
-      * @return DetachInstancesResponse
+     * @summary Removes one or more Elastic Compute Service (ECS) instances or elastic container instances from a scaling group.
+     *
+     * @description After ECS instances or elastic container instances are removed from a scaling group, you can call the AttachInstances operation to add the ECS instances or elastic container instances that are removed from the scaling group to other scaling groups.
+     * After you remove an ECS instance or elastic container instance by calling the DetachInstances operation, the instance is not stopped or released.
+     * Before you call this operation, make sure that the following conditions are met:
+     * *   The specified scaling group is enabled.
+     * *   No scaling activities in the specified scaling group are in progress.
+     * > If no scaling activities in the specified scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * A successful call indicates only that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
+     * The number of ECS instances or elastic container instances in a scaling group after you remove a specific number of instances from the scaling group must be equal to or greater than the value of the MinSize parameter. Otherwise, an error is reported when you call the DetachInstances operation.
+     *
+     * @param request DetachInstancesRequest
+     * @return DetachInstancesResponse
      */
     detachInstances(request: DetachInstancesRequest): Promise<DetachInstancesResponse>;
+    /**
+     * @summary Detaches one or more Classic Load Balancer (CLB) instances from a scaling group.
+     *
+     * @param request DetachLoadBalancersRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DetachLoadBalancersResponse
+     */
     detachLoadBalancersWithOptions(request: DetachLoadBalancersRequest, runtime: $Util.RuntimeOptions): Promise<DetachLoadBalancersResponse>;
+    /**
+     * @summary Detaches one or more Classic Load Balancer (CLB) instances from a scaling group.
+     *
+     * @param request DetachLoadBalancersRequest
+     * @return DetachLoadBalancersResponse
+     */
     detachLoadBalancers(request: DetachLoadBalancersRequest): Promise<DetachLoadBalancersResponse>;
+    /**
+     * @summary Detaches one or more server groups from a scaling group. You can attach and detach the following server groups from a scaling group: Application Load Balancer (ALB) and Network Load Balancer (NLB) server groups.
+     *
+     * @param request DetachServerGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DetachServerGroupsResponse
+     */
     detachServerGroupsWithOptions(request: DetachServerGroupsRequest, runtime: $Util.RuntimeOptions): Promise<DetachServerGroupsResponse>;
+    /**
+     * @summary Detaches one or more server groups from a scaling group. You can attach and detach the following server groups from a scaling group: Application Load Balancer (ALB) and Network Load Balancer (NLB) server groups.
+     *
+     * @param request DetachServerGroupsRequest
+     * @return DetachServerGroupsResponse
+     */
     detachServerGroups(request: DetachServerGroupsRequest): Promise<DetachServerGroupsResponse>;
     /**
-      * You can use the following parameters to specify the vServer groups that you want to detach from your scaling group.
-      * *   LoadBalancerId: the ID of the Classic Load Balancer (CLB) instance.
-      * *   VServerGroupId: the ID of the vServer group.
-      * *   Port: the port number of the vServer group.
-      * If the vServer group that is specified in this call matches the vServer group associated with your scaling group, the vServer group can be detached. Otherwise, the request for detaching the vServer group is ignored, and no error is reported.
-      *
-      * @param request DetachVServerGroupsRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return DetachVServerGroupsResponse
+     * @summary Detaches vServer groups from a scaling group. Auto Scaling supports the attachment of load balancers to scaling groups to improve service performance. If the load balancer currently attached to your scaling group is no longer needed to distribute the access traffic to the instances in your scaling group, you can call the DetachVServerGroups operation to detach one or more vServer groups of this load balancer from the scaling group.
+     *
+     * @description *   When you call the DetachVServerGroups operation, you must use the following parameters to specify the vServer groups that you want to detach from your scaling group:
+     *     *   LoadBalancerId: the ID of the load balancer
+     *     *   VServerGroupId: the ID of the vServer group
+     *     *   Port: the port number of the vServer group
+     * *   When the vServer group specified by the request parameters matches that attached to your scaling group, this operation yields a favorable result. Otherwise, the request is ignored and no error is reported.
+     * *   Before you call this operation, you must make sure that the load balancer has ceased routing the access traffic to the instances in the scaling group. Failure to do so may lead to service requests being dropped or lost during the detachment process.
+     *
+     * @param request DetachVServerGroupsRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DetachVServerGroupsResponse
      */
     detachVServerGroupsWithOptions(request: DetachVServerGroupsRequest, runtime: $Util.RuntimeOptions): Promise<DetachVServerGroupsResponse>;
     /**
-      * You can use the following parameters to specify the vServer groups that you want to detach from your scaling group.
-      * *   LoadBalancerId: the ID of the Classic Load Balancer (CLB) instance.
-      * *   VServerGroupId: the ID of the vServer group.
-      * *   Port: the port number of the vServer group.
-      * If the vServer group that is specified in this call matches the vServer group associated with your scaling group, the vServer group can be detached. Otherwise, the request for detaching the vServer group is ignored, and no error is reported.
-      *
-      * @param request DetachVServerGroupsRequest
-      * @return DetachVServerGroupsResponse
+     * @summary Detaches vServer groups from a scaling group. Auto Scaling supports the attachment of load balancers to scaling groups to improve service performance. If the load balancer currently attached to your scaling group is no longer needed to distribute the access traffic to the instances in your scaling group, you can call the DetachVServerGroups operation to detach one or more vServer groups of this load balancer from the scaling group.
+     *
+     * @description *   When you call the DetachVServerGroups operation, you must use the following parameters to specify the vServer groups that you want to detach from your scaling group:
+     *     *   LoadBalancerId: the ID of the load balancer
+     *     *   VServerGroupId: the ID of the vServer group
+     *     *   Port: the port number of the vServer group
+     * *   When the vServer group specified by the request parameters matches that attached to your scaling group, this operation yields a favorable result. Otherwise, the request is ignored and no error is reported.
+     * *   Before you call this operation, you must make sure that the load balancer has ceased routing the access traffic to the instances in the scaling group. Failure to do so may lead to service requests being dropped or lost during the detachment process.
+     *
+     * @param request DetachVServerGroupsRequest
+     * @return DetachVServerGroupsResponse
      */
     detachVServerGroups(request: DetachVServerGroupsRequest): Promise<DetachVServerGroupsResponse>;
+    /**
+     * @summary Disables an event-triggered task. If your business pattern is unpredictable or prone to unforeseen traffic spikes, you can create event-triggered tasks by associating CloudMonitor metrics to effectively monitor fluctuations in your business workload. Upon detecting that the criteria for alerts, as specified in event-triggered tasks, are fulfilled, Auto Scaling promptly issues alerts and executes the scaling rules predefined within those tasks. This process occurs within the predefined effective time windows of the tasks, thereby facilitating the automatic increase or decrease of Elastic Compute Service (ECS) instances or elastic container instances within your scaling groups. Ultimately, this mechanism ensures the dynamic optimization of resources based on real-time workload demands. If you currently do not need an event-triggered task, you can call the DisableAlarm operation to disable it.
+     *
+     * @description Before you disable an event-triggered task, make sure that the task is in the `Normal`, `Alert`, or `Insufficient Data` state.
+     *
+     * @param request DisableAlarmRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DisableAlarmResponse
+     */
     disableAlarmWithOptions(request: DisableAlarmRequest, runtime: $Util.RuntimeOptions): Promise<DisableAlarmResponse>;
+    /**
+     * @summary Disables an event-triggered task. If your business pattern is unpredictable or prone to unforeseen traffic spikes, you can create event-triggered tasks by associating CloudMonitor metrics to effectively monitor fluctuations in your business workload. Upon detecting that the criteria for alerts, as specified in event-triggered tasks, are fulfilled, Auto Scaling promptly issues alerts and executes the scaling rules predefined within those tasks. This process occurs within the predefined effective time windows of the tasks, thereby facilitating the automatic increase or decrease of Elastic Compute Service (ECS) instances or elastic container instances within your scaling groups. Ultimately, this mechanism ensures the dynamic optimization of resources based on real-time workload demands. If you currently do not need an event-triggered task, you can call the DisableAlarm operation to disable it.
+     *
+     * @description Before you disable an event-triggered task, make sure that the task is in the `Normal`, `Alert`, or `Insufficient Data` state.
+     *
+     * @param request DisableAlarmRequest
+     * @return DisableAlarmResponse
+     */
     disableAlarm(request: DisableAlarmRequest): Promise<DisableAlarmResponse>;
+    /**
+     * @summary Disables a scaling group.
+     *
+     * @description Before you call this operation to disable a scaling group, take note of the following items:
+     * *   When you call this operation, ongoing scaling activities will continue until they are complete, but new activities will be rejected.
+     * *   You can disable only scaling groups that are in the Active state.
+     *
+     * @param request DisableScalingGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return DisableScalingGroupResponse
+     */
     disableScalingGroupWithOptions(request: DisableScalingGroupRequest, runtime: $Util.RuntimeOptions): Promise<DisableScalingGroupResponse>;
+    /**
+     * @summary Disables a scaling group.
+     *
+     * @description Before you call this operation to disable a scaling group, take note of the following items:
+     * *   When you call this operation, ongoing scaling activities will continue until they are complete, but new activities will be rejected.
+     * *   You can disable only scaling groups that are in the Active state.
+     *
+     * @param request DisableScalingGroupRequest
+     * @return DisableScalingGroupResponse
+     */
     disableScalingGroup(request: DisableScalingGroupRequest): Promise<DisableScalingGroupResponse>;
+    /**
+     * @summary Enables an event-triggered task. If your business pattern is unpredictable or prone to unforeseen traffic spikes, you can create event-triggered tasks by associating CloudMonitor metrics to effectively monitor fluctuations in your business workload. Upon detecting that the criteria for alerts, as specified in event-triggered tasks, are fulfilled, Auto Scaling promptly issues alerts and executes the scaling rules predefined within those tasks. This process occurs within the predefined effective time windows of the tasks, thereby facilitating the automatic increase or decrease of Elastic Compute Service (ECS) instances or elastic container instances within your scaling groups. Ultimately, this mechanism ensures the dynamic optimization of resources based on real-time workload demands. If you want to reuse an event-triggered task that is in the Disabled state, you can call the EnableAlarm operation to enable it.
+     *
+     * @param request EnableAlarmRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return EnableAlarmResponse
+     */
     enableAlarmWithOptions(request: EnableAlarmRequest, runtime: $Util.RuntimeOptions): Promise<EnableAlarmResponse>;
+    /**
+     * @summary Enables an event-triggered task. If your business pattern is unpredictable or prone to unforeseen traffic spikes, you can create event-triggered tasks by associating CloudMonitor metrics to effectively monitor fluctuations in your business workload. Upon detecting that the criteria for alerts, as specified in event-triggered tasks, are fulfilled, Auto Scaling promptly issues alerts and executes the scaling rules predefined within those tasks. This process occurs within the predefined effective time windows of the tasks, thereby facilitating the automatic increase or decrease of Elastic Compute Service (ECS) instances or elastic container instances within your scaling groups. Ultimately, this mechanism ensures the dynamic optimization of resources based on real-time workload demands. If you want to reuse an event-triggered task that is in the Disabled state, you can call the EnableAlarm operation to enable it.
+     *
+     * @param request EnableAlarmRequest
+     * @return EnableAlarmResponse
+     */
     enableAlarm(request: EnableAlarmRequest): Promise<EnableAlarmResponse>;
     /**
-      * You can call this operation to enable a scaling group that is in the Inactive state and has an instance configuration source. The instance configuration source can be a scaling configuration, a launch template, or an Elastic Compute Service (ECS) instance that you specified when you created the scaling group. If a scaling group is not in the Inactive state or does not have an active instance configuration source, you cannot call this operation to enable the scaling group.
-      * > A scaling group can have only one active instance configuration source. When you call this operation to enable a scaling group, you can specify a scaling configuration or a launch template for the scaling group. If an instance configuration source has been configured for the scaling group before you call this operation, the scaling configuration or launch template that you specify in the request overwrites the original scaling configuration or launch template.
-      * If you specify a value for the InstanceIds parameter when you call the operation, Auto Scaling checks whether the total number of ECS instances is within the range allowed in the scaling group after you call the operation.
-      * *   If the total number of ECS instances is less than the minimum number of instances required in the scaling group after you call the operation, Auto Scaling automatically creates the required number of pay-as-you-go ECS instances and adds the instances to the scaling group to reach the minimum number. For example, if the minimum number of instances required in your scaling group is five, and you specify the InstanceIds parameter to add two ECS instances to the scaling group, Auto Scaling automatically creates three instances in the scaling group after the two instances are added.
-      * *   If the value of the TotalCapacity parameter is greater than the value of the MaxSize parameter, the call fails.
-      *
-      * @param request EnableScalingGroupRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return EnableScalingGroupResponse
+     * @summary Enables a scaling group.
+     *
+     * @description You can call this operation to enable a scaling group that is in the Inactive state and has an instance configuration source. The instance configuration source can be a scaling configuration, a launch template, or an Elastic Compute Service (ECS) instance that you specified when you created the scaling group. If a scaling group is not in the Inactive state or does not have an active instance configuration source, you cannot call this operation to enable the scaling group.
+     * > A scaling group can have only one active instance configuration source. When you call this operation to enable a scaling group, you can specify a scaling configuration or a launch template for the scaling group. If an instance configuration source has been configured for the scaling group before you call this operation, the scaling configuration or launch template that you specify in the request overwrites the original scaling configuration or launch template.
+     * If you specify a value for the InstanceId parameter when you call the operation, Auto Scaling checks whether the total number of ECS instances is within the range allowed in the scaling group after you call the operation.
+     * *   If the total number of ECS instances is less than the minimum number of instances allowed in the scaling group after you call the operation, Auto Scaling automatically creates the required number of pay-as-you-go ECS instances and adds the instances to the scaling group to reach the minimum number. For example, if the minimum number of instances allowed in your scaling group is five, and you specify the InstanceId parameter to add two created ECS instances to the scaling group, Auto Scaling automatically creates three instances in the scaling group after the two instances are added.
+     * *   If the value of the TotalCapactiy parameter is greater than the value of the MaxSize parameter, the call fails.
+     *
+     * @param request EnableScalingGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return EnableScalingGroupResponse
      */
     enableScalingGroupWithOptions(request: EnableScalingGroupRequest, runtime: $Util.RuntimeOptions): Promise<EnableScalingGroupResponse>;
     /**
-      * You can call this operation to enable a scaling group that is in the Inactive state and has an instance configuration source. The instance configuration source can be a scaling configuration, a launch template, or an Elastic Compute Service (ECS) instance that you specified when you created the scaling group. If a scaling group is not in the Inactive state or does not have an active instance configuration source, you cannot call this operation to enable the scaling group.
-      * > A scaling group can have only one active instance configuration source. When you call this operation to enable a scaling group, you can specify a scaling configuration or a launch template for the scaling group. If an instance configuration source has been configured for the scaling group before you call this operation, the scaling configuration or launch template that you specify in the request overwrites the original scaling configuration or launch template.
-      * If you specify a value for the InstanceIds parameter when you call the operation, Auto Scaling checks whether the total number of ECS instances is within the range allowed in the scaling group after you call the operation.
-      * *   If the total number of ECS instances is less than the minimum number of instances required in the scaling group after you call the operation, Auto Scaling automatically creates the required number of pay-as-you-go ECS instances and adds the instances to the scaling group to reach the minimum number. For example, if the minimum number of instances required in your scaling group is five, and you specify the InstanceIds parameter to add two ECS instances to the scaling group, Auto Scaling automatically creates three instances in the scaling group after the two instances are added.
-      * *   If the value of the TotalCapacity parameter is greater than the value of the MaxSize parameter, the call fails.
-      *
-      * @param request EnableScalingGroupRequest
-      * @return EnableScalingGroupResponse
+     * @summary Enables a scaling group.
+     *
+     * @description You can call this operation to enable a scaling group that is in the Inactive state and has an instance configuration source. The instance configuration source can be a scaling configuration, a launch template, or an Elastic Compute Service (ECS) instance that you specified when you created the scaling group. If a scaling group is not in the Inactive state or does not have an active instance configuration source, you cannot call this operation to enable the scaling group.
+     * > A scaling group can have only one active instance configuration source. When you call this operation to enable a scaling group, you can specify a scaling configuration or a launch template for the scaling group. If an instance configuration source has been configured for the scaling group before you call this operation, the scaling configuration or launch template that you specify in the request overwrites the original scaling configuration or launch template.
+     * If you specify a value for the InstanceId parameter when you call the operation, Auto Scaling checks whether the total number of ECS instances is within the range allowed in the scaling group after you call the operation.
+     * *   If the total number of ECS instances is less than the minimum number of instances allowed in the scaling group after you call the operation, Auto Scaling automatically creates the required number of pay-as-you-go ECS instances and adds the instances to the scaling group to reach the minimum number. For example, if the minimum number of instances allowed in your scaling group is five, and you specify the InstanceId parameter to add two created ECS instances to the scaling group, Auto Scaling automatically creates three instances in the scaling group after the two instances are added.
+     * *   If the value of the TotalCapactiy parameter is greater than the value of the MaxSize parameter, the call fails.
+     *
+     * @param request EnableScalingGroupRequest
+     * @return EnableScalingGroupResponse
      */
     enableScalingGroup(request: EnableScalingGroupRequest): Promise<EnableScalingGroupResponse>;
+    /**
+     * @summary Puts an Elastic Compute Service (ECS) instance into the Standby state.
+     *
+     * @description ## Description
+     * *   If you call the operation to put an ECS instance in a scaling group that is associated with a Classic Load Balancer (CLB) instance into the Standby state, the weight of the ECS instance as a backend server of the CLB instance is set to 0.
+     * *   You can remove an instance that is in the Standby state from a scaling group, and then release the instance.
+     * *   ECS instances that are in the Standby state are not removed from the scaling group during scale-in activities triggered by event-triggered tasks.
+     * *   If Auto Scaling considers an ECS instance that is in the Standby state unhealthy, for example, the ECS instance is being stopped or being restarted, Auto Scaling does not update the health status of the ECS instance or trigger scale-in activities to remove the ECS instance from the scaling group. Auto Scaling updates the health status of the ECS instance only when the ECS instance is no longer in the Standby state.
+     *
+     * @param request EnterStandbyRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return EnterStandbyResponse
+     */
     enterStandbyWithOptions(request: EnterStandbyRequest, runtime: $Util.RuntimeOptions): Promise<EnterStandbyResponse>;
+    /**
+     * @summary Puts an Elastic Compute Service (ECS) instance into the Standby state.
+     *
+     * @description ## Description
+     * *   If you call the operation to put an ECS instance in a scaling group that is associated with a Classic Load Balancer (CLB) instance into the Standby state, the weight of the ECS instance as a backend server of the CLB instance is set to 0.
+     * *   You can remove an instance that is in the Standby state from a scaling group, and then release the instance.
+     * *   ECS instances that are in the Standby state are not removed from the scaling group during scale-in activities triggered by event-triggered tasks.
+     * *   If Auto Scaling considers an ECS instance that is in the Standby state unhealthy, for example, the ECS instance is being stopped or being restarted, Auto Scaling does not update the health status of the ECS instance or trigger scale-in activities to remove the ECS instance from the scaling group. Auto Scaling updates the health status of the ECS instance only when the ECS instance is no longer in the Standby state.
+     *
+     * @param request EnterStandbyRequest
+     * @return EnterStandbyResponse
+     */
     enterStandby(request: EnterStandbyRequest): Promise<EnterStandbyResponse>;
     /**
-      * Before you call this operation, take note of the following items:
-      * *   The scaling group is in the Active state.
-      * *   No scaling activities in the scaling group are in progress.
-      * If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
-      * If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
-      * If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
-      * You can specify only a limited number of ECS instances in each adjustment. For more information, see the description of the AdjustmentValue parameter in the CreateScalingRule topic.
-      *
-      * @param request ExecuteScalingRuleRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ExecuteScalingRuleResponse
+     * @summary Executes a scaling rule.
+     *
+     * @description Before you call this operation, take note of the following items:
+     * *   The scaling group is in the Active state.
+     * *   No scaling activities in the scaling group are in progress.
+     * If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
+     * If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
+     * If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
+     * You can specify only a limited number of ECS instances in each adjustment. For more information, see the description of the AdjustmentValue parameter in the CreateScalingRule topic.
+     *
+     * @param request ExecuteScalingRuleRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ExecuteScalingRuleResponse
      */
     executeScalingRuleWithOptions(request: ExecuteScalingRuleRequest, runtime: $Util.RuntimeOptions): Promise<ExecuteScalingRuleResponse>;
     /**
-      * Before you call this operation, take note of the following items:
-      * *   The scaling group is in the Active state.
-      * *   No scaling activities in the scaling group are in progress.
-      * If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
-      * If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
-      * If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
-      * You can specify only a limited number of ECS instances in each adjustment. For more information, see the description of the AdjustmentValue parameter in the CreateScalingRule topic.
-      *
-      * @param request ExecuteScalingRuleRequest
-      * @return ExecuteScalingRuleResponse
+     * @summary Executes a scaling rule.
+     *
+     * @description Before you call this operation, take note of the following items:
+     * *   The scaling group is in the Active state.
+     * *   No scaling activities in the scaling group are in progress.
+     * If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the ScalingActivityId parameter in the response.
+     * If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
+     * If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
+     * You can specify only a limited number of ECS instances in each adjustment. For more information, see the description of the AdjustmentValue parameter in the CreateScalingRule topic.
+     *
+     * @param request ExecuteScalingRuleRequest
+     * @return ExecuteScalingRuleResponse
      */
     executeScalingRule(request: ExecuteScalingRuleRequest): Promise<ExecuteScalingRuleResponse>;
+    /**
+     * @summary Moves an Elastic Compute Service (ECS) instance out of the Standby state.
+     *
+     * @description ## Description
+     * If your scaling group is associated with a Classic Load Balancer (CLB) instance and you move an ECS instance in your scaling group out of the Standby state, the weight of the ECS instance is reset to the value that is specified in the scaling configuration of your scaling group.
+     *
+     * @param request ExitStandbyRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ExitStandbyResponse
+     */
     exitStandbyWithOptions(request: ExitStandbyRequest, runtime: $Util.RuntimeOptions): Promise<ExitStandbyResponse>;
+    /**
+     * @summary Moves an Elastic Compute Service (ECS) instance out of the Standby state.
+     *
+     * @description ## Description
+     * If your scaling group is associated with a Classic Load Balancer (CLB) instance and you move an ECS instance in your scaling group out of the Standby state, the weight of the ECS instance is reset to the value that is specified in the scaling configuration of your scaling group.
+     *
+     * @param request ExitStandbyRequest
+     * @return ExitStandbyResponse
+     */
     exitStandby(request: ExitStandbyRequest): Promise<ExitStandbyResponse>;
+    /**
+     * @summary Queries the tag keys added to Auto Scaling resources. Querying tag keys facilitates easier classification, identification, and monitoring of your Auto Scaling resources, thereby enhancing the flexibility and convenience of your resource management processes.
+     *
+     * @param request ListTagKeysRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ListTagKeysResponse
+     */
     listTagKeysWithOptions(request: ListTagKeysRequest, runtime: $Util.RuntimeOptions): Promise<ListTagKeysResponse>;
+    /**
+     * @summary Queries the tag keys added to Auto Scaling resources. Querying tag keys facilitates easier classification, identification, and monitoring of your Auto Scaling resources, thereby enhancing the flexibility and convenience of your resource management processes.
+     *
+     * @param request ListTagKeysRequest
+     * @return ListTagKeysResponse
+     */
     listTagKeys(request: ListTagKeysRequest): Promise<ListTagKeysResponse>;
+    /**
+     * @summary Queries tags that are added to one or more Auto Scaling resources.
+     *
+     * @param request ListTagResourcesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ListTagResourcesResponse
+     */
     listTagResourcesWithOptions(request: ListTagResourcesRequest, runtime: $Util.RuntimeOptions): Promise<ListTagResourcesResponse>;
+    /**
+     * @summary Queries tags that are added to one or more Auto Scaling resources.
+     *
+     * @param request ListTagResourcesRequest
+     * @return ListTagResourcesResponse
+     */
     listTagResources(request: ListTagResourcesRequest): Promise<ListTagResourcesResponse>;
+    /**
+     * @summary Queries the tag keys associated with Auto Scaling resources to facilitate a deeper comprehension of those resources. By doing so, you can categorize and manage your Auto Scaling resources more efficiently.
+     *
+     * @param request ListTagValuesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ListTagValuesResponse
+     */
     listTagValuesWithOptions(request: ListTagValuesRequest, runtime: $Util.RuntimeOptions): Promise<ListTagValuesResponse>;
+    /**
+     * @summary Queries the tag keys associated with Auto Scaling resources to facilitate a deeper comprehension of those resources. By doing so, you can categorize and manage your Auto Scaling resources more efficiently.
+     *
+     * @param request ListTagValuesRequest
+     * @return ListTagValuesResponse
+     */
     listTagValues(request: ListTagValuesRequest): Promise<ListTagValuesResponse>;
     /**
-      * *   If you set the MetricType parameter to custom, you must report your custom metrics to CloudMonitor before you can create event-triggered tasks by using the custom metrics. For more information, see [Custom monitoring event-triggered tasks](~~74861~~).
-      * *   When you create an event-triggered task, you must specify the MetricName, DimensionKey, and DimensionValue parameters to determine the range of statistics that you want to aggregate for the metrics of the scaling group. For example, you can specify the user_id and scaling_group dimensions for an event-triggered task to aggregate monitoring data of all Elastic Compute Service (ECS) instances or elastic container instances in a scaling group within an Alibaba Cloud account.
-      *     *   If you set the MetricType parameter to custom, the valid values are your custom metrics.
-      *     *   For information about the metrics that are supported if you set the MetricType parameter to system, see[ Event-triggered task for system monitoring](~~74854~~).
-      * > The user_id and scaling_group dimensions are automatically populated. You need to only specify the device and state dimensions. For more information, see the `DimensionKey` and `DimensionValue` parameters in the "Request parameters" section of this topic.
-      *
-      * @param request ModifyAlarmRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ModifyAlarmResponse
+     * @summary Modifies an event-triggered task.
+     *
+     * @description *   If you set the MetricType parameter to custom, you must report your custom metrics to CloudMonitor before you can create event-triggered tasks by using the custom metrics. For more information, see [Custom monitoring event-triggered tasks](https://help.aliyun.com/document_detail/74861.html).
+     * *   When you create an event-triggered task, you must specify the MetricName, DimensionKey, and DimensionValue parameters to determine the range of statistics that you want to aggregate for the metrics of the scaling group. For example, you can specify the user_id and scaling_group dimensions for an event-triggered task to aggregate monitoring data of all Elastic Compute Service (ECS) instances or elastic container instances in a scaling group within an Alibaba Cloud account.
+     *     *   If you set the MetricType parameter to custom, the valid values are your custom metrics.
+     *     *   For information about the metrics that are supported if you set the MetricType parameter to system, see[ Event-triggered task for system monitoring](https://help.aliyun.com/document_detail/74854.html).
+     * > The user_id and scaling_group dimensions are automatically populated. You need to only specify the device and state dimensions. For more information, see the `DimensionKey` and `DimensionValue` parameters in the "Request parameters" section of this topic.
+     *
+     * @param request ModifyAlarmRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyAlarmResponse
      */
     modifyAlarmWithOptions(request: ModifyAlarmRequest, runtime: $Util.RuntimeOptions): Promise<ModifyAlarmResponse>;
     /**
-      * *   If you set the MetricType parameter to custom, you must report your custom metrics to CloudMonitor before you can create event-triggered tasks by using the custom metrics. For more information, see [Custom monitoring event-triggered tasks](~~74861~~).
-      * *   When you create an event-triggered task, you must specify the MetricName, DimensionKey, and DimensionValue parameters to determine the range of statistics that you want to aggregate for the metrics of the scaling group. For example, you can specify the user_id and scaling_group dimensions for an event-triggered task to aggregate monitoring data of all Elastic Compute Service (ECS) instances or elastic container instances in a scaling group within an Alibaba Cloud account.
-      *     *   If you set the MetricType parameter to custom, the valid values are your custom metrics.
-      *     *   For information about the metrics that are supported if you set the MetricType parameter to system, see[ Event-triggered task for system monitoring](~~74854~~).
-      * > The user_id and scaling_group dimensions are automatically populated. You need to only specify the device and state dimensions. For more information, see the `DimensionKey` and `DimensionValue` parameters in the "Request parameters" section of this topic.
-      *
-      * @param request ModifyAlarmRequest
-      * @return ModifyAlarmResponse
+     * @summary Modifies an event-triggered task.
+     *
+     * @description *   If you set the MetricType parameter to custom, you must report your custom metrics to CloudMonitor before you can create event-triggered tasks by using the custom metrics. For more information, see [Custom monitoring event-triggered tasks](https://help.aliyun.com/document_detail/74861.html).
+     * *   When you create an event-triggered task, you must specify the MetricName, DimensionKey, and DimensionValue parameters to determine the range of statistics that you want to aggregate for the metrics of the scaling group. For example, you can specify the user_id and scaling_group dimensions for an event-triggered task to aggregate monitoring data of all Elastic Compute Service (ECS) instances or elastic container instances in a scaling group within an Alibaba Cloud account.
+     *     *   If you set the MetricType parameter to custom, the valid values are your custom metrics.
+     *     *   For information about the metrics that are supported if you set the MetricType parameter to system, see[ Event-triggered task for system monitoring](https://help.aliyun.com/document_detail/74854.html).
+     * > The user_id and scaling_group dimensions are automatically populated. You need to only specify the device and state dimensions. For more information, see the `DimensionKey` and `DimensionValue` parameters in the "Request parameters" section of this topic.
+     *
+     * @param request ModifyAlarmRequest
+     * @return ModifyAlarmResponse
      */
     modifyAlarm(request: ModifyAlarmRequest): Promise<ModifyAlarmResponse>;
     /**
-      * If you want to change the name of a scaling configuration in a scaling group, make sure that the new name is unique within the scaling group.
-      *
-      * @param request ModifyEciScalingConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ModifyEciScalingConfigurationResponse
+     * @summary Modifies a scaling configuration for a scaling group that contains elastic container instances.
+     *
+     * @description If you want to change the name of a scaling configuration in a scaling group, make sure that the new name is unique within the scaling group.
+     *
+     * @param request ModifyEciScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyEciScalingConfigurationResponse
      */
     modifyEciScalingConfigurationWithOptions(request: ModifyEciScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<ModifyEciScalingConfigurationResponse>;
     /**
-      * If you want to change the name of a scaling configuration in a scaling group, make sure that the new name is unique within the scaling group.
-      *
-      * @param request ModifyEciScalingConfigurationRequest
-      * @return ModifyEciScalingConfigurationResponse
+     * @summary Modifies a scaling configuration for a scaling group that contains elastic container instances.
+     *
+     * @description If you want to change the name of a scaling configuration in a scaling group, make sure that the new name is unique within the scaling group.
+     *
+     * @param request ModifyEciScalingConfigurationRequest
+     * @return ModifyEciScalingConfigurationResponse
      */
     modifyEciScalingConfiguration(request: ModifyEciScalingConfigurationRequest): Promise<ModifyEciScalingConfigurationResponse>;
+    /**
+     * @summary Modifies the attributes of an Elastic Compute Service (ECS) instance in a scaling group. You can call the ModifyInstanceAttribute operation to modify the lifecycle management attribute of a manually added ECS instance in a scaling group.
+     *
+     * @param request ModifyInstanceAttributeRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyInstanceAttributeResponse
+     */
     modifyInstanceAttributeWithOptions(request: ModifyInstanceAttributeRequest, runtime: $Util.RuntimeOptions): Promise<ModifyInstanceAttributeResponse>;
+    /**
+     * @summary Modifies the attributes of an Elastic Compute Service (ECS) instance in a scaling group. You can call the ModifyInstanceAttribute operation to modify the lifecycle management attribute of a manually added ECS instance in a scaling group.
+     *
+     * @param request ModifyInstanceAttributeRequest
+     * @return ModifyInstanceAttributeResponse
+     */
     modifyInstanceAttribute(request: ModifyInstanceAttributeRequest): Promise<ModifyInstanceAttributeResponse>;
     /**
-      * You can use one of the following methods to specify the lifecycle hook that you want to modify:
-      * *   Specify the lifecycle hook ID by using the LifecycleHookId parameter. When you use this method, the ScalingGroupId and LifecycleHookName parameters are ignored.
-      * *   Specify the scaling group ID by using the ScalingGroupId parameter and specify the lifecycle hook name by using the LifecycleHookName parameter.
-      *
-      * @param request ModifyLifecycleHookRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ModifyLifecycleHookResponse
+     * @summary Modifies a lifecycle hook.
+     *
+     * @description You can use one of the following methods to specify the lifecycle hook that you want to modify:
+     * *   Specify the lifecycle hook ID by using the LifecycleHookId parameter. When you use this method, the ScalingGroupId and LifecycleHookName parameters are ignored.
+     * *   Specify the scaling group ID by using the ScalingGroupId parameter and the lifecycle hook name by using the LifecycleHookName parameter.
+     *
+     * @param request ModifyLifecycleHookRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyLifecycleHookResponse
      */
     modifyLifecycleHookWithOptions(request: ModifyLifecycleHookRequest, runtime: $Util.RuntimeOptions): Promise<ModifyLifecycleHookResponse>;
     /**
-      * You can use one of the following methods to specify the lifecycle hook that you want to modify:
-      * *   Specify the lifecycle hook ID by using the LifecycleHookId parameter. When you use this method, the ScalingGroupId and LifecycleHookName parameters are ignored.
-      * *   Specify the scaling group ID by using the ScalingGroupId parameter and specify the lifecycle hook name by using the LifecycleHookName parameter.
-      *
-      * @param request ModifyLifecycleHookRequest
-      * @return ModifyLifecycleHookResponse
+     * @summary Modifies a lifecycle hook.
+     *
+     * @description You can use one of the following methods to specify the lifecycle hook that you want to modify:
+     * *   Specify the lifecycle hook ID by using the LifecycleHookId parameter. When you use this method, the ScalingGroupId and LifecycleHookName parameters are ignored.
+     * *   Specify the scaling group ID by using the ScalingGroupId parameter and the lifecycle hook name by using the LifecycleHookName parameter.
+     *
+     * @param request ModifyLifecycleHookRequest
+     * @return ModifyLifecycleHookResponse
      */
     modifyLifecycleHook(request: ModifyLifecycleHookRequest): Promise<ModifyLifecycleHookResponse>;
+    /**
+     * @summary Modifies a notification.
+     *
+     * @param request ModifyNotificationConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyNotificationConfigurationResponse
+     */
     modifyNotificationConfigurationWithOptions(request: ModifyNotificationConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<ModifyNotificationConfigurationResponse>;
+    /**
+     * @summary Modifies a notification.
+     *
+     * @param request ModifyNotificationConfigurationRequest
+     * @return ModifyNotificationConfigurationResponse
+     */
     modifyNotificationConfiguration(request: ModifyNotificationConfigurationRequest): Promise<ModifyNotificationConfigurationResponse>;
     /**
-      * You can change the name of a scaling configuration in a scaling group. The name must be unique within the scaling group.
-      *
-      * @param tmpReq ModifyScalingConfigurationRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ModifyScalingConfigurationResponse
+     * @summary Modifies a scaling configuration.
+     *
+     * @description You can change the name of a scaling configuration in a scaling group. The name must be unique within the scaling group.
+     *
+     * @param tmpReq ModifyScalingConfigurationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyScalingConfigurationResponse
      */
     modifyScalingConfigurationWithOptions(tmpReq: ModifyScalingConfigurationRequest, runtime: $Util.RuntimeOptions): Promise<ModifyScalingConfigurationResponse>;
     /**
-      * You can change the name of a scaling configuration in a scaling group. The name must be unique within the scaling group.
-      *
-      * @param request ModifyScalingConfigurationRequest
-      * @return ModifyScalingConfigurationResponse
+     * @summary Modifies a scaling configuration.
+     *
+     * @description You can change the name of a scaling configuration in a scaling group. The name must be unique within the scaling group.
+     *
+     * @param request ModifyScalingConfigurationRequest
+     * @return ModifyScalingConfigurationResponse
      */
     modifyScalingConfiguration(request: ModifyScalingConfigurationRequest): Promise<ModifyScalingConfigurationResponse>;
     /**
-      * *   You cannot call this operation to modify the settings of the following parameters:
-      *     *   RegionId
-      *     *   LoadBalancerId
-      *     > If you want to change the CLB instances that are associated with your scaling group, call the AttachLoadBalancers and DetachLoadBalancers operations.
-      *     *   DBInstanceId
-      *     > If you want to change the ApsaraDB RDS instances that are associated with your scaling group, call the AttachDBInstances and DetachDBInstances operations.
-      * *   You can modify only scaling groups that are in the Active or Inactive state.
-      * *   If you enable a new scaling configuration, Elastic Compute Service (ECS) instances that are created based on the previous scaling configuration still run as expected in the scaling group.
-      * *   If the total number of instances in the scaling group is greater than the allowed maximum number after you change the value of the MaxSize parameter, Auto Scaling automatically removes instances from the scaling group to ensure that the number of instances is within the new range.
-      * *   If the total number of instances in the scaling group is less than the allowed minimum number after you change the value of the MinSize parameter, Auto Scaling automatically adds instances to the scaling group to ensure that the number of instances is within the new range.
-      * *   If the total number of instances in the scaling group does not match the expected number of instances after you change the value of the DesiredCapacity parameter, Auto Scaling automatically adds instances to or removes instances from the scaling group to ensure that the number of instances matches the value of the DesiredCapacity parameter.
-      *
-      * @param request ModifyScalingGroupRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ModifyScalingGroupResponse
+     * @summary Modifies a scaling group.
+     *
+     * @description *   You cannot call this operation to modify the settings of the following parameters:
+     *     *   RegionId
+     *     *   LoadBalancerId
+     *     > If you want to change the CLB instances that are associated with your scaling group, call the AttachLoadBalancers and DetachLoadBalancers operations.
+     *     *   DBInstanceId
+     *     > If you want to change the ApsaraDB RDS instances that are associated with your scaling group, call the AttachDBInstances and DetachDBInstances operations.
+     * *   You can modify only scaling groups that are in the Active or Inactive state.
+     * *   If you enable a new scaling configuration, Elastic Compute Service (ECS) instances that are created based on the previous scaling configuration still run as expected in the scaling group.
+     * *   If the total number of instances in the scaling group is greater than the allowed maximum number after you change the value of the MaxSize parameter, Auto Scaling automatically removes instances from the scaling group to ensure that the number of instances is within the new range.
+     * *   If the total number of instances in the scaling group is less than the allowed minimum number after you change the value of the MinSize parameter, Auto Scaling automatically adds instances to the scaling group to ensure that the number of instances is within the new range.
+     * *   If the total number of instances in the scaling group does not match the expected number of instances after you change the value of the DesiredCapacity parameter, Auto Scaling automatically adds instances to or removes instances from the scaling group to ensure that the number of instances matches the value of the DesiredCapacity parameter.
+     *
+     * @param request ModifyScalingGroupRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyScalingGroupResponse
      */
     modifyScalingGroupWithOptions(request: ModifyScalingGroupRequest, runtime: $Util.RuntimeOptions): Promise<ModifyScalingGroupResponse>;
     /**
-      * *   You cannot call this operation to modify the settings of the following parameters:
-      *     *   RegionId
-      *     *   LoadBalancerId
-      *     > If you want to change the CLB instances that are associated with your scaling group, call the AttachLoadBalancers and DetachLoadBalancers operations.
-      *     *   DBInstanceId
-      *     > If you want to change the ApsaraDB RDS instances that are associated with your scaling group, call the AttachDBInstances and DetachDBInstances operations.
-      * *   You can modify only scaling groups that are in the Active or Inactive state.
-      * *   If you enable a new scaling configuration, Elastic Compute Service (ECS) instances that are created based on the previous scaling configuration still run as expected in the scaling group.
-      * *   If the total number of instances in the scaling group is greater than the allowed maximum number after you change the value of the MaxSize parameter, Auto Scaling automatically removes instances from the scaling group to ensure that the number of instances is within the new range.
-      * *   If the total number of instances in the scaling group is less than the allowed minimum number after you change the value of the MinSize parameter, Auto Scaling automatically adds instances to the scaling group to ensure that the number of instances is within the new range.
-      * *   If the total number of instances in the scaling group does not match the expected number of instances after you change the value of the DesiredCapacity parameter, Auto Scaling automatically adds instances to or removes instances from the scaling group to ensure that the number of instances matches the value of the DesiredCapacity parameter.
-      *
-      * @param request ModifyScalingGroupRequest
-      * @return ModifyScalingGroupResponse
+     * @summary Modifies a scaling group.
+     *
+     * @description *   You cannot call this operation to modify the settings of the following parameters:
+     *     *   RegionId
+     *     *   LoadBalancerId
+     *     > If you want to change the CLB instances that are associated with your scaling group, call the AttachLoadBalancers and DetachLoadBalancers operations.
+     *     *   DBInstanceId
+     *     > If you want to change the ApsaraDB RDS instances that are associated with your scaling group, call the AttachDBInstances and DetachDBInstances operations.
+     * *   You can modify only scaling groups that are in the Active or Inactive state.
+     * *   If you enable a new scaling configuration, Elastic Compute Service (ECS) instances that are created based on the previous scaling configuration still run as expected in the scaling group.
+     * *   If the total number of instances in the scaling group is greater than the allowed maximum number after you change the value of the MaxSize parameter, Auto Scaling automatically removes instances from the scaling group to ensure that the number of instances is within the new range.
+     * *   If the total number of instances in the scaling group is less than the allowed minimum number after you change the value of the MinSize parameter, Auto Scaling automatically adds instances to the scaling group to ensure that the number of instances is within the new range.
+     * *   If the total number of instances in the scaling group does not match the expected number of instances after you change the value of the DesiredCapacity parameter, Auto Scaling automatically adds instances to or removes instances from the scaling group to ensure that the number of instances matches the value of the DesiredCapacity parameter.
+     *
+     * @param request ModifyScalingGroupRequest
+     * @return ModifyScalingGroupResponse
      */
     modifyScalingGroup(request: ModifyScalingGroupRequest): Promise<ModifyScalingGroupResponse>;
+    /**
+     * @summary Modifies a scaling rule.
+     *
+     * @param request ModifyScalingRuleRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyScalingRuleResponse
+     */
     modifyScalingRuleWithOptions(request: ModifyScalingRuleRequest, runtime: $Util.RuntimeOptions): Promise<ModifyScalingRuleResponse>;
+    /**
+     * @summary Modifies a scaling rule.
+     *
+     * @param request ModifyScalingRuleRequest
+     * @return ModifyScalingRuleResponse
+     */
     modifyScalingRule(request: ModifyScalingRuleRequest): Promise<ModifyScalingRuleResponse>;
     /**
-      * You can use the following parameters to specify the scaling method of a scheduled task:
-      * *   If you use the `ScheduledAction` parameter, you must select an existing scaling rule for the scheduled task.
-      * *   If you use the `ScalingGroupId` parameter, you must specify the minimum number, maximum number, or expected number of instances in the scheduled task.
-      * > You cannot specify the `ScheduledAction` and `ScalingGroupId` parameters at the same time.
-      *
-      * @param request ModifyScheduledTaskRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ModifyScheduledTaskResponse
+     * @summary Modifies a scheduled task.
+     *
+     * @description You can use the following parameters to specify the scaling method of a scheduled task:
+     * *   If you use the `ScheduledAction` parameter, you must select an existing scaling rule for the scheduled task.
+     * *   If you use the `ScalingGroupId` parameter, you must specify the minimum number, maximum number, or expected number of instances in the scheduled task.
+     * > You cannot specify the `ScheduledAction` and `ScalingGroupId` parameters at the same time.
+     *
+     * @param request ModifyScheduledTaskRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ModifyScheduledTaskResponse
      */
     modifyScheduledTaskWithOptions(request: ModifyScheduledTaskRequest, runtime: $Util.RuntimeOptions): Promise<ModifyScheduledTaskResponse>;
     /**
-      * You can use the following parameters to specify the scaling method of a scheduled task:
-      * *   If you use the `ScheduledAction` parameter, you must select an existing scaling rule for the scheduled task.
-      * *   If you use the `ScalingGroupId` parameter, you must specify the minimum number, maximum number, or expected number of instances in the scheduled task.
-      * > You cannot specify the `ScheduledAction` and `ScalingGroupId` parameters at the same time.
-      *
-      * @param request ModifyScheduledTaskRequest
-      * @return ModifyScheduledTaskResponse
+     * @summary Modifies a scheduled task.
+     *
+     * @description You can use the following parameters to specify the scaling method of a scheduled task:
+     * *   If you use the `ScheduledAction` parameter, you must select an existing scaling rule for the scheduled task.
+     * *   If you use the `ScalingGroupId` parameter, you must specify the minimum number, maximum number, or expected number of instances in the scheduled task.
+     * > You cannot specify the `ScheduledAction` and `ScalingGroupId` parameters at the same time.
+     *
+     * @param request ModifyScheduledTaskRequest
+     * @return ModifyScheduledTaskResponse
      */
     modifyScheduledTask(request: ModifyScheduledTaskRequest): Promise<ModifyScheduledTaskResponse>;
+    /**
+     * @summary Rebalances the distribution of Elastic Compute Service (ECS) instances across zones. If ECS instances are unevenly distributed across multiple zones, you can call the RebalanceInstances operation to rebalance the distribution of the ECS instances across the zones.
+     *
+     * @description ## [](#)Usage notes
+     * Auto Scaling creates new ECS instances to replace the existing ECS instances to fulfill the rebalancing purpose. Auto Scaling starts the new ECS instances before stopping the existing ECS instances. The rebalancing operation does not affect the performance or service availability of your application.
+     * *   This operation is supported by only multi-zone scaling groups whose `MultiAZPolicy` is set to `BALANCE`.
+     * *   A rebalancing operation is required only when the distribution of the instances of a multi-zone scaling group is significantly unbalanced. In a rebalancing activity, Auto Scaling replaces up to 20 ECS instances to rectify the unbalanced distribution.
+     * *   During the execution of a rebalancing operation, if the number of instances in the scaling group approaches or hits the value of MaxSize but the rebalancing operation needs to continue, Auto Scaling allows the total number of ECS instances to momentarily exceed the value of MaxSize by 10%. This temporary surplus condition persists for a duration until equilibrium in the distribution of ECS instances is achieved. Typically, it takes 1 to 6 minutes.
+     *     **
+     *     **Note** If the 10% increment of the maximum number of instances in a scaling group yield a non-integer value, the decimal portion is always rounded up to ensure an additional instance is accounted for. For example, you have a scaling group that holds a maximum of 15 ECS instances. During a rebalancing operation, Auto Scaling would permit the total number of instances to momentarily surpass this limit by 2, instead of the calculated 10% (which is 1.5).
+     *
+     * @param request RebalanceInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return RebalanceInstancesResponse
+     */
     rebalanceInstancesWithOptions(request: RebalanceInstancesRequest, runtime: $Util.RuntimeOptions): Promise<RebalanceInstancesResponse>;
+    /**
+     * @summary Rebalances the distribution of Elastic Compute Service (ECS) instances across zones. If ECS instances are unevenly distributed across multiple zones, you can call the RebalanceInstances operation to rebalance the distribution of the ECS instances across the zones.
+     *
+     * @description ## [](#)Usage notes
+     * Auto Scaling creates new ECS instances to replace the existing ECS instances to fulfill the rebalancing purpose. Auto Scaling starts the new ECS instances before stopping the existing ECS instances. The rebalancing operation does not affect the performance or service availability of your application.
+     * *   This operation is supported by only multi-zone scaling groups whose `MultiAZPolicy` is set to `BALANCE`.
+     * *   A rebalancing operation is required only when the distribution of the instances of a multi-zone scaling group is significantly unbalanced. In a rebalancing activity, Auto Scaling replaces up to 20 ECS instances to rectify the unbalanced distribution.
+     * *   During the execution of a rebalancing operation, if the number of instances in the scaling group approaches or hits the value of MaxSize but the rebalancing operation needs to continue, Auto Scaling allows the total number of ECS instances to momentarily exceed the value of MaxSize by 10%. This temporary surplus condition persists for a duration until equilibrium in the distribution of ECS instances is achieved. Typically, it takes 1 to 6 minutes.
+     *     **
+     *     **Note** If the 10% increment of the maximum number of instances in a scaling group yield a non-integer value, the decimal portion is always rounded up to ensure an additional instance is accounted for. For example, you have a scaling group that holds a maximum of 15 ECS instances. During a rebalancing operation, Auto Scaling would permit the total number of instances to momentarily surpass this limit by 2, instead of the calculated 10% (which is 1.5).
+     *
+     * @param request RebalanceInstancesRequest
+     * @return RebalanceInstancesResponse
+     */
     rebalanceInstances(request: RebalanceInstancesRequest): Promise<RebalanceInstancesResponse>;
     /**
-      * You can call this operation to prolong the length of a lifecycle hook up to 20 times. Take note that the total length of a lifecycle hook cannot exceed 6 hours.
-      *
-      * @param request RecordLifecycleActionHeartbeatRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return RecordLifecycleActionHeartbeatResponse
+     * @summary Prolongs a lifecycle hook for Elastic Compute Service (ECS) instances.
+     *
+     * @description You can call this operation to prolong the length of a lifecycle hook up to 20 times. Take note that the total length of a lifecycle hook cannot exceed 6 hours.
+     *
+     * @param request RecordLifecycleActionHeartbeatRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return RecordLifecycleActionHeartbeatResponse
      */
     recordLifecycleActionHeartbeatWithOptions(request: RecordLifecycleActionHeartbeatRequest, runtime: $Util.RuntimeOptions): Promise<RecordLifecycleActionHeartbeatResponse>;
     /**
-      * You can call this operation to prolong the length of a lifecycle hook up to 20 times. Take note that the total length of a lifecycle hook cannot exceed 6 hours.
-      *
-      * @param request RecordLifecycleActionHeartbeatRequest
-      * @return RecordLifecycleActionHeartbeatResponse
+     * @summary Prolongs a lifecycle hook for Elastic Compute Service (ECS) instances.
+     *
+     * @description You can call this operation to prolong the length of a lifecycle hook up to 20 times. Take note that the total length of a lifecycle hook cannot exceed 6 hours.
+     *
+     * @param request RecordLifecycleActionHeartbeatRequest
+     * @return RecordLifecycleActionHeartbeatResponse
      */
     recordLifecycleActionHeartbeat(request: RecordLifecycleActionHeartbeatRequest): Promise<RecordLifecycleActionHeartbeatResponse>;
     /**
-      * *   Before you call this operation, make sure that the following requirements are met:
-      *     *   The scaling group is in the Active state.
-      *     *   No scaling activity is in progress within the scaling group.
-      * > If no scaling activity is in progress within the scaling group, you can call the operation even within the cooldown period.
-      * *   If an ECS instance is automatically created by Auto Scaling, or if an ECS instance is manually added to a scaling group and managed by the scaling group, the ECS instance is stopped in economical mode or is released after the instance is removed from the scaling group.
-      * *   If an ECS instance is manually added to a scaling group and is not managed by the scaling group, the ECS instance is not stopped or released after the instance is removed from the scaling group.
-      * *   If the difference between the number of existing ECS instances specified by the TotalCapacity parameter and the number of ECS instances that you call this operation to remove is less than the value of the MinSize parameter, the call fails.
-      * A successful call only means that Auto Scaling accepts the request. The scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
-      *
-      * @param request RemoveInstancesRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return RemoveInstancesResponse
+     * @summary Removes one or more Elastic Compute Service (ECS) instances or elastic container instances from a scaling group.
+     *
+     * @description *   Before you call this operation, make sure that the following requirements are met:
+     *     *   The scaling group is in the Active state.
+     *     *   No scaling activity is in progress within the scaling group.
+     * > If no scaling activity is in progress within the scaling group, you can call the operation even within the cooldown period.
+     * *   If an ECS instance is automatically created by Auto Scaling, or if an ECS instance is manually added to a scaling group and managed by the scaling group, the ECS instance is stopped in economical mode or is released after the instance is removed from the scaling group.
+     * *   If an ECS instance is manually added to a scaling group and is not managed by the scaling group, the ECS instance is not stopped or released after the instance is removed from the scaling group.
+     * *   If the difference between the number of existing ECS instances specified by the TotalCapacity parameter and the number of ECS instances that you call this operation to remove is less than the value of the MinSize parameter, the call fails.
+     * A successful call only means that Auto Scaling accepts the request. The scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
+     *
+     * @param request RemoveInstancesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return RemoveInstancesResponse
      */
     removeInstancesWithOptions(request: RemoveInstancesRequest, runtime: $Util.RuntimeOptions): Promise<RemoveInstancesResponse>;
     /**
-      * *   Before you call this operation, make sure that the following requirements are met:
-      *     *   The scaling group is in the Active state.
-      *     *   No scaling activity is in progress within the scaling group.
-      * > If no scaling activity is in progress within the scaling group, you can call the operation even within the cooldown period.
-      * *   If an ECS instance is automatically created by Auto Scaling, or if an ECS instance is manually added to a scaling group and managed by the scaling group, the ECS instance is stopped in economical mode or is released after the instance is removed from the scaling group.
-      * *   If an ECS instance is manually added to a scaling group and is not managed by the scaling group, the ECS instance is not stopped or released after the instance is removed from the scaling group.
-      * *   If the difference between the number of existing ECS instances specified by the TotalCapacity parameter and the number of ECS instances that you call this operation to remove is less than the value of the MinSize parameter, the call fails.
-      * A successful call only means that Auto Scaling accepts the request. The scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
-      *
-      * @param request RemoveInstancesRequest
-      * @return RemoveInstancesResponse
+     * @summary Removes one or more Elastic Compute Service (ECS) instances or elastic container instances from a scaling group.
+     *
+     * @description *   Before you call this operation, make sure that the following requirements are met:
+     *     *   The scaling group is in the Active state.
+     *     *   No scaling activity is in progress within the scaling group.
+     * > If no scaling activity is in progress within the scaling group, you can call the operation even within the cooldown period.
+     * *   If an ECS instance is automatically created by Auto Scaling, or if an ECS instance is manually added to a scaling group and managed by the scaling group, the ECS instance is stopped in economical mode or is released after the instance is removed from the scaling group.
+     * *   If an ECS instance is manually added to a scaling group and is not managed by the scaling group, the ECS instance is not stopped or released after the instance is removed from the scaling group.
+     * *   If the difference between the number of existing ECS instances specified by the TotalCapacity parameter and the number of ECS instances that you call this operation to remove is less than the value of the MinSize parameter, the call fails.
+     * A successful call only means that Auto Scaling accepts the request. The scaling activity may still fail. You can obtain the status of a scaling activity based on the value of the ScalingActivityId parameter in the response.
+     *
+     * @param request RemoveInstancesRequest
+     * @return RemoveInstancesResponse
      */
     removeInstances(request: RemoveInstancesRequest): Promise<RemoveInstancesResponse>;
+    /**
+     * @summary Resumes suspended processes in a scaling group.
+     *
+     * @param request ResumeProcessesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ResumeProcessesResponse
+     */
     resumeProcessesWithOptions(request: ResumeProcessesRequest, runtime: $Util.RuntimeOptions): Promise<ResumeProcessesResponse>;
+    /**
+     * @summary Resumes suspended processes in a scaling group.
+     *
+     * @param request ResumeProcessesRequest
+     * @return ResumeProcessesResponse
+     */
     resumeProcesses(request: ResumeProcessesRequest): Promise<ResumeProcessesResponse>;
     /**
-      * Compared with the ExecuteScalingRule operation, the ScaleWithAdjustment operation does not require a scaling rule to be created in advance. Before you call the ScaleWithAdjustment operation, take note of the following items:
-      * *   The following conditions must be met:
-      *     *   The scaling group is in the Active state.
-      *     *   No scaling activities in the scaling group are in progress.
-      * *   If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * *   If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
-      * *   If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
-      * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the `ScalingActivityId` parameter in the response.
-      *
-      * @param tmpReq ScaleWithAdjustmentRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return ScaleWithAdjustmentResponse
+     * @summary Scales instances in a scaling group based on the specified scaling policy.
+     *
+     * @description Compared with the ExecuteScalingRule operation, the ScaleWithAdjustment operation does not require a scaling rule to be created in advance. Before you call the ScaleWithAdjustment operation, take note of the following items:
+     * *   The following conditions must be met:
+     *     *   The scaling group is in the Active state.
+     *     *   No scaling activities in the scaling group are in progress.
+     * *   If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * *   If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
+     * *   If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
+     * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the `ScalingActivityId` parameter in the response.
+     *
+     * @param tmpReq ScaleWithAdjustmentRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return ScaleWithAdjustmentResponse
      */
     scaleWithAdjustmentWithOptions(tmpReq: ScaleWithAdjustmentRequest, runtime: $Util.RuntimeOptions): Promise<ScaleWithAdjustmentResponse>;
     /**
-      * Compared with the ExecuteScalingRule operation, the ScaleWithAdjustment operation does not require a scaling rule to be created in advance. Before you call the ScaleWithAdjustment operation, take note of the following items:
-      * *   The following conditions must be met:
-      *     *   The scaling group is in the Active state.
-      *     *   No scaling activities in the scaling group are in progress.
-      * *   If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
-      * *   If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
-      * *   If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
-      * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the `ScalingActivityId` parameter in the response.
-      *
-      * @param request ScaleWithAdjustmentRequest
-      * @return ScaleWithAdjustmentResponse
+     * @summary Scales instances in a scaling group based on the specified scaling policy.
+     *
+     * @description Compared with the ExecuteScalingRule operation, the ScaleWithAdjustment operation does not require a scaling rule to be created in advance. Before you call the ScaleWithAdjustment operation, take note of the following items:
+     * *   The following conditions must be met:
+     *     *   The scaling group is in the Active state.
+     *     *   No scaling activities in the scaling group are in progress.
+     * *   If no scaling activities in the scaling group are in progress, the operation can trigger scaling activities even before the cooldown time expires.
+     * *   If the addition of a specified number of Elastic Compute Service (ECS) instances to a scaling group causes the total number of ECS instances in the scaling group to exceed the maximum number of instances allowed, Auto Scaling adds only a specific number of ECS instances to ensure that the total number of instances is equal to the maximum number of instances.
+     * *   If the removal of a specified number of ECS instances from a scaling group causes the total number of ECS instances in the scaling group to drop below the minimum number of instances allowed, Auto Scaling removes only a specific number of ECS instances to ensure that the total number of instances is equal to the minimum number of instances.
+     * A successful call indicates that Auto Scaling accepts the request. However, the scaling activity may still fail. You can obtain the status of a scaling activity by using the value of the `ScalingActivityId` parameter in the response.
+     *
+     * @param request ScaleWithAdjustmentRequest
+     * @return ScaleWithAdjustmentResponse
      */
     scaleWithAdjustment(request: ScaleWithAdjustmentRequest): Promise<ScaleWithAdjustmentResponse>;
+    /**
+     * @summary Sets deletion protection for a scaling group. If you enable deletion protection for a scaling group, you cannot delete the scaling group. If you disable deletion protection for a scaling group, you can directly delete the scaling group. You can call the SetGroupDeletionProtection operation to enable or disable deletion protection.
+     *
+     * @param request SetGroupDeletionProtectionRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return SetGroupDeletionProtectionResponse
+     */
     setGroupDeletionProtectionWithOptions(request: SetGroupDeletionProtectionRequest, runtime: $Util.RuntimeOptions): Promise<SetGroupDeletionProtectionResponse>;
+    /**
+     * @summary Sets deletion protection for a scaling group. If you enable deletion protection for a scaling group, you cannot delete the scaling group. If you disable deletion protection for a scaling group, you can directly delete the scaling group. You can call the SetGroupDeletionProtection operation to enable or disable deletion protection.
+     *
+     * @param request SetGroupDeletionProtectionRequest
+     * @return SetGroupDeletionProtectionResponse
+     */
     setGroupDeletionProtection(request: SetGroupDeletionProtectionRequest): Promise<SetGroupDeletionProtectionResponse>;
     /**
-      * Configures the health check feature for Elastic Compute Service (ECS) instances.
-      *
-      * @param request SetInstanceHealthRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return SetInstanceHealthResponse
+     * @summary Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\&M hurdles efficiently.
+     *
+     * @description Auto Scaling detects and removes unhealthy ECS instances or elastic container instances from the corresponding scaling groups. If you want to retain a specific instance in the corresponding scaling group, you can put the instance into the Standby or Protected state. For more information, see [EnterStandby](~~EnterStandby~~) and [SetInstancesProtection](~~SetInstancesProtection~~).
+     *
+     * @param request SetInstanceHealthRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return SetInstanceHealthResponse
      */
     setInstanceHealthWithOptions(request: SetInstanceHealthRequest, runtime: $Util.RuntimeOptions): Promise<SetInstanceHealthResponse>;
     /**
-      * Configures the health check feature for Elastic Compute Service (ECS) instances.
-      *
-      * @param request SetInstanceHealthRequest
-      * @return SetInstanceHealthResponse
+     * @summary Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\&M hurdles efficiently.
+     *
+     * @description Auto Scaling detects and removes unhealthy ECS instances or elastic container instances from the corresponding scaling groups. If you want to retain a specific instance in the corresponding scaling group, you can put the instance into the Standby or Protected state. For more information, see [EnterStandby](~~EnterStandby~~) and [SetInstancesProtection](~~SetInstancesProtection~~).
+     *
+     * @param request SetInstanceHealthRequest
+     * @return SetInstanceHealthResponse
      */
     setInstanceHealth(request: SetInstanceHealthRequest): Promise<SetInstanceHealthResponse>;
     /**
-      * Puts one or more Elastic Compute Service (ECS) instances into the Protected state.
-      *
-      * @param request SetInstancesProtectionRequest
-      * @param runtime runtime options for this request RuntimeOptions
-      * @return SetInstancesProtectionResponse
+     * @summary Puts Elastic Compute Service (ECS) instances into the Protected state. When ECS instances are put into the Protected state, they become immune to manual deletion attempts by using the Auto Scaling console or API operations. This operation serves as a robust safeguard, efficiently preventing any inadvertent instance release that could lead to irreversible consequences.
+     *
+     * @description Once ECS instances enter the Protected state, they become subject to the following restrictions:
+     * *   ECS instances will persist in the Protected state, unless you deliberately remove them from this state.
+     * *   Even in scenarios where automatic scale-in actions are initiated due to fluctuations in the number of ECS instances or the execution of event-triggered tasks, Auto Scaling does not remove ECS instances that are in the Protected state from their respective scaling groups. Only after being manually removed from their respective scaling groups can ECS instances that are in the Protected state be released. For more information, see [Remove an ECS instance](https://help.aliyun.com/document_detail/25955.html).
+     * *   ECS instances in the Protected state maintain their existing health status even when they undergo stopping or restarting processes.
+     *
+     * @param request SetInstancesProtectionRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return SetInstancesProtectionResponse
      */
     setInstancesProtectionWithOptions(request: SetInstancesProtectionRequest, runtime: $Util.RuntimeOptions): Promise<SetInstancesProtectionResponse>;
     /**
-      * Puts one or more Elastic Compute Service (ECS) instances into the Protected state.
-      *
-      * @param request SetInstancesProtectionRequest
-      * @return SetInstancesProtectionResponse
+     * @summary Puts Elastic Compute Service (ECS) instances into the Protected state. When ECS instances are put into the Protected state, they become immune to manual deletion attempts by using the Auto Scaling console or API operations. This operation serves as a robust safeguard, efficiently preventing any inadvertent instance release that could lead to irreversible consequences.
+     *
+     * @description Once ECS instances enter the Protected state, they become subject to the following restrictions:
+     * *   ECS instances will persist in the Protected state, unless you deliberately remove them from this state.
+     * *   Even in scenarios where automatic scale-in actions are initiated due to fluctuations in the number of ECS instances or the execution of event-triggered tasks, Auto Scaling does not remove ECS instances that are in the Protected state from their respective scaling groups. Only after being manually removed from their respective scaling groups can ECS instances that are in the Protected state be released. For more information, see [Remove an ECS instance](https://help.aliyun.com/document_detail/25955.html).
+     * *   ECS instances in the Protected state maintain their existing health status even when they undergo stopping or restarting processes.
+     *
+     * @param request SetInstancesProtectionRequest
+     * @return SetInstancesProtectionResponse
      */
     setInstancesProtection(request: SetInstancesProtectionRequest): Promise<SetInstancesProtectionResponse>;
+    /**
+     * @summary Suspends scaling processes. This operation empowers you to selectively pause distinct scaling processes within a particular scaling group, enabling you to carry out alternative tasks and achieve more granular management over your scaling operations.
+     *
+     * @param request SuspendProcessesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return SuspendProcessesResponse
+     */
     suspendProcessesWithOptions(request: SuspendProcessesRequest, runtime: $Util.RuntimeOptions): Promise<SuspendProcessesResponse>;
+    /**
+     * @summary Suspends scaling processes. This operation empowers you to selectively pause distinct scaling processes within a particular scaling group, enabling you to carry out alternative tasks and achieve more granular management over your scaling operations.
+     *
+     * @param request SuspendProcessesRequest
+     * @return SuspendProcessesResponse
+     */
     suspendProcesses(request: SuspendProcessesRequest): Promise<SuspendProcessesResponse>;
+    /**
+     * @summary Adds tags to specified Auto Scaling resources.
+     *
+     * @param request TagResourcesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return TagResourcesResponse
+     */
     tagResourcesWithOptions(request: TagResourcesRequest, runtime: $Util.RuntimeOptions): Promise<TagResourcesResponse>;
+    /**
+     * @summary Adds tags to specified Auto Scaling resources.
+     *
+     * @param request TagResourcesRequest
+     * @return TagResourcesResponse
+     */
     tagResources(request: TagResourcesRequest): Promise<TagResourcesResponse>;
+    /**
+     * @summary Removes tags from Auto Scaling resources simultaneously. This operation streamlines resource management activities, enhances system efficiency, and mitigates potential security vulnerabilities. Once a tag is removed from a particular resource, and if it is not re-added to any other resource, the system will automatically delete the unused tag.
+     *
+     * @param request UntagResourcesRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return UntagResourcesResponse
+     */
     untagResourcesWithOptions(request: UntagResourcesRequest, runtime: $Util.RuntimeOptions): Promise<UntagResourcesResponse>;
+    /**
+     * @summary Removes tags from Auto Scaling resources simultaneously. This operation streamlines resource management activities, enhances system efficiency, and mitigates potential security vulnerabilities. Once a tag is removed from a particular resource, and if it is not re-added to any other resource, the system will automatically delete the unused tag.
+     *
+     * @param request UntagResourcesRequest
+     * @return UntagResourcesResponse
+     */
     untagResources(request: UntagResourcesRequest): Promise<UntagResourcesResponse>;
+    /**
+     * @summary Checks whether Auto Scaling is authorized to access Elastic Compute Service (ECS) and Elastic Container Instance resources.
+     *
+     * @param request VerifyAuthenticationRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return VerifyAuthenticationResponse
+     */
     verifyAuthenticationWithOptions(request: VerifyAuthenticationRequest, runtime: $Util.RuntimeOptions): Promise<VerifyAuthenticationResponse>;
+    /**
+     * @summary Checks whether Auto Scaling is authorized to access Elastic Compute Service (ECS) and Elastic Container Instance resources.
+     *
+     * @param request VerifyAuthenticationRequest
+     * @return VerifyAuthenticationResponse
+     */
     verifyAuthentication(request: VerifyAuthenticationRequest): Promise<VerifyAuthenticationResponse>;
+    /**
+     * @summary Verifies whether Auto Scaling is activated. This operation guarantees that in response to shifts in business workloads or variations in incoming traffic, the system will automatically adjust resource provisioning. This auto-scaling capability enhances the overall system performance, ensuring high availability and improved flexibility to accommodate dynamic demands.
+     *
+     * @param request VerifyUserRequest
+     * @param runtime runtime options for this request RuntimeOptions
+     * @return VerifyUserResponse
+     */
     verifyUserWithOptions(request: VerifyUserRequest, runtime: $Util.RuntimeOptions): Promise<VerifyUserResponse>;
+    /**
+     * @summary Verifies whether Auto Scaling is activated. This operation guarantees that in response to shifts in business workloads or variations in incoming traffic, the system will automatically adjust resource provisioning. This auto-scaling capability enhances the overall system performance, ensuring high availability and improved flexibility to accommodate dynamic demands.
+     *
+     * @param request VerifyUserRequest
+     * @return VerifyUserResponse
+     */
     verifyUser(request: VerifyUserRequest): Promise<VerifyUserResponse>;
 }