EC2 CPU达70%时如何触发AWS AutoScale启动其他服务器组

你设想的CloudWatch > Lambda > Auto Scaling（以下简称ASG）链路属于冗余实现，额外引入Lambda层会徒增权限维护、代码排障、异常重试的运维成本，90%以上的同场景下用AWS原生的CloudWatch告警直连ASG扩缩策略就能实现需求，链路更短、稳定性更高，是官方推荐的标准实现。

前置准备（必做） #

不管用哪种方案，你首先得把当前单跑的EC2纳入ASG管理，不然ASG没有权限关联你的现有实例、也没法按配置弹新机器：

• 新建ASG的时候选择「附加现有实例」，选中你当前一直在跑的这台EC2
• ASG基础参数设置：最小实例数填1（保证你原有业务至少有1台机器跑，不会被ASG随便缩没），最大实例数按你业务上限填（如果当前只需要多弹1台就先填2），初始期望实例数填1
• 给ASG绑定提前做好的启动模板：把你现有EC2的AMI、实例规格、安全组、开机自启动脚本、存储配置都同步到启动模板里，保证新弹的机器和现有实例配置一致，开机就能跑业务
• 如果你业务用负载均衡承接流量，记得把ASG绑定到对应目标组，新实例启动后会自动注册到LB接流量

原生无Lambda方案配置步骤（优先选） #

这套方案完全不需要写代码，所有逻辑都是AWS托管，配完基本不用维护：

• 进入ASG详情页，找到「自动扩缩」-「扩缩策略」板块，新建步进扩缩策略
  • 扩缩动作选择「添加容量」，调整值设为1，也就是触发时新增1台实例
  • 触发规则设置为：ASG平均CPU使用率 >= 70%，持续评估周期按你业务容忍度选，怕瞬时尖峰误触发就选2个连续5分钟周期，要响应快就选1个1分钟周期
  • 冷却时间按你业务启动耗时设，比如你的服务从开机到正常接流量要2分钟，就设300秒留冗余，冷却期内不会重复触发扩缩，避免弹多机器浪费钱
• 保存策略后AWS会自动创建对应的CloudWatch告警，告警状态变为触发态时会直接给ASG发扩缩指令，中间没有额外转发层
• 建议同步配置缩容规则：再加一条步进缩容策略，设置ASG平均CPU使用率低于30%、持续3个周期时，实例数减1，自动缩回到1台的基线水平，记得给你最初那台长期运行的实例开启「缩容保护」，避免缩容的时候被误终止。

CloudWatch>Lambda>ASG链路配置方法（仅适合复杂判断场景） #

如果你的触发逻辑不只是单纯看CPU到70%，还要结合内存占用、业务接口错误率、甚至外部系统的指标做综合判断，才需要用Lambda做中间逻辑层，配置步骤如下：

• 新建CloudWatch告警，监控目标选你当前运行的EC2实例，指标选CPU利用率，阈值设为>=70%，触发动作配置为调用目标Lambda函数
• 新建Lambda运行角色，给角色分配对应ASG的操作权限（生产环境别直接给全量AutoScaling权限，最小权限只开放SetDesiredCapacity、DescribeAutoScalingGroups两个接口的操作权限即可）
• Lambda核心逻辑参考（Python runtime）：

import boto3
asg_client = boto3.client('autoscaling')
# 替换成你自己的ASG名称和预设的最大实例数
YOUR_ASG_NAME = "biz-prod-asg"
MAX_INSTANCE_COUNT = 2

def lambda_handler(event, context):
    asg_info = asg_client.describe_auto_scaling_groups(
        AutoScalingGroupNames=[YOUR_ASG_NAME]
    )['AutoScalingGroups'][0]
    current_cap = asg_info['DesiredCapacity']
    new_cap = min(current_cap + 1, MAX_INSTANCE_COUNT)
    if new_cap == current_cap:
        return "Current capacity already reach max limit, no scale action"
    asg_client.set_desired_capacity(
        AutoScalingGroupName=YOUR_ASG_NAME,
        DesiredCapacity=new_cap,
        HonorCooldown=True
    )
    return f"Scale out triggered, capacity changed from {current_cap} to {new_cap}"

• 配完后手动模拟CPU高负载测试下触发逻辑，注意这套方案你要自己处理告警重复触发、接口调用失败重试、冷却时间判断的逻辑，运维成本比原生方案高很多，非必要不选。

避坑提醒 #

• 一定要提前测试新启动的实例能不能自动承接业务：比如服务有没有设开机自启、有没有自动注册到负载均衡、配置文件有没有自动拉取，别等触发扩缩了才发现新弹的机器没跑业务，原机CPU打满故障
• 尽量用ASG维度的聚合CPU指标做告警，不要直接监控单台EC2的CPU指标，避免单台实例的指标采集异常导致误触发扩缩
• 如果你的服务启动后有预热期（比如Java服务要加载几分钟缓存），记得在ASG里配置实例预热时长，预热期内新实例的指标不会纳入扩缩判断，避免刚开机CPU占用高导致重复弹机器

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