Support for deploying remote roles with stacksets

[hopkinsnji]

Describe the bug Instance scheduler currently does not play nicely with cloudformation stacksets. The hub template always deploys a named role, which would be the same name as the named role in the spoke templates. If you deploy the spoke templates with stacksets to an OU that includes the hub account, you won't be able to deploy the hub stack because the Namespace-SchedulerRole already exists in the remote stack. Conversely, if you deploy the hub stack first, then the remote stack(from the stackset) will fail to deploy in the hub account.

To Reproduce

Depoly remote stack with a stackset to an OU that includes the hub account. Then deploy the hub stack, and it will fail because it tries to create a role tha already exists in the remote stack.

Expected behavior

I expect to be able to deploy the remote stack and the hub stack in the same account as was previously possible.

Please complete the following information about the solution:

• [ ] Version: [e.g. v3.0.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0030) instance-scheduler-on-aws v1.5.1". You can also find the version from releases

• [ ] Region: all
• [ ] Was the solution modified from the version published on this repository? NO
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [x] Have you checked your service quotas for the sevices this solution uses? YES
• [ ] Were there any errors in the CloudWatch Logs? NO Troubleshooting

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

[CrypticCabub]

To deploy spokes via stackset while ignoring the account where the hub stack is installed, you can use the AccountFilterType=Difference flag as described on the stack-set documentation here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/account-level-targets.html

By providing the OU as a target and the Hub account as an account target, the difference flag will then instruct stacksets to filter out the specified accounts from the list of accounts that it will deploy the spoke to.

I hope that helps!

[tivanov-qb]

I do not use AWS Organizations parameter, but also using StackSets to deploy the solution. With the latest version (migrating from v1.5.5 to v3.0.2), IAM roles are being created with the same name. This means if you have different regions that you want to cover within the same account, stackset will fail after first region is completed because the IAM role is global and it already exists.

[CrypticCabub]

You do not need to deploy multiple copies of the spoke stack for each region of instance scheduler. To enable scheduling for ALL regions in a spoke account, you only need to deploy 1 copy of the spoke stack IN THE SAME REGION as the Hub stack. The IAM Role deployed has sufficient permissions to allow Instance Scheduler to perform cross-region scheduling

[tivanov-qb]

hi @CrypticCabub thank you for your switft response!

I've previously deployed the solution with StackSet that was looping over my supported regions. So each region in destination account has it's dedicated stack if you will. With the newer versions released, does it mean I need to have hub stack per region ? so if i have 4 regions, i need to deploy 4 hub stacks ?

[CrypticCabub]

do you have some business requirement for needing a different installation for each region?

The design of Instance Scheduler is specifically geared to allow you to install exactly 1 hub account in a single account/region, and then a single copy of the spoke stack in each member account. Once that is done, Instance Scheduler can schedule all linked accounts, and all regions in those accounts from a single central location (this being one of the main value propositions of the solution)

[tivanov-qb]

no, not really business requirement, but as I mentioned version that I used was 1.5.5 and correct if i'm wrong, but few months ago this functionality was not available (sorry if I've missed that)

probably the easiest way to follow the approach you recommend is to delete all present stacks and follow: https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/aws-cloudformation-templates.html

[CrypticCabub]

Yes, your understanding of 1.5.5's behavior is incorrect. This deployment method has been the consistent design for the lifetime of the solution.

the largest change to the deployment method came in 1.5.0 which added the "Namespace" property to both the hub and spoke stacks. This property made it explicitly possible to install multiple copies of instance scheduler in the same account (and even the same region) so long as they had different namespaces. This was not the primary technical reason for implementing namespaces in the solution, but it is a notable side-effect of the design.

3.0.0 then updated the backend permissions with stricter trust relationships between solution components. These relationships were designed to function within the confines of expected deployment invariants which would explain why you began seeing issues when updated from 1.5.5. For reference, these are the deployment invarients we expect:

• hub account with hub stack installed (no spoke stacks)
• N spoke accounts with 1 spoke stack installed in each
• all stacks (hub and spoke) installed in the same region as one another
• all stacks use the same namespace
• the hub stack is installed before the spoke stacks are deployed
• if opt-in regions are used, they are enabled in both the hub and spoke accounts*

*more of an edge-case that may not be necessary in all circumstances, your mileage may vary

[tivanov-qb]

@CrypticCabub thanks a lot! I've migrated the solution to hub/spoke setup, everything looks good!