Guidance for Establishing an Initial Foundation using Control Tower on AWS

Implementation Resources

• Planning for foundational deployment

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Planning for foundational deployment 

    • Document conventions and basic governance
  • Overview

  • Effective governance permits consistency and control over the environment while maintaining agility. This allows developers to continue to create new products, innovate on current services, and more. Proper governance may include many elements, and even the prospect of establishing fundamental governance might be overwhelming. 

    Supporting Cloud Foundations capability:

    • Governance
  • Implementation
  • Document conventions and basic governance

    Before you start creating an environment, you need to establish basic governance. Naming conventions are one of the most visible core governance procedures and they allow for planning at scale. Identifying a method to name your AWS accounts will enable you to effectively identify ownership or type of AWS account operating within your environment. Additionally, identifying the locations where your AWS management plane and operational workloads are will help you ensure your accounts are not inconsistently sprawled across AWS. In this action, you will create a documented email convention for new accounts, identify and document your home AWS Region, and identify and document your operational AWS Regions. The documentation will help you drive the creation of a well-planned and consistent environment. 

    In this section, you will define your naming convention for new AWS accounts and determine the Regions you want to manage and operate in AWS.
    

    Create AWS account email naming convention

    When creating new AWS accounts, you will need to use an email address that is associated with the root user of the account. To better manage your AWS environment as it scales, it is recommended to establish a naming convention for the account alias and the corresponding root account email address. We recommend using the same name used for the email as the AWS account alias.

    An example is: “aws-management-account-primary@example.com” which is given to the management account of your AWS Organization. Consider that over time you may become responsible to more than one AWS Organization and that you will need to differentiate those environments. All AWS accounts require a unique email address and can never be leveraged twice. The following is an example of getting started with a naming convention:

    Account Alias	Root email	Email Example	Description
    aws-management-account-[org-identifier]	aws-management-account-[org-identifier]@example.com	aws-management-account-primary@example.com	Name given to the alias and email address for the management account. Org-identifier is used to specify the AWS organization. This can be the function of the organization or a number (eg. 1)
    [workload]-[environment]-[org-identifier]	aws-[workload]-[environment]-[org-identifier]@example.com	aws-[workload]-[environment]-primary@example.com	Convention used for your workload accounts. Org-identifier is used to specify the AWS organization. This can be the function of the organization or a number (eg. 1)
    [sandbox]-[username]-[org-identifier]	aws-[sandbox]-[username]-[org-identifier]@example.com	aws-[sandbox]-[username]-primary@example.com	Convention used for creating AWS sandbox accounts for specific user. Org-identifier is used to specify the AWS organization. This can be the function of the organization or a number (eg. 1)

    Note: Do not simply give your AWS management account the name aws-management-account. Within AWS, you can potentially have more than one AWS management account and Organization. We recommend using an additional descriptor to ensure that if you scale your environment to multiple AWS Organizations, you will be able to identify the different environments. For more information, review this Multiple organizations section from the AWS Whitepaper on Organizing your AWS Environment Using Multiple Accounts.

    Determine home Region

    Within AWS, you will select a home Region where you deploy your AWS Organization management and orchestration tools such as AWS Control Tower and AWS IAM Identity Center. The home Region does not need to be the same as the operational Regions (where your workloads are deployed). If you do not have specific compliance requirements, we recommend keeping your home Region in a Region that supports the necessary AWS services such as AWS Control Tower and aligns with one of your operational Regions.

    Home Region considerations

    1. The home Region does not have to be one of your operational Regions (the Regions where workload data and resources will be hosted)
    2. A home Region could be your operational Region
    3. Reference Supported Regions for AWS Control Tower
       

    Determine operational Regions

    Within AWS, your operational Regions are AWS Regions where you will allow workloads to operate in. Operational Regions can be thought of as the AWS Regions where your end-user data is stored. All other AWS Regions should have controls put in place to restrict operational access. Your operational Region(s) can be the same as your home Region but can also include other Regions. 

    For a list of AWS Regions, reference global infrastructure Regions.

    For more information to help you identify your operational Regions, read the AWS architecture blog: What to Consider when Selecting a Region for your Workloads.

• Creating and configuring your management account

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Creating and configuring your management account 

    • Create management account
    • Configure management account
  • Overview

  • The management account (sometimes referred to as the payer account or AWS organization management account) is the AWS account that defines and manages your AWS Organization. It can create new AWS accounts and invite existing AWS accounts into its AWS Organization. Your AWS management account will be used to:

    1. Centralize a billing entity for all member AWS accounts
    2. Manage AWS Organization services across all member accounts
    3. Enable and delegate AWS Services at the organization level to member accounts
    4. Define management and security policies across the environment
    5. Create, remove, and invite other AWS accounts into the organization

     

    Due to the high level of permissions associated with the management account, it is important to setup and secure the management account early in the process.

     

    Supporting Cloud Foundations capabilities: 

    • Identity Management & Access Control
    • Support
  • Implementation
  • Create management account

    The management account is your first AWS account when onboarding is initiated. The initial setup requires information to create the account that is used during sign up. Once the AWS account is created, it is important to start with security in mind. 
    

    In this section you will create a new management account with a secure root user. 
    

    Set up management account email address

    When creating the new AWS account, you will need to supply an email address that has never been used for an AWS account. We recommend you setup a distribution group email and give it a title following the convention of: “aws-management-account-primary@example.com”, which maps the email address to functionality. This allows the members of the distribution list to recover access to the environment, and if an individual leaves your company or organization, they can be removed from the distribution list. Only add a small number of members to the group email as this email address is for the management account root administrative user.

    Document all email addresses you create for AWS accounts as each email address can be used only one time for account creation.
    

    Create AWS management account

    Visit Create an AWS Account and enter the required information on the following page.
    

    Field	Description	Tips
    Email address	A unique email address that identifies the AWS account and is the name of the AWS account root user.	Use the management AWS account root user email address that you already established. Be very careful that you enter the correct email address and that you have access to the email account.
    Password	A password for the AWS account root user.	Ensure that you secure this value. In a later step, you'll have the option to enable Multi-factor Authentication (MFA) - a highly recommended approach to help secure your AWS account.
    AWS account name	A brief identifier for the AWS account.	For example: management. This value does not have to be unique and can be modified later on.

    As you sign up, set your account to either personal or professional. Both types of accounts have the same functionality and features. Enter your personal or professional information and then read and accept the AWS Customer Agreement.

    Note: Professional accounts are accounts that are created for a business or at an enterprise level, whereas Personal accounts are created for learning and experimenting with AWS services. 
    

    Secure management account root user

    Once you have completed sign up, you will be logged in as the root administrative user of the account. It is important to secure the root user and follow the Best practices to protect your account's root user. Ensure you set AWS multi-factor authentication (MFA) on your AWS account root user account, as outlined here: Enable MFA on the AWS account root user. For more information, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

    Note: AWS supports Hardware, Virtual, and FIDO security key MFA devices. Compliance or the support team location may dictate what type of MFA device is leveraged for the root user. AWS foundational security best practices states to use a hardware-based MFA solution (reference FSBP-IAM-6).
    

    Configure management account

    The AWS management account root user has specific activities it can only complete within the account. After securing the root user account, it is important to complete these set of tasks. 

    In this section you will complete all of the necessary root user tasks in the management account to setup billing and support.
    

    Allow AWS Identity and Access Management (IAM) role access to billing

    Requires: root user

    By default, AWS does not provide access to any other IAM users or roles regardless of the permissions you give them. To enable the ability for IAM users, or roles, outside of the AWS root administrator account follow, the steps in the AWS Identity and Access Management User Guide. Once completed within the AWS management account, all AWS member accounts will inherit this setting.
    

    Set management account alternate contacts for operations, security, billing

    Requires: root user

    In order to keep the right people in the loop, you can add an alternate contact for Billing, Operations, and Security communications for the AWS account.

    To set these contacts in your management account, log in as root user and update the alternate contacts following the AWS Update standalone AWS account alternate contacts documentation. You should provide group email distribution groups for Billing, Operations, and Security.
    

    Configure billing and tax information

    Requires: root user or IAM billing enabled for IAM users and roles

    The AWS management account acts as the centralized billing entity, allowing you to receive a single invoice for all the AWS accounts within the organization. You will need to review and make any necessary changes to the billing console for the following details:

    1. Adding or Editing Tax Numbers
    2. Turning on tax setting inheritance
    3. Managing US tax exemptions
    4. Designate a payment method setting - pay by credit card or invoice
    5. Change billing contact information
       

    Select AWS support tier

    Requires: root user

    Review the different AWS Support plans. By default, all AWS accounts receive Basic support. If you would like to choose a higher level of support than Basic, follow the Changing AWS Support Plans steps in the AWS Support User Guide. If your intent is to have enterprise support, we recommend setting the support plan now instead of changing later on.
    

