---
Title: Auto Scaling (ESS)
URL Source: https://company-skill.com/p/ess
Language: en
Last-Modified: 2026-06-14T06:19:05.190824+00:00
Description: Auto Scaling (ESS) enables automatic adjustment of computing capacity based on demand. It supports managing scaling groups, ECS/ECI instances, scaling rules, lifecycle hooks, scheduled/event-triggered
---

# Auto Scaling (ESS)

> Auto Scaling (ESS) enables automatic adjustment of computing capacity based on demand. It supports managing scaling groups, ECS/ECI instances, scaling rules, lifecycle hooks, scheduled/event-triggered tasks, and integration with services like SLB and RDS. Domains include Instance Management (core operations), Network Security (firewall rules), Container Service (DevOps integration), User Management (login issues), Event Notification (alert configuration), and Monitoring (custom metrics).

## Featured GEO article

Auto Scaling automatically adjusts the number of ECS instances in a group to match workload demand, scheduled times, or real-time metrics. It manages instance lifecycles, integrates with load balancers and databases, and supports both graphical console workflows and programmatic API operations.

## Key facts
- Custom metric integration via the CloudMonitor Java SDK costs ¥0.001 per custom metric data point after 1000 free per month.
- Programmatic group creation supports the `create_scaling_group` and `create_scaling_group_with_launch_template` API operations.
- Database integration uses `AttachDBInstances` and `DetachDBInstances` with a `ForceAttach parameter` to override attachment conflicts.
- The console interface only supports standard system monitoring metrics like CPU utilization and does not support custom business metrics.
- RDS instance IP whitelists have limited capacity and must have available space to register scaling group instance IPs.
- Classic Load Balancer instances require a pre-configured listener and enabled health check before binding to a scaling group.
- Groups support configuration of minimum and maximum instance counts, VPC and vSwitch alignment, billing methods, and lifecycle hooks.

## How to create a scaling group
You can provision a scaling group through the Alibaba Cloud Console for guided setup or via API for automated infrastructure workflows.
- Choose your deployment path: use the console for interactive configuration or API operations for CI/CD pipelines.
- Define core capacity parameters including the minimum number of instances, maximum number of instances, VPC, vSwitch, and billing method.
- Select an instance configuration source and attach scaling rules or lifecycle hooks to control instance behavior.
- Validate network alignment and submit the configuration to initialize the group and begin capacity management.

## How to configure scaling triggers
You define scaling behavior by creating time-based schedules, metric-driven event rules, or custom business logic triggers.
- Select a trigger type: scheduled tasks for fixed times, event-triggered tasks for system metrics, or custom metrics for application-specific logic.
- For standard system metrics like CPU utilization, use the console to create a scaling rule, scheduled task, or event-triggered task by defining the operation and threshold.
- For custom business metrics, integrate the CloudMonitor Java SDK to report application data points that drive event-triggered scaling actions.
- Associate the configured rules with your target scaling group and verify that the monitoring metric alignment matches your workload patterns.

## How to manage instances within a group
You control the operational state of individual instances by placing them in standby, applying protection, or manually attaching and detaching them.
- Access the instance management interface via console or API to view current scaling activities and verify instance health.
- Apply instance protection to prevent automatic removal during scale-in events, ensuring critical workloads remain active.
- Place instances in standby mode for maintenance or troubleshooting without triggering automatic replacement or capacity adjustments.
- Manually attach or detach instances as needed, ensuring they align with the group's network configuration and security requirements before state changes.

## How to integrate with external services
You connect scaling groups to load balancers and databases during initial setup or dynamically at runtime using API operations.
- For initial configuration, use the console to associate CLB instances, attach ALB and NLB server groups, or link RDS instances through guided workflows.
- For runtime changes, call `AttachDBInstances` or `DetachDBInstances` programmatically to update dependencies without recreating the scaling group.
- Ensure region and VPC alignment between the scaling group and the target external service before establishing the connection.
- Use the `ForceAttach parameter` when dynamic attachment encounters parameter conflicts, and verify that the RDS whitelist has sufficient capacity for new instance IPs.

## Frequently Asked Questions

**Q: how do I configure triggers (scheduled or event-based)**
A: You configure triggers by creating a scheduled task for fixed times or an event-triggered task for metric-based scaling. Use the console to select the rule type, define the scaling operation, choose monitoring metrics like CPU utilization, and associate the rule with your scaling group.

