ECS 弹性伸缩提速 4.2 倍：20 秒级指标 + 86 秒触发扩容，告别流量高峰翻车

做微服务的都踩过这个坑：流量突然涨了，但 ECS 扩容太慢。

以前的流程：CloudWatch 指标 1 分钟上报一次 → Application Auto Scaling 检测到超阈值 → 等 3 个数据点确认 → 触发扩容 → 拉新 Task → 健康检查通过 → 开始接流量。整个链路跑完，6 分钟过去了。高峰期 6 分钟，用户早骂完了。

6 月 18 日，亚马逊云科技发布了 ECS 服务弹性伸缩的重大更新——高分辨率指标（High-Resolution Metrics），把指标上报间隔从 60 秒缩短到 20 秒，整体扩容触发时间从 363 秒降到 86 秒。

核心改进

直接上数据（来自 AWS 官方基准测试）：

维度	改进前	改进后	提升
指标发布间隔	60 秒	20 秒	3x
触发扩容时间	363 秒	86 秒	4.2x（快 76%）
扩容完成总时间	462 秒	145 秒	3.2x

什么概念？以前流量来了要等 6 分钟才开始扩，现在 1 分半搞定。

为什么以前慢

ECS Auto Scaling 依赖 CloudWatch 指标来判断"要不要扩"。旧的流程：

T+0s:   流量突增
T+60s:  第 1 个指标数据点上报（1分钟精度）
T+120s: 第 2 个数据点
T+180s: 第 3 个数据点（Target Tracking 默认等 3 个点确认趋势）
T+240s: 触发 scaling activity
T+300s: 新 Task 开始拉取镜像
T+360s: 容器启动 + 健康检查
T+420s: 注册到 ALB，开始接流量

问题出在前半段：指标太粗（60秒），确认太慢（等 3 个点）。

新的流程

T+0s:   流量突增
T+20s:  第 1 个高分辨率数据点上报
T+40s:  第 2 个数据点
T+60s:  第 3 个数据点
T+80s:  触发 scaling activity
T+100s: 新 Task 拉取镜像（通常已缓存）
T+120s: 容器启动
T+145s: 健康检查通过，接入流量

从感知到流量变化到新容器接流量，总共 2 分半。

怎么启用

好消息：不需要改代码，不需要重新部署服务。 这是平台侧的更新，自动生效。

不过你可以通过调整 Scaling Policy 来充分利用这个改进：

import boto3

client = boto3.client('application-autoscaling', region_name='us-east-1')

# 注册 ECS Service 为可扩缩目标
client.register_scalable_target(
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    MinCapacity=2,
    MaxCapacity=20
)

# 设置 Target Tracking Policy
client.put_scaling_policy(
    PolicyName='cpu-target-tracking',
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 60.0,  # CPU 使用率目标 60%
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'ECSServiceAverageCPUUtilization'
        },
        'ScaleInCooldown': 120,   # 缩容冷却 2 分钟
        'ScaleOutCooldown': 30    # 扩容冷却 30 秒（关键：配合高分辨率指标，降低冷却时间）
    }
)

print('Scaling Policy 已更新')

关键配置建议：把 ScaleOutCooldown 从默认的 300 秒降到 30-60 秒。以前冷却时间长是因为指标本身就慢，现在指标 20 秒一个点，冷却时间可以跟着缩短。

三种 Scaling 策略配合

ECS 现在支持三种策略并行使用：

# 1. 预测性扩缩容（Predictive Scaling）— 提前扩
# 基于历史流量模式，ML 算法预测未来负载
client.put_scaling_policy(
    PolicyName='predictive-scaling',
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    PolicyType='PredictiveScaling',
    PredictiveScalingPolicyConfiguration={
        'MetricSpecifications': [{
            'TargetValue': 60.0,
            'PredefinedMetricPairSpecification': {
                'PredefinedMetricType': 'ECSServiceAverageCPUUtilization'
            }
        }],
        'Mode': 'ForecastAndScale',   # 预测+执行
        'SchedulingBufferTime': 300    # 提前 5 分钟扩
    }
)

# 2. 定时扩缩容（Scheduled Scaling）— 按计划扩
# 已知的流量高峰（大促、活动）
client.put_scheduled_action(
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    ScheduledActionName='morning-peak',
    Schedule='cron(0 8 * * ? *)',  # 每天早8点
    ScalableTargetAction={
        'MinCapacity': 10,
        'MaxCapacity': 50
    }
)

# 3. Target Tracking（响应式）— 实时追踪
# 已在上面配置，现在 20 秒级响应

三种策略可以同时生效，互不冲突：

• 预测性：处理日常流量波动（早晚高峰）
• 定时：处理已知事件（大促、活动直播）
• Target Tracking + 高分辨率指标：处理突发流量（热点事件、DDoS）

实际效果对比

假设你的 API 服务平时跑 4 个 Task，早高峰需要 12 个：

旧方案（363 秒触发）：

9:00 流量开始涨
9:06 扩容触发，开始拉 Task
9:07 新 Task 启动
9:08 开始接流量
→ 9:00-9:08 之间的 8 分钟内，4 个 Task 承受 12 个 Task 的流量
→ 响应延迟飙升，部分请求超时

新方案（86 秒触发）：

9:00 流量开始涨
9:01:26 扩容触发
9:02:25 新 Task 接入
→ 只有 2.5 分钟的过载期
→ 配合预测性扩缩容，可能在 8:55 就已经预扩到 8 个 Task
→ 用户几乎无感知

搭配其他 ECS 能力

让扩容更快的其他手段：

1. 镜像预缓存：用 ECS Anywhere 或 Capacity Provider 预拉镜像
2. Fargate Spot + On-Demand 混合：平时跑 Spot 省钱，突增时 On-Demand 兜底
3. Service Connect：服务发现自动注册，省去 ALB 注册等待时间
4. ECR Pull Through Cache：镜像拉取从 S3 走，比跨 Region 拉 DockerHub 快

注意事项

1. 高分辨率指标会增加 CloudWatch 费用：20 秒上报意味着数据量是 60 秒的 3 倍。对于小规模集群影响不大，大集群留意一下账单
2. ScaleOutCooldown 别设太短：30 秒是合理下限。设太短容易"弹簧效应"——扩了又缩，缩了又扩
3. 自动生效无需操作：已有的 ECS Service 会自动受益，不需要重建
4. Region 支持：所有支持 ECS 的 Region 都已生效

开始使用

如果你已经在用 ECS + Auto Scaling，恭喜——不需要做任何事，你的扩容速度已经自动提升了。

如果你想进一步优化，可以：

1. 检查现有 Scaling Policy 的 Cooldown 设置，适当缩短
2. 开启 Predictive Scaling，让系统学习你的流量模式
3. 在 CloudWatch 里观察新的 20 秒级指标，看看是否需要调整阈值

文档：https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html

---

这个更新解决的是一个真实痛点：微服务扩容慢。以前业内的共识是"预扩容比响应式扩容靠谱"，现在响应式扩容也够快了——86 秒触发 + 145 秒接入流量，大部分场景下够用。