Which option meets the requirements with the LEAST disruption?
Create an AWS account for each business unit. Move each business unit’s instances to its own account and set up a federation to allow users to access their business unit’s account.
Set up a federation to allow users to use their corporate credentials, and lock the users down to their own VPC. Use a network ACL to block each VPC from accessing other VPCs.
Implement a tagging policy based on business units. Create an IAM policy so that each user can terminate instances belonging to their own business units only.
Set up role-based access for each user and provide limited permissions based on individual roles and the services for which each user is responsible.
Explanations:
Creating separate AWS accounts for each business unit would provide isolation and improve availability; however, it would involve significant disruption due to account migrations and the need to manage multiple accounts, making it a less favorable option.
Setting up federation with network ACLs to restrict access between VPCs could enhance security, but it would not prevent users from modifying or terminating resources within their own VPC, which remains a risk. This solution also adds complexity without addressing the primary issue of resource management across business units.
Implementing a tagging policy along with an IAM policy that restricts users to manage resources only within their business unit’s tags allows for better resource governance while causing minimal disruption. This approach maintains the existing architecture but adds an important layer of control and accountability.
Role-based access can help manage permissions, but without strict controls related to resource ownership (like tagging), users could still potentially modify or terminate resources that do not belong to them. This option does not directly address the need to restrict access based on resource ownership.