ECS EC2栈首次部署后CDK重复部署失败问题咨询

问题出在ECS默认的滚动更新逻辑和你的实例资源容量冲突：

• t2.micro实例总CPU是1vCPU（换算成ECS的CPU单元为1024），你两个服务的任务各占0.5vCPU（512单元），刚好把实例CPU占满。
• 首次添加第二个服务时，是直接把新任务调度到剩余的0.5vCPU资源上，没有旧任务需要替换，所以部署成功；但之后重复执行cdk deploy时，哪怕代码无修改，CDK仍会触发ECS服务的滚动更新流程——默认策略是先启动新任务，再终止旧任务，此时实例需要同时承载3个任务的CPU需求（2个旧任务+1个新任务），超出了t2.micro的容量上限，导致调度失败。

1. 调整ECS服务部署策略，先停旧任务再启新任务 #

在CDK代码中给服务配置部署参数，将minimumHealthyPercent设为0，maximumPercent设为100。这样更新时会先终止旧任务释放资源，再启动新任务，避免瞬间资源过载：

// TypeScript示例，其他语言逻辑一致
const service = new ecs.Ec2Service(this, 'MyService', {
  cluster: cluster,
  taskDefinition: taskDef,
  deploymentConfiguration: {
    minimumHealthyPercent: 0,
    maximumPercent: 100,
  },
});

调整后，每次更新时实例上同一服务最多只会存在1个任务，总CPU占用始终控制在1vCPU以内。

2. 升级EC2实例规格 #

如果后续需要新增任务，或者想保留默认的滚动更新逻辑，可以将实例升级为t2.small（2vCPU）或更高规格，预留足够的冗余资源应对更新时的临时需求。

3. 启用ECS容量提供者自动扩缩容 #

给ECS集群配置容量提供者并关联Auto Scaling Group，当集群资源不足时自动扩容EC2实例，让任务调度时能自动补充资源。不过对你当前仅运行2个小任务的场景来说，这个方案略显冗余，更适合长期有扩缩容需求的场景。

4. 排查CDK是否存在不必要的变更触发更新 #

有时候即使代码无修改，CDK的一些隐式变更（比如任务定义哈希值变化、标签自动更新等）也会触发服务更新。可以执行cdk diff查看具体变更内容，若为不必要的变更，针对性调整CDK代码避免触发更新。

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