Lower elbv2 target group draining timeout for ECS services
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
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
```js
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
Contributor guide
Research direction
Start by locating the ECS patterns `*LoadBalanced*Service` classes and how they configure elbv2 target group attributes. Determine whether the implementation should expose an optional `drainingTimeout` or introduce separate fast-service patterns, then verify that the selected approach preserves the 300-second default and enables faster rolling updates.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, devops
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100