Which solution will meet these requirements with the LEAST operational overhead?
Create an IAM policy that has an aws:RequestedRegion condition that allows actions only in the designated Region. Attach the policy to all users.
Create an IAM policy that has an aws:RequestedRegion condition that denies actions that are not in the designated Region. Attach the policy to the AWS account in AWS Organizations.
Create an IAM policy that has an aws:RequestedRegion condition that allows the desired actions. Attach the policy only to the users who are in the designated Region.
Create an SCP that has an aws:RequestedRegion condition that denies actions that are not in the designated Region. Attach the SCP to the AWS account in AWS Organizations.
Explanations:
While this IAM policy allows actions only in the designated Region, attaching it to all users increases operational overhead due to the need for ongoing management of user permissions. Each time a new user is added, the policy must be attached, which could lead to inconsistencies and higher maintenance efforts.
Although this policy could effectively prevent launching resources in other Regions by denying actions not in the designated Region, attaching it to the AWS account does not enforce a Region restriction at a higher organizational level. It may still require management of IAM policies for specific user permissions, which adds complexity.
This policy restricts specific users to only the desired Region, but it requires continual management of individual user permissions. As user roles and responsibilities change, this can lead to increased operational overhead and complexity.
Creating a Service Control Policy (SCP) that denies actions in Regions outside the designated one is the best approach. SCPs are enforced at the organization level, meaning that all accounts under the organization will inherit this restriction with minimal operational overhead, eliminating the need for individual IAM policy management for each user.