AWS Control Tower Deployment Scenarios
The goal of this blog is to share my experience in deploying AWS Control Tower in different scenarios and considerations. This is not an exhaustive list, but covers most of the common implementation scenarios.
Introduction:
In AWS terms “Control Tower is the easiest way to set up and govern a new, secure multi-account AWS environment” this phrase sums up what exactly Control Tower can offer to an enterprise.
AWS Control Tower helps enterprises with standardised AWS account provisioning process with configurable policies and controls as part of AWS account provisioning process, this helps enterprises to govern and secure their multiple AWS accounts with out losing the agility of the cloud.
AWS Control Tower integrates with other AWS resources like Organisations, Single Sign On, Cloud Trail, Config, SNS, Lambda & Cloud Formation StackSets etc. to provide business agility and governance control.
General Considerations:
Below are some points to consider before deploying Control Tower.
- Consider using shared E-mail inbox for AWS root Email ID’s instead of individual Email ID’s for ease of administration.
- Spend some time designing AWS users/groups and their permissions for different teams.
- Consider using AWS SSO and integrate it with Active directory for central management of users and groups.
- If using AWS SSO, the SSO URL can be customised, however it can not be changed once customised, hence have a good think before you customise this.
- Design AWS Organisation Units this can be aligned to environments ( Dev, Test, Production and Sandbox etc.) or also can be Business Units based on the requirements.
- Carefully review VPC settings in Control Tower account factory before provisioning any new account, certain settings can provision unintended resources like NAT Gateways in child accounts as part of baseline stacks which can be expensive.
- Control Tower does not have AWS CLI/ CFN APIs to automate the deployment process (as of today), the enrolling of accounts and activating guard rails on each OU is painfully manual and sequential. Consider using script mentioned in below links for enrolling accounts. (applicable for enrolling existing accounts scenario).
- If a requirement to deploy custom tasks needs to be performed along with new account provisioning, consider using Control Tower Customisation (Check References section below).
Below are some of the scenario specific considerations of deploying AWS Control Tower.
Scenario#1: Deploying Control Tower in a new AWS account & Migrating AWS accounts from existing AWS Organisation.
This scenario is where an enterprise decides to use a new AWS account for Control Tower and they already have another AWS master account with Organisations setup,
Here the process is, removing accounts from existing Organisation and moving it to the new Organisation and enrolling them to Control Tower.
Considerations:
- Carefully check if there are any resources shared with existing Organisations using AWS RAM. for example the subnets can only shared with in one AWS Organisation.
- Removing an account from Organisation requires to provide a new payment method for child account as it would be standalone account for a while before joining the new Organisation.
- If consolidated billing feature is being used, the move of accounts from existing Organisation should be planned carefully and executed. This depends on how important the charge back mechanism to different Business Units for that particular enterprise.
Scenario#2: New Deployment
This is the scenario where an enterprise does not have any AWS foot print and planning to start their cloud journey with multi account strategy. In this case Control Tower deployment in master AWS account is pretty straight forward and one of the first resources to deploy.
Considerations:
- Control Tower deployment will also created AWS Organisations with 2 default OU’s.
- All of the general considerations listed above applies to this type of deployment.
Scenario#3: Deploying Control Tower with existing AWS accounts
In this scenario enterprise has existing AWS accounts with or with out AWS Organisation.
Considerations:
- Review current AWS access method, if you are using IAM users consider switching to AWS SSO.
- Carefully evaluate effects of preventative guard rails (SCP’s)you apply to OU’s.
- Register / create OU’s via Control Tower, Control Tower does not recognise OU’s created outside of Control Tower.
- If AWS Organisation is not implemented, deploying Control Tower will automatically create AWS Organisations with 2 default OU’s (Core and Custom), Core is reserved for Audit and Log accounts and Custom OU can be used for AWS accounts or different OU’s can be created.
Conclusion:
Pros:
Overall AWS Control Tower is great for account provisioning and provides a wonderful insight of overall AWS accounts health ( in terms of adherence to defined policies) from central dashboard. Recording of API activities with CloudTrail and configuration change logging with Config satisfies most enterprises security and audit requirements.
Cons:
AWS Control Tower does not have CLI / CloudFormation API’s to deploy or manage Control Tower as a code is bit of pain, however I believe this would be certainly in making and would be available soon.
#AWS #AWSSecurity #AWSControlTower #AWSLandingZone
