introduce regions to reduce authorization errors

[DawidKrysiak]

SCP-blocked regions cause floods of errors in the logs

To my understanding, the scheduler enters an account and tries to act upon all available regions.
The problem with that is, that some regions are blocked with SCP policies causing:

{IAM Role} not authorized to perform: `tag:GetResources` with an explicit deny in a service control policy

Proposed solution(s)
An additional attribute in DDB to define regions (needs to be account->[regions] to allow for full customisation of regions per account.

Alternatively, to avoid changing the item's attribute:
Implement in the code a catch for a region definition, if exists.

Example:

remote_account_ids : "123456789012{eu-west-1,us-east-1},123456789011{eu-central-1}"

[CrypticCabub]

Thanks for submitting this request.

Knowledge of specific organizational SCPs would be outside the scope of the solution, but allowing spokes to individually define which regions they would like to be within scope for scheduling may be a possible enhancement in the future, though this comes at the trade-off of additional configuration complexity.

If anybody else would also like to see per-spoke account configuration of scheduled regions, please add a thumb's up reaction to the original request and reply to this thread with any additional context on your use-case that may be helpful in the design of such a feature.

[DawidKrysiak]

Hi,
Thank you for looking into it.
The second solution I proposed would be probably the easiest to implement as:

1. it does not require ddb structure changes, updates to the attributes would be solely at the users' discretion
2. it's backwards compatible if the code would treat the {regions} as optional. (btw, I threw {} as an example - whatever format is convenient would work as long as I can define lists of regions :) )

So if some users don't care, they leave their config as is, and nothing breaks. The ones who care (i.e. sysadmins supporting accounts in the Orgs they have no control over) would simply add the required {} to their config attributes for the regions that cause errors (and streams of CloudTrail alarms :) )