# What Is AWS Control Tower? AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices. AWS Control Tower *orchestrates* the capabilities of several other [AWS services](https://docs.aws.amazon.com//controltower/latest/userguide/integrated-services.html), including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour. Resources are set up and managed on your behalf. AWS Control Tower orchestration extends the capabilities of AWS Organizations. To help keep your organizations and accounts from *drift*, which is divergence from best practices, AWS Control Tower applies controls (sometimes called *guardrails*). For example, you can use controls to help ensure that security logs and necessary cross-account access permissions are created, and not altered. If you are hosting more than a handful of accounts, it’s beneficial to have an orchestration layer that facilitates account deployment and account governance. You can adopt AWS Control Tower as your primary way to provision accounts and infrastructure. With AWS Control Tower, you can more easily adhere to corporate standards, meet regulatory requirements, and follow best practices. AWS Control Tower enables end users on your distributed teams to provision new AWS accounts quickly, by means of configurable account templates in Account Factory. Meanwhile, your central cloud administrators can monitor that all accounts are aligned with established, company-wide compliance policies. In short, AWS Control Tower offers the easiest way to set up and govern a secure, compliant, multi-account AWS environment based on best practices established by working with thousands of enterprises. For more information about working with AWS Control Tower and the best practices outlined in the AWS multi-account strategy, see [AWS multi-account strategy: Best practices guidance](aws-multi-account-landing-zone.md#multi-account-guidance). ## Features AWS Control Tower has the following features: + **Landing zone** – A landing zone is a well-architected, [multi-account environment](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html#example-workloads-flat-structure) that's based on security and compliance best practices. It is the enterprise-wide container that holds all of your organizational units (OUs), accounts, users, and other resources that you want to be subject to compliance regulation. A landing zone can scale to fit the needs of an enterprise of any size. + **Controls** – A control (sometimes called a *guardrail*) is a high-level rule that provides ongoing governance for your overall AWS environment. It's expressed in plain language. Three kinds of controls exist: *preventive*, *detective*, and *proactive*. Three categories of guidance apply to controls: *mandatory*, *strongly recommended*, or *elective*. For more information about controls, see [How controls work](how-controls-work.md). + **Account Factory** – An Account Factory is a configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations. AWS Control Tower offers a built-in Account Factory that helps automate the account provisioning workflow in your organization. For more information, see [Provision and manage accounts with Account Factory](account-factory.md). + **Dashboard** – The dashboard offers continuous oversight of your landing zone to your team of central cloud administrators. Use the dashboard to see provisioned accounts across your enterprise, controls enabled for policy enforcement, controls enabled for continuous detection of policy non-conformance, and noncompliant resources organized by accounts and OUs. ## How AWS Control Tower interacts with other AWS services AWS Control Tower is built on top of trusted and reliable AWS services including AWS Service Catalog, AWS IAM Identity Center, and AWS Organizations. For more information, see [Integrated services](integrated-services.md). You can incorporate AWS Control Tower with other AWS services into a solution that helps you migrate your existing workloads to AWS. For more information, see [How to take advantage of AWS Control Tower and CloudEndure to migrate workloads to AWS](https://aws.amazon.com//blogs/mt/how-to-take-advantage-of-aws-control-tower-and-cloudendure-to-migrate-workloads-to-aws/). **Configuration, Governance, and Extensibility** + *Automated account configuration:* AWS Control Tower automates account deployment and enrollment by means of an Account Factory (or “vending machine”), which is built as an abstraction on top of provisioned products in AWS Service Catalog. The Account Factory can create and enroll AWS accounts, and it automates the process of applying controls and policies to those accounts. For more information about creating and provisioning accounts, see [Methods of provisioning](https://docs.aws.amazon.com//controltower/latest/userguide/methods-of-provisioning.html). + *Centralized governance:* By employing the capabilities of AWS Organizations, AWS Control Tower sets up a framework that ensures consistent compliance and governance across your multi-account environment. The AWS Organizations service provides essential capabilities for managing a multi-account environment, including central governance and management of accounts, account creation from AWS Organizations APIs, service control policies (SCPs), and resource control policies (RCPs). + *Extensibility:* You can build or extend your own AWS Control Tower environment by working directly in AWS Organizations, as well as in the AWS Control Tower console. You can see your changes reflected in AWS Control Tower after you register your existing organizations and enroll your existing accounts into AWS Control Tower. You can update your AWS Control Tower landing zone to reflect your changes. If your workloads require further advanced capabilities, you can leverage other AWS partner solutions along with AWS Control Tower. ## Are You a First-Time User of AWS Control Tower? If you’re a first-time user of this service, we recommend that you read the following: 1. If you need more information about how to plan and organize your landing zone, see [Plan your AWS Control Tower landing zone](planning-your-deployment.md) and [AWS multi-account strategy for your AWS Control Tower landing zone](aws-multi-account-landing-zone.md). 1. If you’re ready to create your first landing zone, see [Getting started with AWS Control Tower](getting-started-with-control-tower.md). 1. For information on drift detection and prevention, see [Detect and resolve drift in AWS Control Tower](drift.md). 1. For security details, see [Security in AWS Control Tower](security.md). 1. For information on updating your landing zone and member accounts, see [Configuration update management in AWS Control Tower](configuration-updates.md). # How AWS Control Tower works How it works This section describes at a high level how AWS Control Tower works. Your landing zone is a well-architected multi-account environment for all of your AWS resources. You can use this environment to enforce compliance regulations on all of your AWS accounts. ## Structure of an AWS Control Tower Landing Zone The structure of a landing zone in AWS Control Tower is as follows: + **Root** – The parent that contains all other OUs in your landing zone. + **Security OU** – This OU contains the Log Archive and Audit accounts. These accounts often are referred to as *shared accounts*. When you launch your landing zone, you can choose customized names for these shared accounts, and you have the option to bring existing AWS accounts into AWS Control Tower for security and logging. However, these cannot be renamed later, and existing accounts cannot be added for security and logging after initial launch. + **Sandbox OU** – The Sandbox OU is created when you launch your landing zone, if you enable it. This and other registered OUs contain the enrolled accounts that your users work with to perform their AWS workloads. + **IAM Identity Center directory** – By default, this directory houses your IAM Identity Center users. It defines the scope of permissions for each IAM Identity Center user. Optionally, you can choose to self-manage your identity and access control. For more information, see [Working with AWS IAM Identity Center and AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/sso.html). + **IAM Identity Center users** – These are the identities that your users can assume to perform their AWS workloads in your landing zone. ## What happens when you set up a landing zone When you set up a landing zone, AWS Control Tower performs the following actions in your management account on your behalf: + Creates two AWS Organizations organizational units (OUs): Security, and Sandbox (optional), contained within the organizational root structure. + Creates or adds two shared accounts in the Security OU: the Log Archive account and the Audit account. + Creates a cloud-native directory in IAM Identity Center, with preconfigured groups and single sign-on access, if you choose the default AWS Control Tower configuration, or it allows you to self-manage your identity provider. + Applies all mandatory, preventive controls to enforce policies. + Applies all mandatory, detective controls to detect configuration violations. + *Preventive controls are not applied to the management account.* + Except for the management account, controls are applied to the organization as a whole. **Safely Managing Resources Within Your AWS Control Tower Landing Zone and Accounts** + When you create your landing zone, a number of AWS resources are created. To use AWS Control Tower, you must not modify or delete these AWS Control Tower managed resources outside of the supported methods described in this guide. Deleting or modifying these resources will cause your landing zone to enter an unknown state. For details, see [Guidance for creating and modifying AWS Control Tower resources](getting-started-guidance.md) + When you enable optional controls (those with *strongly recommended or elective * guidance), AWS Control Tower creates AWS resources that it manages in your accounts. Do not modify or delete resources created by AWS Control Tower. Doing so can result in the controls entering an unknown state. # What are the shared accounts? In AWS Control Tower, the shared accounts in your landing zone are provisioned during setup: the management account, the log archive account, and the audit account. ## What is the management account? This is the account that you created specifically for your landing zone. This account is used for billing for everything in your landing zone. It's also used for Account Factory provisioning of accounts, as well as to manage OUs and controls. **Note** It is not recommended to run any type of production workloads from an AWS Control Tower management account. Create a separate AWS Control Tower account to run your workloads. For more information, see [Management account](special-accounts.md#mgmt-account). ## What is the log archive account? This account works as a repository for logs of API activities and resource configurations from all accounts in the landing zone. For more information, see [Log archive account](special-accounts.md#log-archive-account). ## What is the audit account? The audit account is a restricted account that's designed to give your security and compliance teams read and write access to all accounts in your landing zone. From the audit account, you have programmatic access to review accounts, by means of a role that is granted to Lambda functions only. The audit account does not allow you to log in to other accounts manually. For more information about Lambda functions and roles, see [Configure a Lambda function to assume a role from another AWS account](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-assume-iam-role). For more information, see [Audit account](special-accounts.md#audit-account). # How controls work A control is a high-level rule that provides ongoing governance for your overall AWS environment. Each control enforces a single rule, and it's expressed in plain language. You can change the elective or strongly recommended controls that are in force, at any time, from the AWS Control Tower console or the AWS Control Tower APIs. Mandatory controls are always applied, and they can't be changed. Preventive controls prevent actions from occurring. For example, the elective control called **Disallow Changes to Bucket Policy for Amazon S3 Buckets** (Previously called **Disallow Policy Changes to Log Archive**) prevents any IAM policy changes within the log archive shared account. Any attempt to perform a prevented action is denied and logged in CloudTrail. The resource is also logged in AWS Config. Detective controls detect specific events when they occur and log the action in CloudTrail. For example, the strongly recommended control called **Detect Whether Encryption is Enabled for Amazon EBS Volumes Attached to Amazon EC2 Instances** detects whether an unencrypted Amazon EBS volume is attached to an EC2 instance in your landing zone. Proactive controls check whether resources are compliant with your company policies and objectives, before the resources are provisioned in your accounts. If the resources are out of compliance, they are not provisioned. Proactive controls monitor resources that would be deployed in your accounts by means of CloudFormation templates. *For those who are familiar with AWS:* In AWS Control Tower preventive controls are implemented with service control policies (SCPs) and resource control policies (RCPs). Detective controls are implemented with AWS Config rules. Proactive controls are implemented with CloudFormation hooks. ## Related Topics + [Detect and resolve drift in AWS Control Tower](drift.md) ## How AWS Control Tower works with StackSets AWS Control Tower uses CloudFormation StackSets to set up resources in your accounts, by default. Each stack set has StackInstances that correspond to accounts, and to AWS Regions per account. AWS Control Tower deploys one stack set instance per account and Region. AWS Control Tower applies updates to certain accounts and AWS Regions selectively, based on CloudFormation parameters. When updates are applied to some stack instances, other stack instances may be left in **Outdated** status. This behavior is expected and normal. When a stack instance goes into **Outdated** status, it usually means that the stack corresponding to that stack instance is not aligned with the latest template in the stack set. The stack remains in the older template, so it might not include the latest resources or parameters. The stack is still completely usable. Here's a quick summary of what behavior to expect, based on CloudFormation parameters that are specified during an update: If the stack set update includes changes to the template (that is, if the `TemplateBody` or `TemplateURL` properties are specified), or if the `Parameters` property is specified, CloudFormation marks all stack instances with a status of **Outdated** prior to updating the stack instances in the specified accounts and AWS Regions. If the stack set update does not include changes to the template or parameters, CloudFormation updates the stack instances in the specified accounts and Regions, while leaving all other stack instances with their existing stack instance status. To update all of the stack instances associated with a stack set, do not specify the `Accounts` or `Regions` properties. For more information, see [Update Your Stack Set](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/stacksets-update.html) in the CloudFormation User Guide.