Lower elbv2 target group draining timeout for ECS services

[pahud]

The default registration delay timeout of elbv2 target group is 300s which is way too long for some simple web applications and user will wait at least 5min when they cdk deploy to kickoff the service rolling update.

see discussion here https://twitter.com/pahudnet/status/1185232660081197056

Use Case

Users need lower draining timeout and faster ECS service rolling update experience.

Proposed Solution

Option 1

To provide a new optional drainingTimeout property for all *LoadBalanced*Service classes. If customer specify the new drainingTimeout duration, CDK update the target group attribute accordingly. Otherwaise, it remains the default 300s.

For example

    const webSvc = new ecsPatterns.ApplicationLoadBalancedEc2Service(this, 'webSvc', {
      cluster,
      taskDefinition,
      desiredCount: 3,
      drainingTimeout: Duration.seconds(30),
    })

Option 2

To provide new ECS patters for "fast API / web server with no long connections" without surfacing the implementation details.

Other

• [ ] :wave: I may be able to implement this feature request
• [ ] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

[rix0rrr]

I think short-lived connections are the norm rather than the exceptions. Shouldn't this be the default for all load balanced connections? Or just for ECS?

[pahud]

@rix0rrr Depends on the service type, if you are running websocket service on ECS behind ALB or NLB, it will be a long-lived connection. I agree the default 300s value is way too long, but make it 30s could also break some scenarios with long-lived connections such as websocket or TCP service running on ECS behind NLB.

[rix0rrr]

I understand that, but people in non-common situations can still adjust the timeout (and there should be a discoverable, convenient API for it via a Duration property!).

We should be optimizing for the common case, that helps the most people.

[pahud]

@rix0rrr Agree. Thanks for your input.

[zhahaoyu]

Any update on this? I am using bitbucket pipeline's deploy plugin https://bitbucket.org/atlassian/aws-ecs-deploy/src/master/ This plugin will timeout in 10 minutes. Although the plugin could have waited longer, it would be nice to provide an option so I can configure the lb draining time

[vertti]

Any updates on this? People can't be happy waiting 5 extra minutes on every deploy.

[tmokmss]

Here's the workaround for this issue: https://github.com/aws/aws-cdk/issues/4015#issuecomment-553007260

[whereisaaron]

While 30 seconds is more sensible that the AWS default 300 seconds, leaving things default unless the user overrides is an OK position too. Either way, this is a setting people do commonly want to change, so it would be nice if it were exposed by L2/L3 Constructs. If is exposed by the API and documented, people can find it and change it. In the meantime they'll be Googling until their find the magic incantation in https://github.com/aws/aws-cdk/issues/4015#issuecomment-553007260 😂

loadBalancedFargateService.TargetGroup.SetAttribute("deregistration_delay.timeout_seconds", "10");