• Enabling foundational cost observability

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Enabling foundational cost observability 
    

    • Enable Cost Explorer
    • Setup Cost and Usage Reports
  • Overview

  • Set up the right mechanisms and tools to monitor your resources. These tools allow you to create reports, dashboards, and anomaly detection of the cloud spend of your budget. These also help you plan for cost optimization to avoid or reduce unnecessary costs.

    Supporting Cloud Foundations capability:
    

    • Cloud Financial Management
  • Implementation

  • Enable Cost Explorer

    AWS Cost Explorer is a tool that enables you to view and analyze your AWS costs and usage. Enabling AWS Cost Explorer in the management account allows you to analyze AWS cost and usage for your entire AWS Organization. In order to use Cost Explorer, it must be enabled. Note that Cost Explorer will take approximately 24 hours to generate the current month’s costs. The trailing 12-month costs and 12-month forecast will be available a few days later. Also note that AWS Cost Explorer can only be enabled through the console.

    In this section, you will enable AWS Cost Explorer for your AWS environment.
    

    Enable Cost Explorer in the management account following the Cost Management user guide for enabling Cost Explorer.
    

    Setup Cost and Usage Reports

    The AWS Cost and Use Reports (AWS CUR) provide the most detailed cost and usage statistics available. You may utilize AWS Cost and Usage Reports to publish your AWS billing reports to a bucket owned by you on Amazon Simple Storage Service (Amazon S3). To find out more about AWS CUR, refer to the AWS documentation What are AWS Cost and Usage Reports.

    In this section, you will setup Cost and Usage Reports for your AWS environment.
    

    Create Amazon S3 Bucket for Cost and Usage Reports

    You will need to create an Amazon S3 bucket to use as a destination for AWS CUR. You can create this S3 bucket in the console as you create the Cost and Usage report, or follow the instructions for Setting up an Amazon S3 bucket for Cost and Usage Reports.
    

    Enable Cost and Usage Reports

    Create and configure Cost and Usage reports (CURs) following the AWS Cost and Usage Reports User Guide.

    Below is a suggested configuration for your first Cost and Usage report:
    

    Parameter	Description	Recommendation
    Report Name	The name for this Cost and Usage report	cur-hourly
    S3 Bucket	The S3 bucket that will be used to receive and store your Cost and Usage reports.	You can create this bucket in the console as you create your Cost and Usage report.
    Report path prefix	A prefix that will be prepended to the name of your report.	cur-hourly
    Time Granularity	The time granularity on which report data are measured and displayed.	hourly
    Enable report data integration for	Determines the data format to allow integration with Amazon Athena, Amazon Redshift, or Amazon QuickSight.	Amazon Athena

    The Cost and Usage report will take up to 24 hours to generate. For how to view and understand your report, refer to the AWS Cost and Usage Reports user guide section on Managing reports.
    

