AWS Control Tower

AWS Control Tower provides an automated way to set up and govern a secure, multi-account AWS environment called a landing zone. It implements AWS best practices for account structure, identity, logging, and compliance, and it does so on top of AWS Organizations rather than replacing it: Control Tower orchestrates Organizations, IAM Identity Center, CloudTrail, AWS Config, and Service Catalog into one coherent governance layer.

What It Sets Up

• Landing Zone: pre-configured multi-account environment with baseline security
• Account Factory: automated provisioning of new accounts with consistent configuration
• Guardrails (Controls): preventive (SCPs), detective (Config Rules), and proactive (CloudFormation hooks)
• Dashboard: centralized view of compliance across all accounts

Built-in Security

• Centralized CloudTrail logging to a protected Log Archive account
• Cross-account audit access via an Audit account
• Mandatory guardrails: disallow public S3 access, require EBS encryption, enforce CloudTrail
• IAM Identity Center integration for centralized access management

When to Use It

• New AWS environments - start with Control Tower from day one
• Existing environments - Control Tower can enroll existing accounts and OUs
• Regulated industries - built-in compliance guardrails for PCI DSS, HIPAA, NIST

Understanding Drift

Control Tower assumes it owns the resources it deploys. When someone modifies one of those managed resources directly, for example editing an SCP that Control Tower attached, moving an enrolled account between OUs in the Organizations console, or deleting a baseline Config rule, the environment enters a state Control Tower calls drift. Drifted controls are flagged in the dashboard and in the API: the ListEnabledControls operation reports a drift status per control, with values including DRIFTED, IN_SYNC, NOT_CHECKING, and UNKNOWN. Drift is not automatically repaired; you resolve it by re-registering the OU or repairing the landing zone, which reapplies the intended configuration.

How It Goes Wrong in Practice

The most common failure I see is the side-door account. A team needs a new AWS account quickly, so someone creates it directly in the Organizations console or invites an existing standalone account, bypassing Account Factory. The account joins the organization but is never enrolled in Control Tower, so none of the detective controls, baseline Config rules, or centralized logging apply to it. Months later that unenrolled account is where the public S3 bucket or the wide-open security group shows up, precisely because it lived outside the guardrails everyone assumed were universal. The fix is procedural as much as technical: make Account Factory the only sanctioned path for account creation, monitor for unenrolled accounts in the Control Tower console, and enroll stragglers promptly.

A close second is admins "fixing" managed resources by hand, which silently creates drift. An SCP edit in the management account can weaken a preventive control across an entire OU while the dashboard still looks green until the next drift scan surfaces it.

A Practical Check: Listing Enabled Controls

You can audit which controls are actually enabled on an OU, and whether any have drifted, with the Control Tower API:

aws controltower list-enabled-controls --target-identifier arn:aws:organizations::123456789012:ou/o-example/ou-1234-example

The response lists each enabled control with its statusSummary (deployment status of SUCCEEDED, FAILED, or UNDER_CHANGE) and its drift status. You can also pass a --filter to return only drifted controls, and --include-children to sweep child OUs in one call. Running this regularly, or wiring it into a scheduled Lambda, catches drift and failed control deployments long before an audit does.

Frequently Asked Questions

Does AWS Control Tower cost extra?

No. AWS states there is no additional charge for Control Tower itself. You pay for the underlying services it configures on your behalf: AWS Config configuration items and rule evaluations, CloudTrail, S3 storage for logs, Service Catalog, SNS, and CloudWatch. In practice the AWS Config bill is the line item that grows with account count and resource churn.

What is the difference between Control Tower and AWS Organizations?

Organizations is the underlying primitive: the account hierarchy, consolidated billing, and SCP mechanism. Control Tower is an opinionated automation layer that uses Organizations plus several other services to build and continuously govern a landing zone. You can run Organizations without Control Tower; you cannot run Control Tower without Organizations.

Can I adopt Control Tower in an existing AWS organization?

Yes. Control Tower can be set up in an existing organization and can enroll existing accounts and OUs, applying its baselines and controls to them. Plan the enrollment: preventive controls are SCPs, so enrolling an OU can restrict actions that workloads in those accounts previously relied on.