Which solution will meet these requirements with the LEAST operational overhead?
Use AWS SSO to set up service-linked roles with IAM policy statements that include the Condition, Resource, and NotAction elements to allow access to only the Regions and services that are needed.
Deactivate AWS Security Token Service (AWS STS) in Regions that the developers are not allowed to use.
Create SCPs that include the Condition, Resource, and NotAction elements to allow access to only the Regions and services that are needed.
For each AWS account, create tailored identity-based policies for AWS SSO. Use statements that include the Condition, Resource, and NotAction elements to allow access to only the Regions and services that are needed.
Explanations:
AWS SSO does not use service-linked roles for access control. Service-linked roles are used for AWS services to access other AWS services, not for user access.
Deactivating AWS STS in Regions does not restrict access to specific AWS services or specific Regions in a granular way. This does not meet the requirement.
SCPs (Service Control Policies) can restrict access to specific Regions and services across all AWS accounts in an AWS Organization, providing a scalable solution with minimal overhead.
Identity-based policies for AWS SSO would require manual configuration for each user or group in each account, leading to higher operational overhead than using SCPs.
To the best of my knowledge, the answer is:
Create SCPs that include the Condition, Resource, and NotAction elements to allow access to only the Regions and services that are needed.
As I understand it, the answer is:
Create SCPs that include the Condition, Resource, and NotAction elements to allow access to only the Regions and services that are needed.