• Deploying identity management

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Deploying identity management
    

    • Deploy AWS IAM Identity Center
    • Create AWS IAM Identity Center standard assignments
    • Configure AWS IAM Identity Center
    • Discontinue use of management account root user
  • Overview

  • Federated identity management allows you to efficiently manage the access to the environment, and should be established and operated centrally. By managing your identities and controlling access to your environment centrally, you can quickly create, update, and delete the permissions and policies you need to meet your business requirements. From granting or revoking permissions to specific users or roles, or by establishing preventative controls on your overall environment, your security teams can manage access to the environment from one place.

    Supporting Cloud Foundations capability:
    

    • Identity Management & Access Control
  • Implementation
  • Deploy AWS IAM Identity Center

    AWS IAM Identity Center (successor to AWS Single Sign-On) enables a robust, federated identity management services into your AWS environment. It is recommended that you do not use AWS root user accounts except for activities that require it (reference AWS documentation for Root User Tasks). IAM Identity Center will enable you to create users and permission sets that you can assign to all AWS accounts within your environment. 

    In this section, you will establish your AWS Organization, enable IAM Identity Center, create an administrator that will be used instead of the AWS account root user, and create a read-only user.
    

    Enable IAM Identity Center

    Within your identified home Region follow the instructions to Enable IAM Identity Center.
    

    Create standard assignments

    IAM Identity Center needs to be configured to create user assignments to access your resources and your applications in your environment. You will need to setup standard permissions and roles that will facilitate role-based access.

    In this section, you will setup a management account administrator assignment and a read-only assignment that your team can use to administer your management account. 

    Create management account for IAM Identity Center admin users

    From the management account in the IAM Identity Center web console, you will need to add or create your additional management account administrators. The management account administrator team should be a small number of individuals that will have admin access to the management account. 

    Follow the Add user instructions from the IAM Identity Center documentation to add your management account admin users, creating a minimum of one new admin user for you.
    

    Create management account for IAM Identity Center permission sets

    From the management account in the IAM Identity Center web console, you will need to add or create the permission set for your management account administrators. Note that any permission set assigned to the management account cannot be leveraged or edited from the IAM Identity Center delegated admin AWS account.

    Follow the Create a permission set instructions from the IAM Identity Center documentation to create multi-account (MA) and read-only permission sets. Note that the MA-Administrator permissions set leverages a Predefined permission set whereas the MA-ReadOnly uses a Custom permission set:
    

    MA-Administrator

    Permission Set Name: MA-Administrator
    Permission Set Type: Predefined
    Description: Gives administrative access to the management account
    Tags: Add your defined mandatory tags to this permission set
    Associated Policies: Predefined permission set: AdministratorAccess 

    MA-ReadOnly

    Permission Set Name: MA-ReadOnly
    Permission Set Type: Custom
    Description: Gives read-only access to the management account
    Tags: Add your defined mandatory tags to this permission set
    Associated Policies: Custom Permission set: AWS managed policy ReadOnlyAccess
    

    Create management account for IAM Identity Center assignments

    From the management account in the IAM Identity Center console, you will need to assign your users to a permission set and to the management account. It is best practice to assign only users and not groups to the management account administrator assignment. Groups can be updated in the IAM Identity Center delegated admin account and could give unauthorized access to the management account.
    Follow the instructions below for assigning your management account users to both the MA-Administrator and MA-ReadOnly permission sets:

    1. Access AWS accounts in IAM Identity Center.
    2. Select the checkbox next to your management AWS account.
    3. Select Assign users and then select the user accounts you created for management account administration
    4. Select Next then select MA-Administrator or MA-ReadOnly for permission set
       

    The assignment will complete and your management account administrative users should be able to login and have access to the management account.
    

    Configure AWS IAM Identity Center

    IAM Identity Center (IdC) stores administrative permission settings that specify the amount of access granted to users and groups for an AWS account. After enabling IAM Identity Center and creating a permission set, the identity provider must be configured to support best practices. 

    In this section, you will configure IAM Identity Center to require users to setup multi-factor authentication, enable Attribute Based Access Control (ABAC), and you will create a customized IdC URL for your team to easily remember and access. 
    

    Set multi-factor authentication in AWS IAM Identity Center

    Enable multi-factor Authentication (MFA) for IAM Identity Center users. This is enabled from the IAM Identity Center web console by setting the option to Configure multi-factor authentication which will not allow users to log in for the first time until they configure an MFA device. Follow the IAM Identity Center User Guide to configure this setting using the below settings:
    

    Setting	Recommendation
    Prompt users for MFA	Only when their sign-in context changes (context-aware)
    Users can authenticate with these MFA types	Check the boxes: Security keys and built-in authenticators and Authenticator apps
    If user does not yet have a registered device	Require them to register an MFA device at sign in

    Enable Attribute-based access control in IAM Identity Center

    Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. Enable ABAC in IAM Identity Center by following the guidance for enabling attributes for access control.
    

    Configure IdC URL in IAM Identity Center

    To make accessing your AWS environment easier for your users, you can set a customized portal URL. Follow the Identity Center documentation at Customizing the AWS access portal URL to configure your customized portal URL.
    

    Note: If you are not sure what the custom URL will be, you can come back and complete this step later.
    

    Discontinue use of management account root user

    Your management account root user is used to configure your environment; however, now that IAM Identity Center is stood up, it is recommended to discontinue use of the root user account. Your root user will not be needed except for tasks that are defined in the AWS account root user credentials and IAM user credentials documentation.

    In this section, you will stop using the management account root user and login as the IAM Identity Center management account administrator.
    

    Login with your IAM Identity Center user account

    Using your IdC user account you created and the custom URL for your Identity Center, log in and start accessing the management account using the MA-Administrator role.
    

