Closed brianmyburgh closed 3 years ago
i somehow doubt this is the case. IIRC i have been using this resource in regions other than us-east-1. @eduardomourar?
Yes, I can confirm that the password policy resource can be created in any region. Keep in mind that this is a global resource, so we are not allowed to specify the region to the underlying AWS API.
It might be worth changing the reference architecture. Because, by setting to the primaryRegion, others might get the wrong impression that they can change it.
good, so:
Interesting suggestion to 'hardcode' the region to a specific region and advice not to change it. This however has the unintended side-effect that you might have a majority of your resources deployed to your primaryRegion and we would advice to deviate from that primaryRegion to not cause confusion if passwordPolicies are deployed to multiple regions with different values.
i personally think leaving it the way it is (stack/logical resource gets deployed to primaryRegion) is just fine.
still mysterious as to why deploying the passwordPolicy resource to eu-central-1 didnt work for @brianmyburgh
FYI, it is also related to this issue created in the cloudformation roadmap: https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/493
Org-formation: !Ref allRegions? 🤣
Org-formation: !Ref allRegions? 🤣
Yes, I know. Hahahaha!
My idea here was for the registry internal API to handle it instead of OrgFormation having to deploy (and manage) to all possible regions.
yeah, obviously. i think StackSets is doing some good work.... i think that would be the path they are on...
...maybe we should get on a call with the cfn team to see where/how we can converge these two...
Yes, there is only one password policy per account, so in essence region should not matter. But why does eu-central-1 not work but us-east-1 does in our case?
Note that it was us evaluating Security hub to realise that this was not set as the cloudformation stack and the org-formation stack run successfully with no errors but without actually setting anything.
Password-policy stack needs to run in us-east-1. The corresponding register-type PasswordPolicy also needs to exist in us-east-1