Is there a way to have Instance Scheduler support a cron-like syntax to build dynamic schedules in the future

[exolain]

We have a really big organization and there are customers who have specific requirements on their schedules. We can have people from Bulgaria/India and London working on the same application and sometimes there schedule might overlap. And a specific set schedule for office hour of a specific region wouldn't be ideal for them

is possible to have an option to use a custom schedule if the time needed is not covered by the ones you are already providing? Perhaps based in a Cron-like syntax. I understand that the way that the Instance Scheduler is designed right now this might be challenging. But wondering if it can be reviewed as a potential feature in the future. Please do let me know if you think it might be impossible to implement on the near future.

The idea would be that the customer would provide a tag with the specific cron syntax to stop and start their instances. Similar to something like: InstanceSchedulerStart: "0 5 *"

• this would run every day at 5am every day

InstanceSchedulerStop: "0 17 *"

• this would run every day at 5pm.

Let me know if you have any questions.

[CrypticCabub]

Thanks for reaching out!

Can you help me understand your use-case a little better? I want to make sure we understand the root problem before attempting to engineer a solution. A few questions that come to mind:

• Is there an organizational reason why another schedule cannot be configured in the hub account for these specific use cases (there's no limit on the number of schedules that can be configured)?
• In what ways would supporting schedule definitions on tags themselves provide a better customization experience for sub-orgs?
• Would deploying a separate copy of instance scheduler for each department with special scheduling needs address this problem?

[exolain]

Hi @CrypticCabub ,

Thanks a lot for the quick response.

Please see responses below in order:

• So basically management doesn't want to open this option to the users since our organization already has more than 1000 accounts with different teams with different support models. So, the amount of custom schedules we would need to update on the Cloudformation template could get way to big by all the different requests we might get (some teams wanting a 10-hour schedule, others with a 12-hour schedule with different start / end times). So, this could get us to hit the limit on the CFT template actually, as well as adding an additional operational workload to our team.
• Previous statement explains a bit for this question as well. Basically would be to allow them better flexibility without having to make code changes
• Yes, we could also ask them to deploy their own InstanceScheduler instance on their accounts. Let me review with one of the customers who was requesting this feature.

Thanks again!

[CrypticCabub]

no problem!

For your first concern, Instance Scheduler can support multiple cloud formation templates with multiple schedules per template, though I will grant that this just moves the goalpost to CFN service quotas on the hub account.

I've seen some similar requests for more schedule control on spoke accounts, but it leads to a difficult question of trying to balance the benefits of centralized control with dispersed flexibility. We could, for example, allow each spoke account to provide its own set of schedules, but then we would have to read dynamodb in every spoke account as well as in the hub account which would complicate troubleshooting and would also have a noticable impact on the solution's baseline running costs. There's also the per-instance tagging approach you mentioned which seems more doable, but that has its own complexities and challenges

I would be very curious as to if deploying multiple hub stacks would be sufficient to meet the needs of your customers or not. It is, in-fact, possible to have multiple copies of Instance Scheduler scheduling the same account so long as each copy uses a different namespace and scheduling tag key (no two hubs should ever attempt to schedule the same instance). This raises the complexity of operating the solution substantially though so it's not a perfect answer.

[exolain]

Hi @CrypticCabub ,

one more question. Before asking the customers with going with the option to deploy it on their environment. When I first deployed Instance Scheduler the CLI didn't exist so, I haven't had the chance to use it. https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/available-commands.html#create-period

If use the Create Period from the CLI what would that do? would that create the period on the DynamoDB configuration? If the Cloudformation template were to be update it do you know if that would "override" or for some reason remove the period created via the CLI?

The reason why I'm asking is because I'm thinking if there might be a possibility for us to create a service catalog product that would simply run this CLI utility to create the specific periods the customers would need. Instead of manually update the cloudformation template. But I also don't want for it to conflict with the IaC code in the future.

[CrypticCabub]

The CLI is basically a thin wrapper around crud operations on the database. with the create/update commands for schedules and periods basically being put operations with overwrite = false/true respectively. It doesn't currently have a safety check against not overwriting a schedule managed by a cloud formation template, but I will discuss the possibility of adding such a check with the team.

[CrypticCabub]

Spoke with the team about it and took a closer look at the exact behavior when the CLI and CFN Schedules interact. Currently the CLI does not respect CFN-managed schedules, but I am working on adding that behavior in this week as a late addition to our next major release. No formal release date yet, but we're hoping to be able to go live in the next few months.

[exolain]

That's great! Thank you so much ! 🎉 Will keep an eye on the release notes

[CrypticCabub]

Cli respecting CFN manage schedules has been added in v3.0.0