How can a Solutions Architect achieve the isolation requirements?
Create individual accounts for each business unit and add the account to an OU in AWS Organizations. Modify the OU to ensure that the particular services are blocked. Federate each account with an IdP, and create separate roles for the business units and the Security team.
Create individual accounts for each business unit. Federate each account with an IdP and create separate roles and policies for business units and the Security team.
Create one shared account for the entire company. Create separate VPCs for each business unit. Create individual IAM policies and resource tags for each business unit. Federate each account with an IdP, and create separate roles for the business units and the Security team.
Create one shared account for the entire company. Create individual IAM policies and resource tags for each business unit. Federate the account with an IdP, and create separate roles for the business units and the Security team.
Explanations:
Creating individual accounts for each business unit allows for complete autonomy and minimizes blast radius, as each unit operates in isolation. Using AWS Organizations, you can manage these accounts and apply Service Control Policies (SCPs) to block specific services for the organizational unit (OU). Federating each account with an Identity Provider (IdP) and creating separate roles ensures that access control is maintained for both business units and the Security team.
While creating individual accounts for each business unit offers autonomy, it lacks the additional management and control that AWS Organizations provide. Without OUs and SCPs, it’s more difficult to enforce restrictions on specific services across multiple accounts effectively. This option does not provide a robust isolation strategy and could lead to increased management overhead.
Using one shared account for the entire company negates the required isolation for each business unit, creating a higher blast radius. Although separate VPCs can provide some network-level isolation, it does not ensure complete autonomy of workloads. Individual IAM policies and resource tags alone do not provide sufficient separation, and the approach increases the risk of accidental access to resources across business units.
Similar to option C, using a single shared account does not achieve the required isolation between business units. While IAM policies and resource tags can help manage permissions, they do not provide the same level of autonomy and isolation that multiple accounts would. This approach increases the risk of cross-contamination of resources and access management complexities.