Which solution will meet these requirements?
Use Organizations to create OUs that have appropriate SCPs attached for each team. Place team accounts in the appropriate OUs to apply security controls. Create any new team accounts in the appropriate OUs.
Create an AWS Control Tower landing zone. Configure OUs and appropriate controls in AWS Control Tower for the existing teams. Configure trusted access for AWS Control Tower. Enroll the existing accounts in the appropriate OUs that match the appropriate security policies for each team. Use AWS Control Tower to provision any new accounts.
Create AWS CloudFormation stack sets in the organization’s management account. Configure a stack set that deploys AWS Config with configuration rules and remediation actions for all controls to each account in the organization. Update the stack sets to deploy to new accounts as the accounts are created.
Configure AWS Config to manage the AWS Config rules across all AWS accounts in the organization. Deploy conformance packs that provide AWS Config rules and remediation actions across the organization.
Explanations:
While using Service Control Policies (SCPs) in Organizational Units (OUs) can provide some level of governance, it does not provide the comprehensive preventive and detective controls that the DevOps team requires. SCPs mainly control what services and actions are available to accounts but do not enforce security configurations or monitor compliance effectively across accounts.
AWS Control Tower provides a framework for governance that includes establishing OUs, implementing SCPs, and provisioning new accounts with predefined security controls. It simplifies the management of multiple accounts with a landing zone that automatically applies security best practices and compliance policies, making it the most effective solution for the company’s requirements now and for future account creation.
While AWS CloudFormation stack sets can deploy AWS Config with configuration rules across accounts, it requires manual updates to the stack set when new accounts are created. This approach does not provide a continuous governance framework or automatic account provisioning like AWS Control Tower does, which is essential for maintaining security controls over time as new accounts are added.
AWS Config can manage rules and compliance across accounts, but deploying conformance packs is a more reactive approach. It does not establish a preventive framework for new accounts, nor does it simplify the process of account creation and governance like AWS Control Tower. Without automation for new accounts, it may not effectively meet the ongoing governance needs of the company.
It seems to me that the answer is:
Create an AWS Control Tower landing zone. Configure OUs and appropriate controls in AWS Control Tower for the existing teams. Configure trusted access for AWS Control Tower. Enroll the existing accounts in the appropriate OUs that match the appropriate security policies for each team. Use AWS Control Tower to provision any new accounts.