Got it, I've run into this exact scenario before—AWS Console's default auto-scaling rule setup doesn't let you directly combine multiple metrics with AND/OR logic, but there's a straightforward way to do this using CloudWatch Composite Alarms paired with Application Auto Scaling policies. Here's how to set it up step by step:

首先得明确：AWS控制台的基础自动扩缩容规则确实不支持直接配置多指标的逻辑组合，但我们可以通过CloudWatch复合告警（Composite Alarms） + Application Auto Scaling策略来实现你要的扩缩容逻辑。

前提准备 #

• 你的ECS服务已经开启了Application Auto Scaling（也就是已经在ECS控制台设置了服务的最小、最大任务数，并且关联了Auto Scaling配置）
• 已经在CloudWatch中有了CPU使用率和connection_count的指标，且能正常采集到数据（如果已有单指标告警也可以直接复用）

步骤1：创建ECS扩缩容策略 #

先进入Application Auto Scaling控制台（或者直接在ECS服务的「自动扩缩容」标签页操作），创建两个独立的缩放策略：

扩容策略（Scale Out） #

• 选择你的目标ECS服务
• 策略类型选Step Scaling
• 配置缩放步骤：比如触发时直接增加2个任务，或者按当前任务数的20%扩容（根据你的业务负载调整）
• 设置冷却时间：建议设为300秒（5分钟），避免短时间内频繁触发扩容

缩容策略（Scale In） #

• 同样选择你的目标ECS服务
• 策略类型选Step Scaling
• 配置缩放步骤：比如触发时减少1个任务，或者按15%比例缩容（缩容幅度保守一点更稳妥）
• 设置冷却时间：建议设为600秒（10分钟），比扩容冷却时间长，避免误缩容影响业务

步骤2：创建复合告警（Composite Alarms） #

进入CloudWatch控制台的「告警」页面，创建两个复合告警，分别对应你的扩容、缩容逻辑：

扩容复合告警（满足任一条件即触发） #

• 告警名称：比如ECS-Service-ScaleOut-Trigger
• 选择「复合告警」类型
• 配置告警规则表达式（注意OR必须大写）：

  (ALARM('CPU-Usage-Over-80') OR ALARM('Connection-Count-Over-9500'))
  

  这里的CPU-Usage-Over-80和Connection-Count-Over-9500是你之前创建的单指标告警（如果还没创建，也可以直接在复合告警里嵌套单指标阈值条件，不过复用已有告警更清晰）
• 触发动作：选择「通知」，然后关联你刚才创建的扩容Step Scaling策略

缩容复合告警（需同时满足两个条件才触发） #

• 告警名称：比如ECS-Service-ScaleIn-Trigger
• 选择「复合告警」类型
• 配置告警规则表达式（注意AND必须大写）：

  (ALARM('CPU-Usage-Below-50') AND ALARM('Connection-Count-Below-5000'))
  

  同样，这里的两个告警是你预先创建的单指标缩容告警（CPU使用率<50%、连接数<5000）
• 触发动作：关联你的缩容Step Scaling策略

步骤3：验证配置 #

创建完成后，可以通过CloudWatch的「注入测试数据」功能模拟指标触发，或者等待实际业务流量触发，检查ECS服务的任务数是否按照预期扩缩容。

另外要注意几个细节：

• 复合告警的逻辑表达式里，告警名称必须和你创建的单指标告警完全一致
• 确保connection_count指标的维度（比如集群名称、服务名称）和ECS服务的维度完全匹配，否则告警无法正确关联
• 冷却时间可以根据你的业务波动情况灵活调整，避免过度扩缩容

内容的提问来源于stack exchange，提问作者rayepps