What should the solutions architect do to meet this requirement with the LEAST amount of management overhead?
Create IAM users and IAM groups in each account. Create IAM policies to limit access to non-European Regions. Attach the IAM policies to the IAM groups.
Enable AWS Organizations, attach the AWS accounts, and create OUs for European Regions and non-European Regions. Create SCPs to limit access to non-European Regions and attach the policies to the OUs.
Set up AWS Single Sign-On and attach AWS accounts. Create permission sets with policies to restrict access to non-European Regions. Create IAM users and IAM groups in each account.
Enable AWS Organizations, attach the AWS accounts, and create OUs for European Regions and non-European Regions. Create permission sets with policies to restrict access to non-European Regions. Create IAM users and IAM groups in the primary account.
Explanations:
While creating IAM users and groups with policies to restrict access to non-European Regions would work, managing IAM users and groups in multiple accounts can lead to increased administrative overhead. It lacks central management, which is necessary for large organizations using multiple accounts.
Using AWS Organizations allows for centralized management of multiple accounts. By creating Service Control Policies (SCPs) that restrict access to non-European Regions and applying them to organizational units (OUs), developers can be effectively restricted with minimal management overhead. This approach scales well and aligns with best practices for security and governance.
Setting up AWS Single Sign-On (SSO) with permission sets can restrict access, but it still requires the creation of IAM users and groups in each account, leading to higher management overhead. Additionally, this option does not leverage AWS Organizations for centralized management, which is more efficient for controlling access across multiple accounts.
Although using AWS Organizations with permission sets can help manage access centrally, creating IAM users and groups in the primary account adds unnecessary complexity and overhead. The focus should be on leveraging OUs and SCPs for managing access effectively without duplicating user management across accounts.
My best guess is:
Enable AWS Organizations, attach the AWS accounts, and create OUs for European Regions and non-European Regions. Create SCPs to limit access to non-European Regions and attach the policies to the OUs.