• Deploying AWS Control Tower

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Deploying AWS Control Tower
    

    • Prepare for AWS Control Tower deployment
    • Deploy AWS Control Tower
    • Configure AWS Control Tower Account Factory
  • Overview

  • Your environment will include AWS accounts outside of the AWS management account. These accounts are used to group workloads that have a common business purpose.

    It is time consuming to manually create accounts and apply governance and security configurations. It will often lead to inconsistent configurations that can create security vulnerabilities or unnecessary resources being deployed. We recommend that you configure an orchestration mechanism to simplify the management of your AWS environment.

    AWS Control Tower is a managed service that orchestrates the deployment of resources to apply a consistent security configuration baseline across your AWS accounts and AWS environment. We recommend deploying AWS Control Tower as the orchestration tool to set up your initial AWS environment and apply post-deployment configurations. 

    
    Supporting Cloud Foundations capabilities:

    • Workload Isolation
    • Log Storage
    • Identity Management & Access Control
    • Resource Inventory Management
  • Implementation
  • Prepare for AWS Control Tower deployment

    Before you deploy AWS Control Tower, we recommend that you collect and document the configuration parameters for your initial AWS Control Tower deployment. This will help ensure you adhere to the policies when setting up your environment on AWS and follow a naming convention from the start, allowing you to scale later on.

    There are a set of one-time decisions for your AWS Control Tower parameters that can’t be updated once the service is deployed, you can find a full list of these requirements here in the expectations for landing zone configuration section of the AWS Control Tower documentation.

    In this section you will identify the necessary input parameters for deploying AWS Control Tower.
    

    Create email for log archive and security tooling accounts

    To set up your landing zone with new shared accounts, AWS Control Tower requires two unique email addresses that aren't already associated with an AWS account. Each of these email addresses will serve as the root user account and the collaborative inbox — a shared email account — intended for the various users in your enterprise that will do specific work related to AWS Control Tower.

    We recommend that you document your naming convention for these accounts so that they can be intuitively identified by your cloud team and supporting staff. The following is an example of the Log Archive and Security Tooling accounts:
    

    • aws-company-security-tooling-prod@example.com
    • aws-company-log-storage-prod@example.com

    Create AWS Key Management Services key administration role in the management account

    To create a role for that can be assumed to manage the AWS Key Management Service (AWS KMS), follow the instructions below: 

    1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
    2. In the navigation pane of the IAM console, choose Roles, and then choose Create role.
    3. For Select trusted entity, choose Custom trust policy. 
    4. Locate the Custom trust policy text box and enter the following policy replacing [Account ID] with your Account ID. Then, choose Next.

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AssumeForKmsManagement",
          "Effect": "Allow",
          "Principal": {"AWS":"arn:aws:iam::[Account ID]:root"},
          "Action": "sts:AssumeRole"
        }
      ]
    }

    Code snippet copied

    Copy

    5. In the Add permissions page search for: AWSKeyManagementServicePowerUser and click next.
    6. For Role name enter “ControlTower-KmsManager”.
    7. For Description enter “Foundational role for managing Control Tower KMS”.
    8. Add any Tags needed.
    9. Review the role and then choose Create role button at the bottom of the page.

    Create AWS KMS key for Control Tower encryption

    In order to encrypt your AWS Control Tower resources with a customer managed key, you will need to create an AWS KMS key in your home Region. This key will be used to encrypt AWS CloudTrail, and the AWS Config and AWS CloudTrail logs stored in the Log Storage bucket.

    Create an AWS KMS key in your home Region following the AWS KMS guidance on creating keys with the below configuration.
    

    Parameter	Description	Recommendation
    Key Type	AWS KMS supports several types of KMS keys: symmetric encryption keys, symmetric HMAC keys, asymmetric encryption keys, and asymmetric signing keys.	Symmetric (default)
    Key Usage	The key usage of a KMS key determines whether the KMS key is used for encryption and decryption, or signing and verifying signatures, or generating and verifying HMAC tags.	Encrypt and Decrypt (default)
    Key Material Origin	Key material origin is a KMS key property that identifies the source of the key material in the KMS key.	KMS (default)
    Regionality	AWS KMS supports single-Region and multi-Region keys.	Single Region (default)
    Alias	An alias is a friendly name for a AWS KMS key. For example, an alias lets you refer to a KMS key as test-key instead of 1234abcd-12ab-34cd-56ef-1234567890ab.	Use an alias that clearly defines the key as the AWS Control Tower KMS key (such as: ControlTowerKmsKey)
    Administration Policy	A key policy is a resource policy for an AWS KMS key. Key policies are the primary way to control access to KMS keys. The Administration policy determines what principle(s) will have permissions to manage the key.	Choose the KMS key administration role that you have created in the management account.
    Usagae policy	A key policy is a resource policy for an AWS KMS key. Key policies are the primary way to control access to KMS keys. The Usage policy determines what principle(s) will have permissions to use the key.	If you are using the console to create the KMS key, Choose the KMS key administration role that you have created in the management account.

    Update the KMS key policy following the guidance on managing your Control Tower KMS key that allows AWS CloudTrail and AWS Config permission to use the key.
    

    Document required parameters 

    During AWS Control Tower setup, you need to apply several parameters for deployment. Review the table below and document your parameters when preparing for your AWS Control Tower deployment.
    

    Parameter	Description	Recommendation
    Home Region	AWS Region where you are deploying control tower	We recommend using the Home Region you identified for overall management operations.
    Region Deny Settings	The Region deny feature prohibits access to AWS services based on your AWS Control Tower Region configuration. It denies access to AWS Regions with status Not governed.	Enable. This will prohibit access to AWS services outside of the Control Tower Managed Regions.
    Additional AWS Regions for governance	Regions governed by AWS Control Tower in addition to the home Region.	Identify all operational Regions where you are deploying and managing your cloud services.
    Foundational OU	AWS Control Tower creates an operational unit (OU) [CD1] [MOU2] for you with the default name of Security.	Leave default name of Security.
    Additional OU	To help set up a multi-account system, AWS Control Tower recommends you create a secondary OU when setting up your landing zone.	Leave the default settings to create a Sandbox OU.
    AWS Account Log Archive alias	During setup, you can select the account alias for your Log Archive shared service AWS account.	We recommend that you change the default "Log Archive" account to "log-archive-prod".
    AWS Account Log Archive email	During deploy, you will need to specify the email address for the log archive shared service account.	Follow your defined naming convention for creating an email address for a shared service account. Example: aws-logarchive-org1@example.com
    AWS Account Audit alias	During setup, you can select the account alias for your security audit account shared service account.	We recommend that you change the default "audit" account to "security-tooling-prod".
    AWS Account Audit email	During deploy, you will need to specify the email address for the security audit shared service account.	Follow your defined naming convention for creating an email address for a shared service account. Example: aws-securitytooling-org1@example.com
    AWS CloudTrail	AWS Control Tower allows you to deploy CloudTrail per account or AWS Organization basis.	Enabled
    Log Retention	AWS Control Tower allows you to specify the retention for AWS CloudTrail and AWS Config logs in a centralized S3 Bucket.	Select a duration that meets your compliance or governance needs.
    OU Names	You can select your top-level OU names during setup, and you also can change OU names after you've set up your landing zone.	We recommend you keep the default names for the OUs.
    Control Tower Admin User	AWS Control Tower will request that you give a name and email address for the initial admin user.	We recommend that the user deploying AWS Control Tower to provide their details and email address to immediately sign in as Control Tower deploys. Additional users can be added later.
    KMS Encryption	AWS Control Tower allows you to use a KMS key that you manage to encrypt the AWS Control Tower resources.	Enable and select the KMS key that you have created in the previous steps (ControlTowerKmsKey).

    Deploy AWS Control Tower

    The AWS Control Tower quick start procedure assumes that you'll accept the default values for the resources in your AWS Control Tower environment. Many of these choices can be changed later. A few one-time choices are listed in the section called Expectations for landing zone configuration.

    AWS Control Tower will deploy and configure the basic multi-account environment in your environment, creating a Security Organizational Unit (OU) and an additional OU of your choice, typically the Sandbox Organizational Unit. You will need to expand this basic organization structure later, once your AWS Control Tower Landing Zone is set up. 

    In this section you will deploy Control Tower using your specific configurations.
    

    Deploy AWSControl Tower in home Region

    Deploy AWS Control Tower in your home Region using the parameters that you have documented by following the AWS Control Tower Getting Started user guide.
    

    Note: After you complete the steps in the Getting Started with AWS Control Tower documentation and your initial Landing Zone is completed, you can proceed to build your foundational OU structure.
    

    Note: If you are using a new AWS account with no prior history, you may receive an error message indicating that AWS Control Tower detected issues with your AWS account environment that prevented successful setup. To resolve this, launch a Free tier eligible EC2 instance, such as a t2.micro, wait 10-15 minutes, and retry the setup. You can terminate the launched instance once the AWS Control Tower installation is started.

    Configure AWS Control Tower Account Factory

    The AWS Control Tower account factory enables customers to provision accounts in your organization under the governance of AWS Control Tower. AWS Control Tower account factory is configured, by default, to provision a virtual private cloud (VPC) and subnet in each new account.

    We recommend changing this default setting to not provision a default VPC(s) in new accounts. This will allow for greater control of your VPCs, subnets, and classless inter-domain routing (CIDR) ranges.
    

    Remove default VPC provisioning from AWS Control Tower account factory

    From the management account, follow the Configure Amazon VPC settings guidance in the AWS Control Tower User Guide to modify the account factory network configuration. Uncheck all of the Regions in the ‘Regions for VPC creation’ section of the account factory network configuration screen and select save. 
    

• Building a foundational OU structure

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Building a foundational OU structure 
    

    • Create Infrastructure OU
    • Create Workloads OU
    • Create Exceptions OU
  • Overview

  • An Organizational Unit (OU) is virtual container used by AWS Organizations to classify and organize AWS accounts and administer them as a single unit. For example, you can attach a policy-based control to an OU, and all accounts within the OU will automatically inherit the policy. 

    By starting with a subset of the AWS Multi-Account Strategy Recommended OUs, you will have an organizational structure that allows you to start building out your environment and workloads and allow you to create additional recommended OUs as they are needed.

    Supporting Cloud Foundations capability:
    

    • Workload Isolation
  • Implementation
  • Create Infrastructure OU

    The Infrastructure Organizational Unit (OU) is intended for shared infrastructure services. It will be used to hold AWS accounts containing AWS infrastructure resources that are shared or utilized by the rest of the organization. No application accounts or application workloads are intended to exist within this OU. For more information visit the Organizing Your AWS Environment - Infrastructure OU whitepaper.

    In this section you will deploy the Infrastructure OU from AWS Control Tower.
    

    Create Infrastructure OU from Control Tower

    Follow the AWS Control Tower documentation to create and enroll a top-level OU (select Root for the Parent OU) named Infrastructure. 
    

    Note: It will take several minutes for Control Tower to create and register the OU.
    

    Create Workload OU

    The Workloads Organizational Unit (OU) is intended to hold your business-specific workloads including both production and non-production environments. To maintain a clear separation between production and non-production workloads, you will be able create a Production and one or more Non-production OUs within the Workload OU. Reference the Organizing Workload-oriented OUs section of the AWS multi-account strategy whitepaper for more information.

    In this section you will deploy the Workload OU from AWS Control Tower.
    

    Create Workloads OU from Control Tower

    Follow the AWS Control Tower documentation to create and enroll a top-level OU (select Root for the Parent OU) named Workloads.
    

    Note: It will take several minutes for Control Tower to create and register the OU.
    

    Create Exceptions OU

    The Exceptions Organizational Unit (OU) is designed to be a service control policy (SCP) exception OU. Therefore, SCPs should not be attached to this OU outside of the AWS Control Tower mandatory preventative controls Instead, SCPs should be attached directly to the accounts within this OU to provide the flexibility to manage different types of exceptions. For more information, visit the Organizing Your AWS Environment whitepaper.

    In this section you will deploy the Exceptions OU from AWS Control Tower.
    

    Create Exceptions OU from Control Tower

    Follow the AWS Control Tower documentation to create and enroll a top-level OU (select Root for the Parent OU) named Exceptions. 
    

    Note: It will take several minutes for Control Tower to create and register the OU.
    