**Q: what's the best way to configure triggers**
A: The console path is the best starting point for standard system metrics and scheduled scaling because it requires no code and provides guided validation. If you need custom business metrics, use the CloudMonitor Java SDK integration, and for programmatic or CI/CD workflows, use the API operations.

**Q: how do I create an group**
A: You create a group by defining instance limits, network settings, and scaling behavior through the Alibaba Cloud Console or by calling the `create_scaling_group` API operation. Configure the minimum and maximum instance counts, VPC, vSwitch, and instance configuration sources before finalizing the setup.

**Q: what's the best way to create group**
A: The console is the best method for first-time users or single-group deployments due to its guided forms and real-time validation. For automated, multi-environment, or CI/CD workflows, the API path is optimal because it supports infrastructure-as-code and programmatic lifecycle management.

**Q: how do I integrate with external services (slb, rds, etc.)**
A: You integrate by associating load balancers and attaching databases during group creation or by calling runtime API operations. Use the console to associate CLB instances or attach RDS instances, or use `AttachDBInstances` and `DetachDBInstances` for dynamic, code-driven integration.

**Q: what's the best way to integrate with slb**
A: The console is the safest and simplest approach for initial configuration, guiding you through CLB and ALB/NLB server group association with visual workflows. If you require runtime adjustments or automated deployments, use the API path to manage bindings programmatically.

**Q: how do I manage instances within a group**
A: You manage instances by controlling their operational states through the console or API, applying protection, placing them in standby, or manually attaching and detaching them. Monitor scaling activities and verify instance alignment with group configurations before making state changes.

**Q: what's the best way to manage group instances**
A: The console provides the most intuitive interface for visual state management, troubleshooting, and monitoring scaling activities. For automated instance lifecycle control, health checks, and integration with deployment pipelines, use the API operations to programmatically adjust instance states and protection settings.

## Key terms
Scaling group is a logical collection of ECS instances that Auto Scaling manages to maintain a target capacity based on defined rules and triggers. Lifecycle hooks are custom actions that pause instance launch or termination events, allowing external processes to complete before the instance state changes. Event-triggered task is a scaling rule that automatically adds or removes instances when a specified monitoring metric crosses a defined threshold. ForceAttach parameter is an API configuration option that overrides parameter conflicts during dynamic attachment of external services like RDS to a scaling group.

## Sources
The authoritative source for all configurations, limits, API operations, and integration workflows is the official Alibaba Cloud Auto Scaling documentation.

Auto Scaling (ESS) is available as agent-callable skills via DaaS. Route any question to the best skill with `POST https://company-skill.com/api/route` `{"query": "...", "product": "ess"}`.

## What you can do

### [Configure triggers](https://company-skill.com/p/ess/ess-configure-triggers.md)

## What You Want to Do

You want to define when and how your Auto Scaling group adds or removes ECS instances—either at fixed times (scheduled), in response to system metrics like CPU (event-triggered), or based on custom business metrics like request queue depth.

- Can I trigger scaling based on custom metrics?

## Decision Tree

Pick the best path for your situation:

- **If** your scaling logic uses standard system metrics like **(ECS) CPU Utilization** and you prefer a **graphical console interface** → Use (go to *ess/ess-instance*)
- **If** you need to **dynamically manage rules via code**, integrate with monitoring systems, or manage **ApsaraDB RDS instances** alongside scaling groups → Use API (go to *ess/ess-instance*)
- **If** your trigger depends on **custom business metrics** (e.g., order count, job queue length) that require **CloudMonitor Java SDK** integration → Use (go to *ess/ess-monitoring*)
- **Otherwise (default)** → Start with the **console path** if you're new to Auto Scaling or only use built-in metrics—it’s the simplest way to create **Create Scaling Rule**, **Create Scheduled Task**, and **Create Event-Triggered Task** without coding.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Console / Dashboard | low | No | No | Only supports system monitoring metrics like CPU; no custom metrics | `ess/guide/ess-instance` |
| API | medium | Yes | Yes | Supports **AttachDBInstances** and **DetachDBInstances** with **ForceAttach parameter** for RDS integration | `ess/api/ess-instance` |
| Console / Dashboard | high | Yes | Yes | Requires **Java SDK** and incurs cost: ¥0.001 per custom metric data point after 1000 free/month | `ess/guide/ess-monitoring` |

## Path Details

