CDK overwrites ECS service desired count back to 1 on every deploy

[nathanpeck]

🐛 Bug Report

What is the problem?

The default behavior of an ECS service update is to maintain the existing desired count if no desired count is specified. This is because customers often use autoscaling, or time based scaling and their scaling rules have already set the service to a specific desired count that is appropriate. Because CDK and CFN can not know this number at the time of the deploy the correct behavior is to omit it and retain the existing desired count.

However when you leave desired count out of the ECS construct in CDK it instead sets it to 1. This overrides whatever the current autoscaling set desired count is, causing a brief period of instability before the desired count is automatically restored to the right number by autoscaling.

[pgarbe]

You can easily reproduce it when you change some settings of the service itself, like a changed tag. In that case DesiredCount gets overwritten by the value defined in the stack. This is not a CDK issue but rather a CloudFormation problem.

[manV]

This seems like a pretty common problem, is there any workaround for this? maybe we can get current DiseredCound when doing new deploy somehow?

edit: setting DesiredCount 0 in CloudFormation seems to be keeping it as the current value. CDK however defaults it to 1 if omitted.

[manV]

ping. @SoManyHs @pkandasamy91 I am happy to help any way I can.

[rix0rrr]

This is CloudFormation behavior and not much we can do about this in CDK. It needs to be fixed upstream in the same way it works for AutoScalingGroups (desiredcount can be undefined, in which case it stays the same on updates, and for creates it defaults to the minimum capacity).

[manV]

Thanks @rix0rrr for the clarification. I can see an issue already open on containers-roadmap here.