• Establishing tagging

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Establishing tagging 
    

    • Create a tagging dictionary
    • Create tagging policies
    • Enable Cost Allocation Tags
  • Overview

  • A tag is a key-value pair applied to a resource to hold metadata about that resource. Each tag is a label consisting of a key and an optional value. Not all services and resource types currently support tags (see Services that support the Resource Groups Tagging API). 

    It is essential to define a strategy to tag your resources as soon as possible during your cloud journey. As your overall environment expands and matures, this will enable you to identify resources or groups of resources quickly. When defining your tagging strategy, you need to determine the right tags that will help you gather all of the information across your environment.

    Supporting Cloud Foundations capability:
    

    • Tagging
  • Implementation
  • Create a tagging dictionary

    It is important to use a consistent approach to tagging your AWS resources. A tagging dictionary helps you achieve this consistency by maintaining and publishing:
    

    • A documented set of mandatory and optional tags
    • Definitions or purpose of each tag
    • Allowed tag values for each tag key (where applicable)
    • Proper case format of tag keys and values (tags are case sensitive)

    In this section you will build a tagging dictionary for your foundational environment.
    

    Define initial tagging dictionary

    As part of your tagging dictionary, you should define certain tags that can be used to access specific environments resources based on the tags attached to a role at a certain time. These tags can be used for a temporary escalation of privileges or for deploying changes through infrastructure as code that other identities may not have access otherwise.

    Below is a suggested set of mandatory tags that would be applied to all supported resources:
    

    Tag Key	Tag Purpose	Sample Tag Values	Observations
    Owner	This tag is used to indicate the owner of the resource.	SecurityLead, SecOps, Workload-1-Development-team	This value should represent a team or a title, given that humans come and go, but the function would remain within your environment.
    BusinessUnit	This tag indicates the business unit for the resource.	Finance, Retail, API-1, DevOps
    Environment	This Tag is used to indicate the lifecycle stage for the resource	Sandbox, Dev, PreProd, QA, Prod, Testing
    CostCenter	This Tag is used to indicate the cost center associated with the resource.	FIN123,Retail-123,Sales-248,HR-333
    FinancialOwner	This tag is used to indicate the Financial Owner associated with the resource.	HR, SecurityLead, DevOps-3, Workload-1-Development-team	This value should represent a team or a title, given that humans come and go, but the function would remain within your environment.
    Compliance	This tag is used to indicate if the resource is subject to any compliance requirement.	FN/A, NIST, HIPAA, GDPR

    Publish tagging dictionary

    The tagging dictionary needs to be made available to builders and stakeholders. This helps ensure that tags are applied consistently across the environment. Once an initial tagging dictionary is defined, publish it internally in a shared location. 
    

    Note: It is not necessary to publish the tagging dictionary to development teams yet. However, it is beneficial to publish this tagging dictionary to the engineers that are building out the environment so that the foundational resources can be tagged in accordance with the mandatory tags.
    

    Create tagging policies

    Tag Policies are a type of AWS organization policy that can help you standardize tags across resources in your organization's accounts by ensuring that predefined Tag Values are used. Tag policies can be configured to be Enforced which will disallow the creation of resources that do not adhere to the policy or Not Enforced which will allow you to audit the compliance of tags within your organization. To learn more about Tag policy enforcement, review the AWS Organizations User guidance on Understanding Enforcement.

    It is helpful to start with a non-enforced tagging policy which will allow you to audit your environment. As your tagging program matures, you will want to move toward an enforced and possibly more granular tagging strategy.

    In this section, you will enable tag policies, and create and attach a tagging policy that is not enforced.
    

    Enable tag policies

    From the Organizations console of the management account: 
    

    1. Select Policies
    2. Select Tag policies
    3. Select Enable tag policies
       

    Create a tagging policy

    From the Organizations console of the management account, follow the Creating a Tag Policy guidance in the AWS Organizations User Guide to create a Tag Policy based on your mandatory tag keys and predefined values.

    We recommend setting the below values for each Tag key:
    

    Checkbox	Description	Recommendation
    Tag key capitalization compliance	Enable this option if you want to mandate a specific capitalization for the tag key using this policy.	Check this box to enable capitalization compliance.
    Tag value compliance	This setting allows you to enter predefined tag values.	Check this box and enter allowed tag values for all tag keys with predefined tag values.
    Prevent noncompliant operations for this tag	This setting determines whether tag compliance will be enforced (noncompliant tag operations will not be permitted) or not enforced (noncompliant tag operations are allowed)	We recommend that you leave this option cleared (the default) which will allow resources to be created that have non-compliant tags but will allow you to report against non-compliant tags.

    Attach the tagging policy to organizational units

    Attach the Tag Policy to the Organizational Units (OUs) that you want to evaluate for tag compliance following the Attaching Tag Policy guidance in the AWS Organizations User Guide. We recommend that all of your accounts, including infrastructure and security accounts, adhere to the mandatory tagging rules that you have defined. Therefore, we recommend that you attach this tagging policy to all top-level OUs in the Organization.
    

    Note: We recommend that the tagging policy is set to Not Enforced to ensure that resources that do not adhere to the tagging policy can still be created. This allows you to track non-compliant resources to your tag policy. 
    

    Validate tag compliance reports for the organization

    The status of your tag compliance can be viewed from the AWS Resource Group console. Review the Evaluating organization-wide compliance guidance in the AWS Resource Group user guide to understand how to evaluate tag compliance.
    

    Note: It can take up to 48 hours for changes to a tag policy or resources to be reflected in the organization-wide compliance report so if you have just attached your first tag policy, you will not see any resources in the tag compliance reports.
    

    Enable Cost Allocation tags

    Cost allocation tags allow you to track your AWS costs on a detailed level. After you activate cost allocation tags, AWS uses the cost allocation tags to organize your resource costs on your cost allocation report to make it easier for you to categorize and track your AWS costs. AWS provides two types of cost allocation tags: AWS generated tags and user-defined tags.
    

    AWS-generated cost allocation tags

    The AWS generated tags createdBy is an AWS-generated cost allocation tag that AWS defines and applies to supported AWS resources for cost allocation purposes.

    To use the AWS generated tags, a management account owner must activate it in the Billing and Cost Management console. Management account owners can activate the AWS generated tags in the Billing and Cost Management console which activates this tag for all member accounts. This tag is visible only in the Billing and Cost Management console and reports.
    

    User Defined Cost allocation tags

    User-defined cost allocation tags are tags that you define, create, and apply to resources. After you have created and applied the user-defined tags, you can activate by using the Billing and Cost Management console for cost allocation tracking. 

    In this section you will enable Cost Allocation tags.
    

    Enable Cost Allocation tags

    Activate the AWS-generated cost allocation tags in the management account following the guidance in the AWS Billing User guide.
    

    Note: Cost allocation tags can take up to 24 hours to populate. If you don’t see any AWS-generated cost allocation tags in the AWS Billing console, return after 24 hours.
    