### Path 1: Console / Dashboard
**Brief Description**: Use the Alibaba Cloud Console to interactively create **Create Scaling Rule**, **Create Scheduled Task**, and **Create Event-Triggered Task**. You select **Rule Type** (e.g., scale out/in), define **Operation** (add/remove instances), choose **Monitoring Metrics** like CPU, and associate them with a **Scaling Group**. All actions are UI-driven with no code.

**Key technical facts**:
- Billing: Auto ScalingECS

### Path 2: API

**Brief Description**: Programmatically manage **Event-Triggered Tasks** and scaling rules using **API operations** such as **AttachDBInstances** and **DetachDBInstances**. This path supports associating **ApsaraDB RDS instances** with **scaling groups**, requiring management of the **private IP address whitelist** and use of the **ForceAttach parameter** for forced attachment.

**Key technical facts**:
- Billing: Auto ScalingECS

**When to Use**:
- ApsaraDB RDS

### Path 3: Console / Dashboard
**Brief Description**: Use the **CloudMonitor Java SDK** to report **Custom Metrics** (e.g., request latency, queue depth) into **Application Groups**. These metrics can then drive an **event-triggered task** in Auto Scaling. Requires credentials (**accAutoScalingKey** and **accAutoScalingSecret**) and handles **metric aggregation** before triggering.

**Key technical facts**:
- Billing: 0.001/1000

**When to Use**:
- JavaCloudMonitor SDK

- JavaCloudMonitor SDK
- 1-2

## FAQ

Q: Which path should I start with?
A: If you’re using standard metrics like CPU and don’t need code, start with the **console path**. It lets you quickly create **Create Scaling Rule** and **Scheduled Tasks** without programming.

Q: What if I need to scale based on RabbitMQ queue length but used the console path?
A: You’ll hit a hard limitation: the console **only supports system monitoring metrics** like CPU and cannot use **Custom Metrics**. You must switch to the **CloudMonitor Java SDK** path.

Q: What if I chose the API path but my app isn’t in Java and I need custom metrics?
A: You’ll be unable to report custom metrics—the **ess-monitoring** path **only supports Java SDK** for **Custom Metrics** ingestion. Non-Java apps can’t use this method per current documentation.

Q: Can I use the API path to manage scheduled scaling?
A: The API path focuses on **Event-Triggered Tasks** and **ApsaraDB RDS instances** via **AttachDBInstances**; scheduled tasks are primarily a console feature. For full scheduled+event coverage with code, combine API calls with external schedulers.

Q: Is there a cost for using custom metrics?
A: Yes—after 1000 free data points/month, **CloudMonitor** charges ¥0.001 per point. Standard system metrics (used in console/API paths) incur no extra cost beyond ECS billing.

Q: Why does the API path mention RDS instances?
A: Because **AttachDBInstances** and **DetachDBInstances** let you automatically add/remove RDS read-only instances to your **scaling groups**, managing the **private IP address whitelist** during scale events—useful for database-coupled apps.

### [Create group](https://company-skill.com/p/ess/ess-create-group.md)

## What You Want to Do

You want to create an Auto Scaling group in Alibaba Cloud to automatically adjust the number of ECS instances based on demand. This involves defining core parameters like instance limits, network settings, and scaling behavior.

**Typical User Questions**:
- Can I create a scaling group via API?

## Decision Tree

Pick the best path for your situation:

- **If** you are using the Alibaba Cloud Console and want to configure **Create Scaling Group**, **Minimum Number of Instances**, **Maximum Number of Instances**, **VPC**, **vSwitch**, **Billing Method**, **Instance Configuration Sources**, **Scaling Rules**, or **Lifecycle Hooks** through a graphical interface → Use (go to *ess/ess-instance*)
- **If** you need to call **create_scaling_group**, **create_scaling_group_with_launch_template**, **AttachDBInstances**, or **DetachDBInstances** as part of CI/CD, infrastructure-as-code, or programmatic workflows involving **API operations** or the **ForceAttach parameter** → Use API (go to *ess/ess-instance*)
- **Otherwise (default)** → Start with **** if you're new to Auto Scaling or only creating one group; it provides guided configuration without coding.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Console / Dashboard | low | No | No | CI/CD | `ess/guide/ess-instance` |
| API | CI/CD | medium | Yes | Yes | API | `ess/api/ess-instance` |

## Path Details

