Why do ASG have separate, different scheduling process with other services?

[TranVanDung-Leo]

Is your feature request related to a problem? Please describe.

Hi team, I use and develop instance scheduler but I see that the flow to schedule ASGs is complicated, different than other services, that it uses a separate orchestrator, a lambda to observe change in the dynamodb table stream, and a potential risk of unconvertable schedules into cronjob of ASG scheduling actions.

Describe the feature you'd like

ASG, and other services will be scheduled in the same orchestrator.

Additional context

[CrypticCabub]

Thanks for reaching out! Is there a particular requirement or use-case that would benefit from making all services share the same orchestrator?

ASGs require a fundamentally different scheduling flow due to the requirement to use Schedule Scaling Rules as an intermediary step for schedule operation. As such we set up a longer polling interval than normal (1 hour) for ASG scheduling and then added the dynamodb stream lambda as a short-circuit response to changes in the schedule database.

Since this flow is fundamentally different from the busy-polling approach used by EC2 and RDS, we thought it woould be more appropriate to use a separate ochestrator to manage it rather than overloading the existing orchestrator and needlessly complicating the control flow within.

[TranVanDung-Leo]

@CrypticCabub But I saw the main difference in ASG data and its definition. Separate workflows cause developers very hard to understand the flow and it contain many lambda, hidden rule (1 days affection, 1 hour cron)

[CrypticCabub]

It is admittedly a confusing difference that we are hoping to be able to simplify in future releases. For regular single-period schedules ASGs should actually be more accurate than EC2/RDS schedules, and we hope to be able to expand the feature support in the future to cover more complex schedules.