• Foundational hardening

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Foundational hardening 
    

    • Delegate IAM Identity Center
    • Harden member accounts
    • Delete default network resources in Management Account
    • Configure management account alerting
    • Configure Identity and Access Management (IAM) password policy in management account
    • Set Amazon S3 public block access in accounts
    • Enable AWS Control Tower initial guardrails
    • Create and attach organization hardening SCPs
  • Overview

  • After deploying your basic foundational environment, we recommend you enhance the security of your environment by following a few hardening best practices. The foundational hardening actions will promote the overall security of your new environment and implement a least-privilege access model. The actions do this by isolating the management account, setting monitoring and alerting mechanisms in all of your AWS accounts, and removing unnecessary resources. 
    

    Supporting Cloud Foundations capabilities:
    

    • Identity Management & Access Control
    • Workload Isolation
  • Implementation
  • Enable AWS Account Management

    Manage the contact details for your member AWS accounts to help deliver timely information to the appropriate audience. These alternate contacts are used for messaging and alerting for the specific member AWS account activity. Every AWS account will have the following alternate account contacts:
    

    • Billing – The alternate billing contact will receive billing-related notifications, such as invoice availability notifications.
    • Operations – The alternate operations contact will receive operations-related notifications.
    • Security – The alternate security contact will receive security-related notifications, including notifications from the AWS Abuse Team.

    In this section, you will enable the ability to manage these member AWS account alternate contacts across your entire AWS Organization and then update all member account alternate contacts.
    

    Enabling trusted access for AWS Account Management

    To enable the management account in your organization to call the AWS Account Management API operations for other member accounts in the organization, follow the steps on the Enabling trusted access for AWS Account Management.
    

    Set member account alternate contacts for operations, security, billing

    In order to keep the right people notified, you need to add an alternate contact for Billing, Operations, and Security communications for the AWS account.

    To set these contacts in your member accounts, log in to your management account using a role with AWS Organizations administrator and update the alternate contacts following the AWS. Update member AWS account alternate contacts documentation. You should provide email distribution groups for Billing, Operations, and Security for any newly created AWS account. 

    Delegate AWS IAM Identity Center

    Delegated administration provides a convenient way for assigned users in a registered member account to perform most IAM Identity Center administrative tasks. Even though your IAM Identity Center instance must always reside in the management account, you can choose to delegate administration of IAM Identity Center to a member account in AWS Organizations, thereby extending the ability to manage IAM Identity Center from outside the management account.

    In this section you will create an AWS account and delegate IAM Identity Center management operations to the new account.
    

    Create IAM Identity Center Account

    Follow the steps on the Provision Account Factory accounts with AWS Service Catalog to create the IAM Identity Center AWS account in the Infrastructure OU. This account will manage all AWS Organization member account access from IAM Identity Center. When creating a new account, you can specify a user email address. For the IAM Identity Center account, specify your administrator email account you setup earlier. In doing this, you will not create a new user account, but use your already created user account.
    

    Note: The account does not manage any IAM Identity Center assignments for the management account, nor can any permission set leveraged in an assignment to the management account be managed from the IAM Identity Center account.
    

    Delegate IAM Identity Center

    While logged into the AWS management account, follow the instructions to Register a member account for delegating AWS Identity Center administration to the Identity Center AWS account
    

    Harden member accounts

    Any AWS account created through AWS Control Tower or the AWS Organizations console will setup a new AWS account root user. By default, the password is not yet set for the account; however, the email address used to create the account can undergo the process of recovering the password in order to initially set the password.

    In this section, you will configure the password and enable MFA for the root user of the member account.
    

    Secure member account root users

    Follow the instructions for resetting lost or forgotten AWS password to set the password for your newly created AWS account root user.

    Once the password is set for the AWS account root user, you should enable MFA for the AWS account root user.

    To enable MFA for the root user:

    1. Sign in to the AWS Management Console at https://console.aws.amazon.com/
    2. On the right side of the navigation bar, choose your account name, and then choose My Security Credentials.
    3. If necessary, choose Continue to Security Credentials.
    4. Expand the Multi-Factor Authentication (MFA) section.
    5. Choose Activate MFA.
    6. Follow the wizard instructions to configure your MFA devices accordingly. For more information, see Enabling MFA devices for users in AWS (IAM documentation).
       

    Delete default network resources in Management Account

    When you create a new account, a default VPC is available in each AWS Region. A default VPC comes with a public subnet in each Availability Zone, an internet gateway, and settings to enable DNS resolution. AWS Control Tower will remove the default VPC from the AWS Control Tower governed Regions of Control Tower created accounts; however it will not remove resources from your management account. Due to this, we recommend you delete the management account default VPCs yourself.

    We recommend deleting the default VPCs in the management account all Regions.

    In this section you will remove the default VPC resources in your management account.
    

    Delete default VPCs in each Region of the management account

    Follow the below steps to delete the default VPCs in each Region of the management account:

    1. In the AWS Management Console change to the Region you plan to work in. This Region selection is in the upper right-hand drop-down menu. 
    2. In the AWS Management Console, choose Services then select VPC.
    3. From the left-hand menu select Your VPCs.
    4. In the main panel, the checkbox next to only VPC (the default VPC) should be
       highlighted. You can verify this is the default VPC by scrolling to the right. The Default VPC column will be marked with Yes.
    5. With our default VPC checked, select the Actions dropdown above it and select Delete VPC.
    6. In the Delete VPC Panel, check the box 'I Acknowledge that I want to delete my default VPC' and select the Delete VPC button in the bottom right.
    7. Confirm deletion by typing ”delete default vpc” in the confirm deletion field.
    8. You should get a green highlighted dialog stating 'The VPC was deleted' and you can select Close. If it is red, then likely something is deployed into this VPC and you will have to remove those resources (items such as EC2 instances, NAT Gateway, VPC endpoints. All of which would prevent your VPC from deleting). You could also consider another Region from the list above.
       

    Configure management account alerting

    AWS Control Tower configures the organization AWS CloudTrail to send CloudTrail events to an Amazon CloudWatch Log group in the management account. This allows you to create a CloudWatch alarm based on log patterns in a CloudTrail CloudWatch Log group. Because Service Control Policies do not apply to the management account, it is important to configure alerting in the management account on unwanted events. In this section, you will create an alert and notification for root user login events.
    

    Create Alarm for root user login in the management account

    In the home Region of your management account, follow the steps in Creating a metric filter in CloudWatch from the CloudWatch User Guide to create a metric filter. This metric filter will identify root user activity using the AWS CloudTrail log group. You will create this metric filter for the log group ‘aws-controltower/CloudTrailLogs’ using the below parameters. 
    

    Note: Make sure you tag your metric filter with the correct values that you decided on during the creation of your tagging dictionary.
    

    Parameter	Description	Recommendation
    Filter Pattern	The pattern that will be used to match terms in log events.	{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
    Filter name	Name to identify the metric filter.	RootUserActivityFilter
    Metric namespace	The metric namespace is a container for CloudWatch metrics. The metric filter will create a CloudWatch metric within this namespace. This namespace should be used for all management account CloudTrail based metric filters.	LogMetrics
    Metric name	The CloudWatch metric name for this metric. It must be unique within the namespace.	RootUserActivity
    Metric value	Metric value is the value published to the metric name when a Filter Pattern match occurs.	1
    Default value	The default value is published to the metric when the pattern does not match. If you leave this blank, no value is published when there is no match.	(leave blank/default)

    Create alarm

    Create the CloudWatch Alarm for the metric filter that you have created. 

    1. Go to the ‘aws-controltower/CloudTrailLogs’ CloudWatch Log Group in the home Region of the management account
    2. Select Metric filters
    3. Select the check box for the Metric filter that you have created (example: ‘RootUserLogin’) 
    4. Select Create alarm
    5. Create the alarm using the below parameters:
       

    Parameter	Description	Type	Recommendation
    Statistic	The statistic for the metric specified in MetricName.	Metric and conditions	Sum (default)
    Period	The length, in seconds, used each time the metric specified in Metric Name is evaluated. Valid values are 10, 30, and any multiple of 60.	Metric and conditions	5 minutes (default)
    Threshold type	The type of threshold for the alarm (Static or Anamoly Detection).	Metric and conditions	Static (default)
    Alarm Condition	The condition that will cause the alarm to trigger.	Metric and conditions	Greater/Equal
    Threshold value	The value that defines the threshold where the alarm will trigger.	Metric and conditions	1
    Alarm State Trigger	The alarm state that will trigger a defined action. In this example, it will trigger sending a notification to the Amazon Simple Notification Service (Amazon SNS) topic.	Notification	In Alarm
    Amazon SNS Topic	The Amazon SNS  topic where the alarm notification will be sent when the alarm is "in alarm" state.	Notification	Create new topic
    New Topic name	Unique name of new Amazon SNS  topic name	Amazon SNS  configuration	ManagementAccountCloudWatchAlarm For future managment account alarms in the home Region, we recommend using the same Amazon SNS  topic.
    Email endpoints	Email endpoints that will receive the notification of alarm.	Amazon SNS  configuration	Use email(s) that you want to receive the alerts. You must Confirm the subscription from the email after you configure alarm.
    Alarm Name	Name for the CloudWatch Alarm	Name and Description	RootUserActivityAlarm

    Note: Make sure you tag your metric alarm with the correct values that you decided on during the creation of your tagging dictionary.
    

    Configure IAM password policy in management account

    You can set a custom password policy on your AWS account to specify complexity requirements and mandatory rotation periods for your IAM users' passwords. If you don't set a custom password policy, the default AWS password policy will be used. For more information, see Setting an account password policy for IAM users in the AWS IAM documentation.

    In this section you will set the IAM password policy for security and compliance.
    

    Configure password policy to company standard in management account

    Create a custom password policy to enhance your security posture:

    • Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam
    • In the navigation pane, choose Account settings.
    • In the Password policy section, choose Change password policy.
    • Select the options that you want to apply to your password policy, and then choose Save changes.
      

    Set Amazon S3 public block access in accounts

    By default, new Amazon S3 buckets and objects don't allow public access. However, users can modify bucket policies or object permissions to allow public access. Amazon S3 Block Public Access provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources. 

    Due to their function and criticality, your Foundational accounts should not contain Amazon S3 buckets that allow public access. By configuring Amazon S3 to block public access at the account level, you are able to ensure that data is not exposed publicly due to a misconfigured bucket.

    In this section, you will configure security controls to block public access for Amazon S3. 
    

    Configure Amazon S3 block public access in the management account

    From the management account, follow the Amazon S3 User Guide to configure Amazon S3 block public access at the account level.
    

    Configure Amazon S3 block public access in member accounts

    In each member account (all accounts except for the management account), follow the Amazon S3 User Guide to configure Amazon S3 block public access at the account level. 
    

    Note: If you have already created an Amazon S3 bucket that is providing public access, setting Amazon S3 block public access at the account level will disable this access. If public access to the S3 bucket is required, we recommend moving the Amazon S3 bucket to a Workload OU account that is dedicated to serving public Amazon S3 data. You would not enable Amazon S3 block public access on that account.
    

    Enable Control Tower initial controls

    Controls are governance rules for security, operations, and compliance that you can define and apply either across your AWS environment or to specific groups of accounts. AWS Control Tower provides a set of managed controls that you can apply to the Organizational Units (OUs) in your environment. AWS Control Tower mandatory controls are enabled and enforced by default and protect the resources and controls that AWS Control Tower creates and manages. Additional strongly recommended controls and elective controls can be enabled on desired OUs through the Control Tower console.

    Detective controls continuously monitor deployed resources for nonconformance and generate alerts when nonconformance is detected. You can automate responses to alerts to take action. For example, disallow public read access to Amazon S3 buckets. AWS Control Tower detective controls are implemented using AWS Config rules. 

    Preventive controls establish intent and prevent deployment of resources that don’t conform to your policies. For example, require AWS CloudTrail to be enabled in all accounts. AWS Control Tower preventative controls are implemented using Service Control Policies (SCPs).

    In this section, you will deploy additional detective and preventive controls outside of AWS Control Tower mandatory controls that are on by default.
    

    Apply Control Tower Detective Controls

    From the home Region of the management account, apply the detective controls that are applicable to the OUs within your environment. Follow the instructions from the Control Tower User Guide - Enable Controls on OU documentation to enable the detective controls on desired OUs. Reference the below table for a list of suggested detective controls by OU.

    Recommended detective controls:
    

    Control	AWS Control Tower Guidance	Behavior	Security OU	Infrastructure OU	Workloads OU	Sandbox OU	Exceptions OU
    Detect whether MFA for the root user is enabled	Strongly recommended	Detective	Yes	Yes	Yes	Yes	Yes
    Detect whether public read access to Amazon S3 buckets is allowed	Strongly recommended	Detective	Yes	Yes	Yes	No	Yes
    Detect whether public write access to Amazon S3 buckets is allowed	Strongly recommended	Detective	Yes	Yes	Yes	No	Yes
    Detect whether MFA is enabled for AWS IAM users of the AWS Console	Elective	Detective	Yes	Yes	Yes	Yes	Yes
    Detect whether MFA is enabled for AWS IAM users of the AWS Console	Elective	Detective	Yes	Yes	Yes	Yes	Yes

    Note: If you require detective controls that are not currently provided in AWS Control Tower, they can be applied as AWS managed Config rules or AWS Config Custom rules.
    

    Apply Control Tower Preventative Controls

    Apply the preventative controls that are applicable to the OUs within your environment. Follow the instructions from the Control Tower User Guide - Enable Controls on OU documentation to enable the preventative controls on desired OUs. Reference the below table for a list of suggested preventative controls by OU.

    Recommended preventative controls:
    

    Control	AWS Control Tower Guidance	Behavior	Security OU	Infrastructure OU	Workloads OU	Sandbox OU	Exceptions OU
    Disallow the creation of access keys for the root user	Strongly recommended	Preventive	Yes	Yes	Yes	Yes	No
    Disallow changes to the encryption configuration for S3 buckets	Elective	Preventive	*Yes	Yes	No	No	No
    Disallow changes to the logging configuration for S3 buckets	Elective	Preventive	*Yes	Yes	Yes	No	No
    Disallow changes to the lifecycle configuration for S3 buckets	Elective	Preventive	*Yes	Yes	No	No	No

    Info: *Yes in the above table recommends additional controls that work with the standard Control Tower deployment based on the use of the ControlTowerExecution role. This may prevent configuring Amazon S3 buckets to any accounts within the Security or Infrastructure OU if you do not use Customizations for Control Tower(CfCT) to configure them. If you enable the controls and decide not to use CfCT, you can display these controls.
    

    Note: If you require preventative controls that are not currently provided in AWS Control Tower, they can be applied as SCPs from the AWS Organizations console.
    

    Create and attach organization hardening SCPs

    Create and attach the SCP in the below example following the AWS Organizations guidance for creating and attaching SCPs.
    

    SCP	Description	SCP Target	Statement ID (Sid)
    Prevent Member from leaving the organization	This SCP will prevent accounts to leave the Organization.	All top level OUs except for Exceptions.	PreventMemberLeaveOrg
    Prevent resource sharing outside of the organization	This SCP Prevents the sharing resources outside of the AWS Organization, helping customers establish data boundaries.	All top level OUs except for Exceptions.	PreventResourceSharingOutsideOrg

    Below is an SCP with both policy statements from the above table combined into one SCP:
    

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "PreventMemberLeaveOrg"
          "Effect": "Deny",
          "Action": [
            "organizations:LeaveOrganization"
          ],
          "Resource": "*"
        },
        {
          "Sid": "PreventResourceSharingOutsideOrg"
          "Effect": "Deny",
          "Action": [
            "*"
          ],
          "Resource": [
            "*"
          ],
          "Condition": {
            "Bool": {
              "ram:AllowsExternalPrincipals": "true"
            }
          }
        }
      ]
    }

    Code snippet copied

    Copy

    You can reference the example SCPs provided in the AWS Organizations user guide for additional SCPs.
    

    Note: We recommend that you do not attach SCPs to the root of the organization because those policies will apply to all member accounts in the organization. Instead, for policies that you want to apply to the entire organization, we recommend attaching them to all top level OUs except for the Exceptions OU.
    

    Remove unnecessary IAM users

    To strengthen the security of your AWS account, delete any unnecessary IAM user credentials (passwords and access keys). We strongly recommend that your management account should not have any IAM users and that you use AWS Identity Center users for standard use. There are exceptions to having IAM users in your management account which include Break Glass user which is not covered in this guidance. All standard user web console and API access should be conducted through IAM Identity Center.

    In this section, you will delete any unneeded IAM users in your management account.
    

    Delete IAM users

    Log into the management account using the IAM Identity Center administrator user role and delete any unnecessary IAM users following the Deleting IAM users section of the IAM user guide.
    

    Deploy AWS Config in management account

    AWS Control Tower deploys AWS Config in each Control Tower governed Region of all member accounts. It does not deploy AWS Config in the management account. Because Service Control Policies do not affect the management account, it is not possible to deny Regions within the management account.

    Due to the critical nature of the management account, we recommend deploying AWS Config in each Region of the management account to track resources and allow alerting on those resources. You can follow the below manual steps or use automation to deploy AWS Config in all Regions of the management account.
    

    Note: If you use automation, ensure that you configure your home Region to Include global resources and configure the other Regions to not include global resources. 
    

    In this section, you will deploy AWS Config to all enabled Regions of the management account with a delivery channel that sends the AWS Config history and snapshots to the Control Tower logging bucket in the Log Archive account.
    

    Deploy AWS Config in the home Region of the management account

    In the CloudFormation console in the home Region of the management account, create a CloudFormation Stack and use the below Template Source URL and parameters (for parameters not in the table, you can leave the default values). This will deploy AWS Config in the home Region of the management account with a delivery channel configured to send the configuration snapshots and configuration history files to the Amazon S3 bucket in the Log Archive account.
    

    Setting	Setting Type	Recommendation
    Template Source URL	Stack Setting	https://cloudformation-stackset-sample-templates-us-east-1.s3.us-east-1.amazonaws.com/EnableAWSConfigForOrganizations.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    Support all resource types	Stack Parameter	TRUE
    Include global resource types	Stack Parameter	TRUE
    Central S3 bucket	Stack Parameter	Enter the AWS Control Tower Log S3 bucket. (eg. aws-controltower-logs-[Log Archive Account number]-[Home Region])
    Prefix for the specified Amazon S3 bucket	Stack Parameter	The Organization ID. (eg. o-v1234567). This can be found in the Settings section of the AWS Organization console in the management account)

    Deploy AWS Config in all non-home enabled Regions of the management account

    In the CloudFormation console in the home Region of the management account, create a CloudFormation StackSet and use the below parameters (for parameters not in the table, you can leave the default values). This will deploy AWS Config in all enabled Regions except for the home Region of the management account with a delivery channel configured to send the configuration snapshots and configuration history files to the Amazon S3 bucket in the Log Archive account.
    

    Setting	Setting Type	Recommendation
    Permissions	Permission Type	Self-service permissions *By default, CloudFormation will use the CloudFormation Roles created in previous steps.
    Template Source URL	StackSet details	https://cloudformation-stackset-sample-templates-us-east-1.s3.us-east-1.amazonaws.com/EnableAWSConfigForOrganizations.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    StackSet Name	StackSet details	ConfigNonHomeRegions
    Support all resource types	StackSet Parameter	TRUE
    Include global resource types	StackSet Parameter	TRUE
    Central Amazon S3 bucket	StackSet Parameter	Enter the AWS Control Tower Log S3 bucket. (example: aws-controltower-logs-[Log Archive Account number]-[Home Region])
    Prefix for the specified Amazon S3 bucket	StackSet Parameter	The Organization ID. (eg. o-v1234563). This can be found in the Settings section of the AWS Organization console in the management account)
    Account Numbers	Set Deployment Options	Enter the management account ID.
    Specify Regions	Set Deployment Options	Enter in All enabled Regions except for the home Region. *Note: you can check which Regions are enabled by clicking on the Region in the top right of the console. The enabled Regions are not grayed out.