Nikhil Reddy
Nikhil Reddy
Hi @HansScharrer Did you deploy the remote [template](https://s3.amazonaws.com/solutions-reference/aws-instance-scheduler/latest/aws-instance-scheduler-remote.template) in the target account(s) and update the CloudFormation parameter "Cross-account roles" ([deployment instructions](https://docs.aws.amazon.com/solutions/latest/instance-scheduler/deployment.html))? The scheduler will try to create a log of...
Hi @HansScharrer You can consider using the Systems Parameter store to work around the 4096 limit for the cloudformation parameter, please refer to the [documentation](https://docs.aws.amazon.com/solutions/latest/instance-scheduler/deployment.html). Comma-delimited list of cross-account roles....
Hi @HansScharrer I would recommend that you use the SSM parameter store to provide the Cross Account Roles to the solution and not update the dynamoDB config attribute. The fix...
Hi @HansScharrer You can pass multiple SSM parameter names to the solution, in the format, `{param: ssm-param1}, {param: ssm-param2}`. Or you can launch multiple stacks for the same solution and...
Hi @HansScharrer Can you confirm what is being loaded into the DynamoDB table config attribute, since you are updating the cloudformation paramater with `{param: /instance-scheduler/account-list1},{param: /instance-scheduler/account-list2}` is it `{param: /instance-scheduler/account-list1},{param:...
HI @HansScharrer Thanks for confirming I am trying to recreate the issue.
Hi @HansScharrer Can you enable enhanced logging parameter named "Enable CloudWatch Logs", select Yes if not already done, and update the stack, once the update is complete, can you verify...
Hi @HansScharrer I was able to recreate the scenario but only after making some changes to the lambda code, in the file `cloudwatch_event_handler` (path `lambda/requesthandlers/`) there is a method `handle_request`,...
Hi @HansScharrer If you are referring to the cross_account roles yes it worked. Can you provide the cloudwatch event rule JSON, it will be logged into the logstream [STACK_NAME]-YYYYMMDD, ```...
@HansScharrer Thanks for finding that, it sure seems to be the root cause of the issue, we will investigate this further and add an bugfix to the solution backlog, After...