CDK v2中如何为ECS Fargate目标追踪扩缩容策略设置告警数据点？

一、在CDK v2中设置目标追踪扩缩容的“datapoints to alarm”参数 #

scaleToTrackCustomMetric方法会自动生成扩容（AlarmHigh）和缩容（AlarmLow）对应的CloudWatch告警，但该方法的配置项未直接暴露datapointsToAlarm参数。不过可以通过访问目标追踪策略的内置告警对象，手动修改该配置：

declare const fargate: FargateService;
const metric = new cloudwatch.Metric({
  namespace: "redisQueueSizeNamespace",
  metricName: `QueueSize`,
  period: Duration.minutes(1),
  statistic: cloudwatch.Statistic.MAXIMUM,
});

const scaling: ScalableTaskCount = fargate.service.autoScaleTaskCount({ 
  minCapacity: 5, 
  maxCapacity: 30
});

// 创建目标追踪扩缩容策略
const targetTrackingPolicy = scaling.scaleToTrackCustomMetric(`QueueSizeScaling`, {
  metric,
  targetValue: props.itemsPerInstance,
  policyName: '10k-items-per-task',
  disableScaleIn: false,
  scaleOutCooldown: Duration.minutes(2),
  scaleInCooldown: Duration.minutes(2)
});

// 配置扩容告警的datapoints to alarm
targetTrackingPolicy.scaleOutAlarm?.configureDatapointsToAlarm({
  datapointsToAlarm: 2, // 满足告警条件的点数
  evaluationPeriods: 3  // 总评估周期数，需大于等于datapointsToAlarm
});

// 配置缩容告警的datapoints to alarm
targetTrackingPolicy.scaleInAlarm?.configureDatapointsToAlarm({
  datapointsToAlarm: 2,
  evaluationPeriods: 3
});

二、手动调整任务数并停止Fargate任务的可行性与注意事项 #

可行性 #

该操作在技术上可行，但仅适用于临时手动干预场景，不建议替代托管式扩缩容策略作为常规操作。

弊端 #

• 与托管扩缩容冲突：目标追踪策略会持续根据指标调整期望任务数，手动修改的desiredCount可能被覆盖，导致操作无效。
• 破坏服务自愈逻辑：若未先调整desiredCount就停止任务，Fargate服务会立即启动新任务补充至原期望数量，无法达成减少任务的目的。
• 运维复杂度提升：手动操作无法自动适配指标变化，长期使用会增加人工维护成本，且易出现人为失误。

SDK调用顺序（针对Fargate） #

Fargate无Auto Scaling Group（ASG），无需调用asg.terminate_instance_in_auto_scaling_group，正确顺序为：

1. 调用ECS.updateService，将desiredCount减少对应数量；
2. 调用ECS.stopTask，停止指定的任务实例。

若颠倒顺序，先停止任务，服务会立刻启动新任务维持原desiredCount，操作将失去意义。

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