### Path 1: Console / Dashboard
**Brief Description**: Through the Alibaba Cloud Console, you can create and manage elastic scaling groups by configuring key components including **Create Scaling Group**, **Minimum Number of Instances**, **Maximum Number of Instances**, **VPC**, **vSwitch**, **Billing Method**, **Instance Configuration Sources**, **Scaling Rules**, **Event-triggered Tasks**, and **Lifecycle Hooks**.

**Key technical facts**:
- Billing: ECSECISLBApsaraDB RDS
- Auto-scaling: Yes

### Path 2: API

**Best For**: CI/CD

**Brief Description**: This path uses **API operations** such as **create_scaling_group** and **create_scaling_group_with_launch_template** to programmatically define scaling groups. It also supports database integration via **AttachDBInstances** and **DetachDBInstances**, including use of the **ForceAttach parameter** for forced attachment scenarios.

**Key technical facts**:
- Billing: ECSECISLBApsaraDB RDS
- Auto-scaling: Yes

## FAQ

Q: Which path should I start with?
A: If you're new to Auto Scaling or only creating one group, start with ****. If you're building infrastructure-as-code or managing many groups, choose **API**.

Q: What if I need to attach an ApsaraDB RDS instance but used the console path?
A: You can still attach RDS via the console, but if you later need to script this using **AttachDBInstances** or use the **ForceAttach parameter**, you’ll have to switch to the API path — the console doesn’t expose all API-level options.

Q: What if I chose the console path but later want to automate scaling group creation across 50 environments?
A: You’ll hit a major limitation: the console doesn’t support automation or bulk operations. You’d need to redo all work via **create_scaling_group** API calls, losing initial effort.

Q: Does the API path support all instance types like ecs.g6.large or ecs.c6.xlarge?
A: The fact cards confirm these instance types are supported in the console path. The API path’s supported instance types are not documented in its fact card — consult the `ess/api/ess-instance` detail skill for full compatibility.

Q: Can I modify the VPC after creating a scaling group via the console?
A: No — the console path has a hard limitation: **VPC**. If your architecture might change networks, plan carefully or consider API-based templating for reproducibility.

Q: Is there a way to use launch templates with the console?
A: Yes — **Instance Configuration Sources** in the console allow selecting launch templates. But for programmatic control over templates, use **create_scaling_group_with_launch_template** in the API path.

### [Integrate services](https://company-skill.com/p/ess/ess-integrate-services.md)

## What You Want to Do

You want to connect your Auto Scaling **scaling groups** to external Alibaba Cloud services like **Classic Load Balancer (CLB)**, Application/NLB **server groups**, or **ApsaraDB RDS instances**, either during initial setup, at runtime, or to fix integration failures.

- Can Auto Scaling work with RDS?

## Decision Tree

Pick the best path for your situation:

- **If** you are performing **initial configuration** of a scaling group and using standard Alibaba Cloud services like **Classic Load Balancer (CLB)** or **ApsaraDB RDS instances** → Use SLB// (go to *ess/ess-instance*)
- **If** you need to **dynamically attach or detach** external resources **during runtime** (e.g., in CI/CD or multi-environment deployments) using **API operations** → Use API (go to *ess/ess-instance*)
- **If** your integration is already configured but you observe issues like **health check fails**, **404 error**, or **permission denied** when accessing **SLB backend server group** or **RDS** → Use SLB/RDS (go to *ess/ess-instance*)
- **Otherwise (default)** → Start with **SLB//** — it’s the safest for first-time users and covers basic integration via guided UI.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| SLB// | low | No | No | Only supports binding during scaling group creation/modification; no runtime changes | `ess/guide/ess-instance` |
| API | medium | Yes | Yes | Uses **ForceAttach parameter** to override conflicts during dynamic attachment | `ess/api/ess-instance` |
| SLB/RDS | medium | No | No | Requires checking **ess:DescribeScalingInstances** and **ess:SetInstancesProtection** status | `ess/troubleshooting/ess-instance` |

## Path Details

### Path 1: SLB//

**Brief Description**: This path uses the Auto Scaling console to perform actions like **Associate CLB Instance**, **Associate ALB and NLB Server Groups**, **Attach RDS Instances**, **Associate ApsaraDB RDS Instance**, and **Disassociate from SLB and RDS**. It guides users through linking **scaling groups** to external services with visual workflows, ensuring region and VPC alignment.

**Key technical facts**:  
*(All fields omitted as fact_card contains only prerequisites/limitations, no runtime/billing data)*

