AWS Control Tower

• AWS Control Tower is a service designed to simplify the setup and governance of multi-account AWS environments using AWS Organizations.

• It provides pre-configured landing zones that follow best practices, ensuring security, compliance, and governance from day one.

• AWS Control Tower applies preventive and detective controls (guardrails) to help keep your organizations and accounts from divergence from best practices. 

Key Components of AWS Control Tower

AWS Control Tower consists of several essential components that help establish and govern a well-architected multi-account environment:

Landing Zone

• Landing zone is a pre-configured well-architected baseline for multi-account environment based on AWS recommended security & compliance best practices. 

• You can use this environment to enforce compliance regulations on all of your AWS accounts. 

• A typical landing zone includes:

• Management account – The root account responsible for governance.

• Log archive account – Stores security and audit logs.

• Audit account – Used for security monitoring and compliance checks.

• The structure of a landing zone in AWS Control Tower is as follows: 

  • Root OU – 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 – This directory houses your IAM Identity Center users. It defines the scope of permissions for each IAM Identity Center user.

  • IAM Identity Center users – These are the identities that your users can assume to perform their AWS workloads in your landing zone.

AWS Organizations

• AWS Control Tower relies on AWS Organizations to manage multiple AWS accounts centrally. Organizations enable:

  • Account structuring – Using Organizational Units (OUs) to categorize accounts.

  • Service control policies (SCPs) – To enforce security and compliance rules.

Controls

• Also known as guardrails.

• AWS Control Tower provides guardrails, which are pre-configured rules to ensure compliance and governance. These are divided into:

1. Preventive guardrails – Enforce policies before an action occurs (e.g., disallow public S3 buckets).

2. Detective guardrails – Identify policy violations and notify administrators (e.g., alert on disabled logging).

AWS Control Tower Account Factory

• The Account Factory is a feature that automates the creation of new AWS accounts with predefined configurations.

• Uses AWS Service Catalog to create accounts based on templates.

• Ensures all accounts comply with governance rules from the start.

AWS IAM Identity Center

• AWS IAM Identity Center allows centralized authentication and access control for multiple accounts. 

• AWS IAM Identity Center has been integrated with Azure Active Directory, and you can connect your existing Azure Active Directory to AWS Control Tower.

• Previously known as AWS SSO.

• It simplifies user management by:

  • Enabling role-based access control.

  • Supporting integration with external identity providers (e.g., SAML 2.0, Microsoft Active Directory).

Logging and Monitoring

• AWS Control Tower provides centralized logging and monitoring by integrating with:

  • AWS CloudTrail – Logs all API activities across AWS accounts.

  • AWS Config – Tracks resource configurations and compliance status.

  • Amazon S3 & AWS CloudWatch – Stores and monitors logs for security auditing.

How AWS Control Tower Works?

Set Up AWS Control Tower

• Enables AWS Organizations.

• Creates the landing zone with core accounts (management, audit, log archive).

• Configures security and compliance settings.

Manage Multiple AWS Accounts

• Use the Account Factory to create and provision new accounts.

• Organize accounts into Organizational Units (OUs) for better management.

Apply Security & Compliance Guardrails

• Implement preventive guardrails to block non-compliant actions.

• Use detective guardrails to monitor and alert on security issues.

Centralize Access Management with AWS SSO

• Assign permissions to users for different AWS accounts.

• Integrate with corporate identity providers (like Active Directory).

Monitor & Audit Activities

• Use AWS CloudTrail, AWS Config, and CloudWatch to track activities and ensure compliance.

AWS CONTROL TOWER Use Cases

• Enterprises managing multiple AWS accounts and wanting centralized governance.

• Organizations needing compliance enforcement (e.g., GDPR, HIPAA).

• Startups and businesses looking for an easy way to establish secure AWS environments.

• MSPs (Managed Service Providers) managing cloud infrastructure for clients.

How CONTROLs (Guardrails) WORK?

• 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 APIs. 

• Mandatory controls are always applied, and they can't be changed. 

• Guardrails in AWS Control Tower are governance rules designed to enforce security, compliance, and operational best practices across multiple AWS accounts. 

• They help organizations maintain control over their cloud environments while allowing teams to work efficiently.

• AWS Control Tower offers two types of guardrails:

  1. Preventive Guardrails – Restrict or block actions from occurring that violate policies.

  2. Detective Guardrails – Monitor and alert administrators about policy violations.

Preventive CONTROLS

• Preventive guardrails proactively block or restrict actions that could lead to non-compliance. 

• 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. 

• They are implemented through:

• AWS Organizations Service Control Policies (SCPs)

• IAM Policies

Detective CONTROLS

• 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. 

• They are implemented using:

• AWS Config Rules

• AWS CloudTrail Logging

PROACtive CONTROLS

• 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 are implemented with AWS CloudFormation hooks. 

Service control policies (SCPs) 

• Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. 

• SCPs do not grant permissions to the IAM users and IAM roles in your organization. No permissions are granted by an SCP. 

• An SCP defines a permission guardrail, or sets limits, on the actions that the IAM users and IAM roles in your organization can perform. 

• SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization.  

• SCPs affect only IAM users and roles that are managed by accounts that are part of the organization. 

• SCPs don't affect resource-based policies directly. 

• They also don't affect users or roles from accounts outside the organization. For example, consider an Amazon S3 bucket that's owned by account A in an organization. The bucket policy (a resource-based policy) grants access to users from account B outside the organization. Account A has an SCP attached. That SCP doesn't apply to those outside users in account B. The SCP applies only to users that are managed by account A in the organization.

• Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.

• If a user or role has an IAM permission policy that grants access to an action that is also allowed by the applicable SCPs, user or role can perform that action.

• If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action.

• SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.