Which solution will meet these requirements with minimal optional overhead?
Use an SCP in Organizations to implement a deny list of AWS servers. Apply this SCP at the level. For any specific exceptions for an OU, create a new SCP for that OU and add the required AWS services to the allow list.
Use an SCP in Organizations to implement a deny list of AWS service. Apply this SCP at the root level and each OU. Remove the default AWS managed SCP from the root level and all OU levels. For any specific exceptions, modify the SCP attached to that OU, and add the required AWS services to the allow list.
Use an SCP in Organizations to implement a deny list of AWS service. Apply this SCP at each OU level. Leave the default AWS managed SCP at the root level. For any specific executions for an OU, create a new SCP for that OU.
Use an SCP in Organizations to implement an allow list of AWS services. Apply this SCP at the root level. Remove the default AWS managed SCP from the root level and all OU levels. For any specific exceptions for an OU, modify the SCP attached to that OU, and add the required AWS services to the allow list.
Explanations:
Using a deny list for AWS services is a valid approach, but the solution described is not optimal. The policy should be applied at the root level to ensure consistency across the entire organization, not just at the OU level. Creating separate SCPs for each OU increases overhead and complexity.
This option removes the default AWS managed SCP from the root level and all OUs, which can lead to unintended consequences and increased management overhead. The default SCPs should be left intact to avoid potential security risks.
This approach applies the deny list only at the OU level, leaving the root level less controlled. While it avoids the complexity of creating multiple SCPs for each OU, it may not consistently enforce the policy across all accounts in the organization.
This option applies an allow list of AWS services at the root level, which is the recommended approach to ensure consistency and minimize complexity. The default AWS managed SCPs should be left in place, and specific exceptions can be managed at the OU level by modifying the SCP attached to that OU. This minimizes overhead and ensures policies are uniformly enforced across all accounts.
I opine that the answer is:
Use an SCP in Organizations to implement an allow list of AWS services. Apply this SCP at the root level. Remove the default AWS managed SCP from the root level and all OU levels. For any specific exceptions for an OU, modify the SCP attached to that OU, and add the required AWS services to the allow list.