**When to Use**:
- Auto Scaling

### Path 2: API

**Brief Description**: This approach uses **API operations** such as `AttachDBInstances` and `DetachDBInstances` to manage dependencies between **scaling groups** and **ApsaraDB RDS instances** programmatically. It supports the **ForceAttach parameter** to resolve **parameter conflict** scenarios during dynamic attachment.

**Key technical facts**:  
*(All fields omitted as fact_card contains only prerequisites/limitations, no runtime/billing data)*

**When to Use**:
- CI/CDAuto Scaling

### Path 3: SLB/RDS

**Brief Description**: This path focuses on diagnosing integration failures using ESS APIs like **ess:DescribeScalingInstances**, **ess:SetInstancesProtection**, **ess:EnterStandby**, **ess:ExitStandby**, and **ess:RemoveInstances**. It addresses issues such as instances not joining the **SLB backend server group**, **health check fails**, or **404 error** during association.

**Key technical facts**:  
*(All fields omitted as fact_card contains no runtime/billing data)*

**When to Use**:
- Auto Scaling
- permission denied

## FAQ

Q: Which path should I start with?
A: If you’re setting up integration for the first time and don’t need runtime changes, start with **SLB//**. It ensures correct region/VPC alignment and walks you through **Associate CLB Instance** and **Attach RDS Instances** safely.

Q: What if my **private IP address whitelist** is full but I used the console path?
A: You’ll hit a failure during scaling because new instances can’t be added to the RDS whitelist. The console doesn’t auto-expand whitelist capacity — you must manually free slots before scaling.

Q: If I need to dynamically switch RDS instances across environments but chose the console path, what happens?
A: You’ll be unable to update bindings without recreating or modifying the scaling group manually each time — defeating automation. The console path **does not support runtime adjustments**, so CI/CD pipelines will break.

Q: Can I use the troubleshooting path to set up integration for the first time?
A: No. The troubleshooting path assumes integration is already configured. Using it for initial setup will leave your **scaling groups** unconnected to **SLB backend server group** or **ApsaraDB RDS instances**.

Q: Why do I get a **404 error** when associating SLB even after correct setup?
A: This often occurs if the **Classic Load Balancer (CLB)** and scaling group are in different regions or VPCs — a prerequisite enforced by the console but easily missed in API usage. Verify alignment before retrying.

Q: Does the API path handle **parameter conflict** automatically?
A: No — you must explicitly use the **ForceAttach parameter** to override conflicts (e.g., duplicate instance IDs). Without it, the API call fails silently or returns an error.

Q: What if **health check fails** on new instances added to SLB?
A: This is a symptom addressed by the troubleshooting path. Causes include missing security group rules, incorrect listener configuration, or delayed RDS whitelist sync — all requiring diagnostic steps using **ess:DescribeScalingInstances**.

Q: 如果我需要在多环境部署中自动化管理外部服务绑定，但选择了控制台路径（SLB//），会发生什么？
A: 控制台路径不支持自动化脚本或程序化方式管理绑定关系，因此你的CI/CD流程将无法自动更新SLB或RDS绑定，导致部署失败或配置不一致。

Q: 如果我要求运行时动态挂载或解绑外部资源，但选择了控制台路径（SLB//），会怎样？
A: 控制台路径仅支持在伸缩组创建时或修改时绑定外部服务，无法在运行时动态调整。你将无法实现动态挂载需求，必须手动干预。

Q: 如果我已有CI/CD流程需要程序化集成，但选择了控制台路径（SLB//），结果如何？
A: 控制台路径不支持程序化集成，你的CI/CD流程将无法自动完成绑定操作，破坏自动化部署流程。

### [Manage instances](https://company-skill.com/p/ess/ess-manage-instances.md)

## What You Want to Do

You want to control the lifecycle or state of ECS instances inside an Auto Scaling group—such as protecting them from termination, placing them in standby, removing them manually, or diagnosing why they were unexpectedly removed.

**Typical User Questions**:
- How to put an instance into standby mode?
- Can I protect specific instances from being terminated?

## Decision Tree

Pick the best path for your situation:

