Turbonomic's parking functionality issue for Auto Scaling Groups (ASGs) running Windows instances (non-Spot)

We are working with the ITAU customer who is experiencing performance issues with the parking functionality in Turbonomic for Auto Scaling Groups (ASGs) running Windows instances (non-Spot).
The issue is that Turbonomic's current parking behavior terminates the EC2 instances, and during the next scale-out event, it creates new EC2 instances, which takes approximately 1 hour and 15 minutes due to the nature of the Windows's processes.
The customer previously implemented a custom Lambda solution that:
*         Suspended scaling processes on the ASG.
*         Stopped the EC2 instances instead of terminating them.
*         On the following day, resumed the scaling processes and started the same EC2 instances.
This allowed the Windows machines to come online much faster, avoiding the overhead of provisioning and bootstrapping new instances.
We understand that Turbonomic does not currently work in this way, and that this behavior is not configurable. While we understand that it would be possible to adjust the schedule to start the environment one hour earlier, the concern is when users want to start it manually outside the Schedule window (do nothing times), they would still face a delay of over one hour before being able to work.
We wanted to raise this IDEA as it’s significantly impacting customer satisfaction and may prevent them from continuing with Turbonomic for parking automation. We are rolling out our first case of Turbonomic in Itaú. The results from that case will drive our expansion negotiation on this Q3, if we were not able to implement that parking scenario, all negotiation will be at risk.
Could you please help us with any workarounds or roadmap plans to support this use case? We would appreciate any information.