---
Title: Manage instances
URL Source: https://company-skill.com/p/ess/ess-manage-instances
Language: en
Description: 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…
---

# Manage instances

Part of **Auto Scaling (ESS)**. Route queries via `POST https://company-skill.com/api/route`.

## 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.

## Related queries

manage scaling group instances, manage auto scaling instances, put instance in standby, protect ECS instance from termination, manually add ECS to scaling group, check instance health status, stop some instances in scaling group, prevent key instance deletion, handle unhealthy scaling instances, how

---
Part of [Auto Scaling (ESS)](https://company-skill.com/p/ess.md) · https://company-skill.com/llms.txt