- **If** you need to perform a one-time manual operation like setting **Protected state**, clicking **Remove from Scaling Group**, or confirming **Delete Instance** with **Disassociate from SLB and RDS** → Use (go to *ess/ess-instance*)
- **If** you are writing automation scripts that call **API** operations like **ess:SetInstancesProtection** or manage standby/health states programmatically → Use API// (go to *ess/ess-instance*)
- **If** your instance was unexpectedly terminated due to **Cloud Monitor agent** issues, **Argus Agent** failure, **INSUFFICIENT_DATA** in alarms, or **OverduePayment** → Use (go to *ess/ess-instance*)
- **Otherwise (default)** → Start with **** if you're unsure—it’s the safest way to inspect and manually adjust instance states without coding.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Console / Dashboard | low | No | No | Requires confirmation to **Disassociate from SLB and RDS** during deletion | `ess/guide/ess-instance` |
| API// | medium | Yes | Yes | Uses **ess:SetInstancesProtection** API with **ForceAttach** parameter support | `ess/api/ess-instance` |
| Console / Dashboard | medium | No | No | Addresses root causes like **INSUFFICIENT_DATA** or **OverduePayment** | `ess/troubleshooting/ess-instance` |

## Path Details

### Path 1: Console / Dashboard
**Brief Description**: Use the Auto Scaling console’s **Instances tab** to directly manage instances—set **Protected state**, execute **Remove from Scaling Group**, or permanently **Delete Instance**. The interface requires explicit confirmation to **Disassociate from SLB and RDS** before deletion to prevent service disruption.

**When to Use**:
- Need temporary debugging or manual intervention in the scaling group
- Performing operational troubleshooting requiring visual confirmation of instance status
- Unfamiliar with API calls but needing quick instance management

**When NOT to Use**:
- Need automated scripts to batch-process instance states
- Require integration with external monitoring or orchestration systems
- Performing frequent instance operations (console workflow is inefficient at scale)

**Known Limitations**:
- Only supports manual operations—no automation possible
- Requires RAM permissions for instance management actions
- Must confirm **Disassociate from SLB and RDS** during deletion, adding steps

### Path 2: API//

**Brief Description**: Programmatically manage instance states using Auto Scaling **API** calls such as **ess:SetInstancesProtection** to enable protection or configure standby mode. Supports advanced parameters like **ForceAttach** for edge cases during instance attachment.

**When to Use**:
- Building automation scripts to manage instance protection or health states
- Integrating with external systems (e.g., CI/CD, incident response tools)
- Managing instances across multiple scaling groups in bulk

**When NOT to Use**:
- Performing only a one-time or ad-hoc instance adjustment
- Lacking development resources to write and maintain API client code
- Needing immediate visual feedback on operation results

**Known Limitations**:
- Requires coding effort to implement and handle **API** authentication
- Must configure proper RAM permissions and manage credential security
- Some operations require specific parameter combinations (e.g., **ForceAttach**)

### Path 3: Console / Dashboard
**Brief Description**: Diagnose why instances were unexpectedly removed by checking **Cloud Monitor agent** status, **Argus Agent** health, alarm conditions showing **INSUFFICIENT_DATA**, or account issues like **OverduePayment** that trigger automatic instance release.

**When to Use**:
- Instance was auto-removed due to failed health checks
- Alarm-based scaling fails with **INSUFFICIENT_DATA** errors
- Instances stopped or released due to billing **OverduePayment**

**When NOT to Use**:
- Actively managing instance states (not responding to failures)
- Issue is unrelated to monitoring data or health evaluation
- Seeking an automated prevention mechanism rather than post-failure diagnosis

**Known Limitations**:
- Reactive only—cannot prevent issues before they occur
- Requires access to **Cloud Monitor** console to verify **Argus Agent** status
- Some root causes (e.g., **OverduePayment**) require financial resolution, not technical fixes

## FAQ

Q: Which path should I start with?
A: If you’re unsure, begin with ****—it lets you safely inspect and adjust instances without coding or assuming a failure occurred.

Q: What if I need to protect 50 instances daily but used the console?
A: You’ll face operational inefficiency—each action requires manual clicks, and there’s no way to automate **Protected state** via UI, leading to high maintenance overhead.

Q: What if my instance was deleted due to **OverduePayment** but I used the API path to “protect” it?
A: Protection via **ess:SetInstancesProtection** does **not** override billing-related terminations—**OverduePayment** will still cause instance release regardless of protection status.

Q: Can I use the troubleshooting path to prevent future health check failures?
A: No—the troubleshooting path only diagnoses past issues. To prevent recurrence, you must fix underlying causes (e.g., ensure **Cloud Monitor agent** is running) and possibly use the API or console to adjust configurations.

