Is your feature request related to a problem? Please describe.
We use Instance Scheduler in a hub-spoke deployment to manage EC2 and RDS start/stop lifecycles on a schedule, saving significant cost by turning off non-production resources outside business hours. However, we also run ECS Fargate services that need the same treatment — scaled to zero outside working hours and restored during working hours. Today this requires building a separate solution because Fargate services can't be "stopped" like EC2 instances; they need their desired task count set to zero and later restored. Managing two scheduling systems for the same business-hours pattern creates operational overhead, inconsistent observability, and duplicated schedule definitions.
Describe the feature you'd like
Native ECS Fargate service scheduling as a first-class service alongside EC2, RDS, and ASG. Specifically:
ECS services tagged with the schedule tag key are automatically discovered through the existing EventBridge registration flow
On STOP: capture the service's current desiredCount in a tag, then set desiredCount to 0 (and zero out Application Auto Scaling bounds if registered)
On START: restore desiredCount from the remembered capacity (and restore autoscaling bounds)
Uses the same schedules, periods, timezone handling, and kill switch that already exist — no separate configuration
Works cross-account via the existing hub-spoke trust model
No new CloudFormation parameters, Lambda functions, DynamoDB tables, or EventBridge rules required
This means customers get ECS scheduling for free with their existing deployment, using the same schedules they already define for EC2 and RDS.
Additional context
I have a complete implementation based on v3.2.6 that I'd like to contribute as a PR. It follows the existing service patterns (imperative model like EC2/RDS, capacity stored as a control tag IS-EcsCapacity, registration via aws.tag events). The change spans 15 modified files (383 insertions, 5 deletions) and 12 new files (~1,800 lines), for roughly 2,200 lines of new code and tests total.
Verified:
804 Python + 89 CDK tests pass (60 new ECS-specific tests)
mypy --strict, black, isort, flake8, prettier, eslint all clean
End-to-end tested: Fargate service at desiredCount=2 scaled to 0 on stop with capacity captured, restored to 2 on start
Is your feature request related to a problem? Please describe.
We use Instance Scheduler in a hub-spoke deployment to manage EC2 and RDS start/stop lifecycles on a schedule, saving significant cost by turning off non-production resources outside business hours. However, we also run ECS Fargate services that need the same treatment — scaled to zero outside working hours and restored during working hours. Today this requires building a separate solution because Fargate services can't be "stopped" like EC2 instances; they need their desired task count set to zero and later restored. Managing two scheduling systems for the same business-hours pattern creates operational overhead, inconsistent observability, and duplicated schedule definitions.
Describe the feature you'd like
Native ECS Fargate service scheduling as a first-class service alongside EC2, RDS, and ASG. Specifically:
ECS services tagged with the schedule tag key are automatically discovered through the existing EventBridge registration flow
On STOP: capture the service's current desiredCount in a tag, then set desiredCount to 0 (and zero out Application Auto Scaling bounds if registered)
On START: restore desiredCount from the remembered capacity (and restore autoscaling bounds)
Uses the same schedules, periods, timezone handling, and kill switch that already exist — no separate configuration
Works cross-account via the existing hub-spoke trust model
No new CloudFormation parameters, Lambda functions, DynamoDB tables, or EventBridge rules required
This means customers get ECS scheduling for free with their existing deployment, using the same schedules they already define for EC2 and RDS.
Additional context
I have a complete implementation based on v3.2.6 that I'd like to contribute as a PR. It follows the existing service patterns (imperative model like EC2/RDS, capacity stored as a control tag IS-EcsCapacity, registration via aws.tag events). The change spans 15 modified files (383 insertions, 5 deletions) and 12 new files (~1,800 lines), for roughly 2,200 lines of new code and tests total.
Verified:
804 Python + 89 CDK tests pass (60 new ECS-specific tests)
mypy --strict, black, isort, flake8, prettier, eslint all clean
End-to-end tested: Fargate service at desiredCount=2 scaled to 0 on stop with capacity captured, restored to 2 on start