Q: Does the console automatically handle **Disassociate from SLB and RDS** during deletion?
A: No—you must explicitly confirm this step in the UI. Skipping it may leave orphaned backend entries or cause service errors.

Q: Will **INSUFFICIENT_DATA** errors be fixed by setting instance protection?
A: No—**INSUFFICIENT_DATA** indicates missing monitoring metrics (often due to **Argus Agent** issues), not a scaling decision. Protection won’t resolve data collection gaps.


## Frequently asked questions

### Should I use the API or the console for Auto Scaling?

Use the **console** for initial setup, visual monitoring, and one-off operations. Use the **API/SDK** for automation, CI/CD integration, or managing multiple environments programmatically.

### How do I authenticate API calls?

Provide your AccessKey pair and sign requests using the standard Alibaba Cloud signature method. Never hardcode keys—use environment variables or secure credential managers.

### Why can’t I see my scaling group in the console?

Verify you’re in the correct region, have sufficient RAM permissions (e.g., `ess:DescribeScalingGroups`), and that the group wasn’t deleted. Check the **Resource Group** filter if enabled.

### What causes “Insufficient Data” in alarm-triggered scaling?

This typically means CloudMonitor hasn’t collected enough metric data yet. Ensure the metric exists, has recent values, and the alarm rule uses a valid comparison operator.

### Can I use Auto Scaling with both ECS and ECI?

Yes—scaling configurations support either ECS instances (with launch templates) or ECI containers. Choose during scaling group creation; mixing types in one group is not supported.

### How do I configure scheduled or event-based scaling triggers?

You configure scaling triggers by defining when and how scaling occurs based on time or metrics. The documentation provides three alternative paths to set up these scheduled or event-based tasks.

### How do I create an Auto Scaling group?

You can create a new scaling group by using either the console or the API. The documentation outlines two alternative paths to guide you through the setup process.

### How do I integrate Auto Scaling with external services like SLB or RDS?

You integrate Auto Scaling by connecting your scaling groups to load balancers, databases, and other external services. The documentation provides three alternative paths to configure these integrations.

### How do I manage instances within a scaling group?

You manage instances within a scaling group by controlling their states, such as placing them in standby, enabling protection, or manually attaching them. The documentation offers three alternative paths to perform these management tasks.

## Cross-product integrations

- [AI-Powered Contact Center Intelligence Platform](https://company-skill.com/p/_combos/ai-powered-contact-center-intelligence-platform-cbbc60.md) (eb + es + dataworks + rds + opensearch)
- [Auto Scaling Event Delivery Pipeline](https://company-skill.com/p/_combos/auto-scaling-event-delivery-pipeline-4357f5.md) (eb)
- [Auto Scaling Group Data Protection with Monitoring](https://company-skill.com/p/_combos/auto-scaling-group-data-protection-with-monitori-122c14.md) (eb + ecs)
- [Auto-Scaling Production Stack with RAG Search](https://company-skill.com/p/_combos/auto-scaling-production-stack-with-rag-search-be1c2d.md) (alinux + ecs + terraform + oss + rds)
- [Auto-Scaling Web Cluster Deployment](https://company-skill.com/p/_combos/auto-scaling-web-cluster-deployment-659c6b.md) (terraform + ecs)
- [Bailian RAG + ES Chatbot with EventBridge Alerts](https://company-skill.com/p/_combos/bailian-rag-es-chatbot-with-eventbridge-alerts-873dcb.md) (eb + es + bailian + dataworks + rds)
- [Batch Pipeline with Closed-Loop Multi-Channel Notification](https://company-skill.com/p/_combos/batch-pipeline-with-closed-loop-multi-channel-no-ec172e.md) (eb + resend + alinux + ecs + supabase)
- [Bidirectional DingTalk-Lark ECS Provisioning Loop](https://company-skill.com/p/_combos/bidirectional-dingtalk-lark-ecs-provisioning-loo-9c34b9.md) (eb + ecs + alinux + supabase + dataworks)

## Use with an AI agent

```bash
curl -s https://company-skill.com/api/route \
  -H 'Content-Type: application/json' \
  -d '{"query": "...", "product": "ess"}'
```

MCP server: https://company-skill.com/api/mcp/ess.py

---
Machine-readable: https://company-skill.com/llms.txt · https://company-skill.com/sitemap.xml