Lesson 257 · AWS Learning Path

AWS 257: AWS Control Tower

Anil Jalela · Published Mar 9, 2026 · 12 min read

Why this matters to an architect

AWS Organizations gives building blocks; AWS Control Tower orchestrates an AWS-recommended multi-account landing zone using Organizations, IAM Identity Center, CloudFormation StackSets, Config, CloudTrail, Service Catalog, EventBridge, S3, SNS, and optional integrations. It can establish baselines, enroll accounts/OUs, provision accounts, deploy controls, report compliance, detect drift, and coordinate updates.

Control Tower is not a magic compliance certificate or a replacement for workload architecture. Its managed resources, landing-zone version, enabled integrations, governed Regions, baselines, controls, extensions, and account lifecycle form an operating system that must be owned and upgraded.

Outcomes

By the end, you can:

• distinguish landing zone, home/governed/denied Region, registered OU, enrolled account, baseline, control, and drift;
• compare classic landing-zone architecture with version 4.0's optional service integrations and organization structure;
• explain preventive, detective, and proactive controls and mandatory/strongly recommended/elective guidance;
• trace control implementation through SCP/RCP/declarative policy, Config rule, or CloudFormation hook;
• provision with Account Factory and explain AFT/customization ownership;
• enroll existing accounts safely and interpret AWSControlTowerExecution privilege;
• diagnose landing-zone, baseline, control, StackSet, account-move, trusted-access, and managed-resource drift;
• plan Region changes, landing-zone upgrades, OU/account updates, recovery, cost, and decommissioning.

History and current-version warning

AWS Control Tower became generally available in 2019 to automate a multi-account landing zone. Older diagrams commonly show a fixed Security OU containing Log Archive and Audit accounts, centralized CloudTrail/Config resources, IAM Identity Center, and Account Factory.

Those concepts remain useful, but landing zone 4.0 changed important assumptions:

• organization structure is customer-defined; Control Tower no longer always creates/manages a fixed Security OU;
• service integrations such as Config, CloudTrail centralized logging, security roles, access management, and Backup are explicitly enabled or disabled;
• each integration has a designated central account, and integration accounts must share an eligible parent OU directly under the organization root;
• Config and CloudTrail use separate dedicated resources, and a service-linked Config aggregator replaces legacy aggregators;
• drift notifications for 4.0+ use EventBridge in the management account rather than the former SNS-only pattern;
• AWS Control Tower/AWS Config baselines are not applied to the designated service-integration OU/accounts in the same way as normal governed workload OUs.

Always inventory landing-zone version and manifest/settings before applying an older runbook.

Control Tower vocabulary

The home Region, governed Regions, and workload Regions are not synonyms. Control Tower is available in selected Regions; controls and underlying services have their own Regional coverage.

Landing-zone architecture and trust

The management account owns the Control Tower control plane and highly privileged orchestration roles. Depending on version/settings, central accounts receive Config aggregation, CloudTrail logs, security/audit roles, or Backup integration. Workload accounts receive baseline roles, StackSet instances, recorders/delivery channels, EventBridge resources, policies, and controls according to configuration.

AWSControlTowerExecution in enrolled accounts is highly privileged and trusts the management account. Control Tower uses it to establish and update governance. Do not add unrelated policies, change trust, or use it as a human administrator role. Protect management-account principals that can assume/manage it and alert on use outside expected services/workflows.

Control Tower uses trusted access and service-linked roles across Organizations-integrated services. SCPs do not restrict service-linked roles. A green landing-zone status does not prove each integration account, member baseline, control, trail, recorder, bucket, key, or delivery path works.

Version 4.0 service integrations

A 4.0 design records each integration separately:

The API manifest's enabled flags must be explicit. Some baselines depend on others; for example, central security-role behavior can depend on central Config. Disabling Config removes availability for detective controls and several integrations/features, while preventive/proactive controls can remain. Use the current feature-comparison table before choosing a reduced landing zone.

During an upgrade from 3.3 or earlier, data is not simply moved into new buckets. Existing CloudTrail logging can continue in prior aws-controltower-logs-* resources while new Config data goes to dedicated aws-controltower-config-logs-* resources. Map retention, KMS, access, lifecycle, queries, SIEM ingestion, and old/new cost before upgrade.

Controls: behavior versus guidance

Controls have two independent classifications.

Behavior

• Preventive: blocks prohibited operations, implemented with Organizations SCPs, RCPs, or supported declarative policies. It prevents new disallowed actions but may not remediate old resources.
• Detective: evaluates resource configuration after/while it exists, generally using AWS Config rules. A noncompliant result is evidence to investigate/remediate; it does not itself stop creation.
• Proactive: checks supported resources before CloudFormation provisioning through hooks. It does not inspect resources created outside covered CloudFormation paths unless another control does.

Guidance

• Mandatory: applied as part of the landing zone and not optional through normal control selection.
• Strongly recommended: AWS-recommended but customer-selectable.
• Elective: optional for a specific requirement.

Do not say “mandatory means preventive”; some mandatory controls are detective. Do not say “enabled means compliant.” Preventive status may be enforced/not enabled; detective compliance depends on Config evaluation and scope; proactive controls cover only supported CloudFormation resources and hooks.

Control parameters, implementation, supported resources/Regions, inherited behavior, remediation, and cost vary. Read the individual Control Reference entry. In nested OUs, preventive controls inherited from ancestors can affect even unregistered descendants; detective/proactive deployment follows registered/enrolled baseline behavior. Calculate each path.

The management account is an intentional exception: its root/admins can perform actions controls would deny in members. Keep workloads out and protect it separately.

Choosing and enabling controls

Map each requirement to an exact control objective, behavior, implementation, target OU, Regions, and residual gap. Before enabling:

1. Inventory existing resources/configuration and overlapping SCPs, Config rules, hooks, Security Hub standards, and custom policies.
2. Check prerequisites, parameters, exclusions, Region/service/resource support, quotas, and Config cost.
3. Deploy to a policy-staging OU and representative account.
4. Test compliant and noncompliant creation through console/API/CloudFormation, existing-resource evaluation, service-linked roles, exception/recovery, and rollback.
5. Canary and batch rollout; monitor asynchronous operation and member deployment.

Duplicating an AWS Config rule can double evaluations/cost and create conflicting remediation. An SCP with the same intent can have subtly different exceptions. Establish a control catalog with one owner/source of truth.

Baselines, OU registration, and account enrollment

AWSControlTowerBaseline registers/governs a normal OU; optional integration baselines add features. Enablement and reset operations are asynchronous and versioned. An OU's green baseline does not automatically prove every child account completed every StackSet/control operation.

Registering an existing OU can affect many accounts. Preflight:

• supported OU/account count and nesting;
• AWSControlTowerExecution role/trust and required permissions;
• conflicting Config recorders/delivery channels/aggregators;
• existing CloudTrail, buckets, keys, SCPs, StackSets, IAM Identity Center, and networking;
• account state, Regions, quotas, suspended/closed accounts;
• log/archive/security account exclusions and data retention.

Account enrollment deploys baseline StackSets/resources, identifies identity, moves/targets the account, and applies controls. It can take minutes to hours. Poll operation, baseline, StackSet instances, recorder/delivery, log arrival, control behavior, and compliance.

Auto-enrollment (landing zone 3.1+) can apply destination OU baseline/control configuration after Organizations account moves. It is eventually consistent, does not fix older drift automatically, and does not clean up orphaned Service Catalog provisioned products. Moves between differently configured OUs can still require careful update/reset and may cause drift.

Account Factory, AFT, and customization

Account Factory uses AWS Service Catalog to vend/update standardized accounts into governed OUs. It is not complete when the account ID exists; acceptance includes contacts, identity, baseline, controls, logs, security integrations, network, quotas, budget, metadata, and behavioral tests.

Account Factory for Terraform (AFT) adds a Git/Terraform pipeline for account requests, provisioning customization, global/account customization, and updates. Account Factory Customization/AFC and Customizations for AWS Control Tower (CfCT) offer other extension patterns. Select one ownership model and avoid three systems managing the same resource.

Extensions must not modify Control Tower-managed resources. Deploy customer-owned StackSets/stacks/policies with separate names, lifecycle, drift, rollback, and version compatibility. Test landing-zone upgrades against customizations before production rollout.

Drift: symptom, type, and correction

Drift means expected managed state and actual state differ. Causes include manual edit/deletion, trusted access disabled, OU/account move, SCP change, StackSet failure, missing role, integration change, or incomplete update.

Relevant types include landing-zone drift, enabled baseline/control inheritance drift, moved member/shared account, deleted/modified managed resources, and role/trusted-access drift. Diagnose before “reset everything”:

landing-zone version/status
-> integrations/trusted access/delegated admins
-> OU enabled baseline version/status
-> account child baseline/control status
-> enabled controls and parameters
-> StackSet/stack instance status per account/Region
-> underlying Config/CloudTrail/EventBridge/S3/KMS/IAM behavior

Remediation may be Update landing zone, Re-register OU, Update account, ResetEnabledBaseline, or ResetEnabledControl. After resetting an OU baseline, reset optional enabled controls as current guidance requires. A reset can overwrite unsupported manual edits; preserve evidence and understand custom dependencies first.

Landing zone 4.0+ drift notifications arrive through EventBridge in the management account; create monitored rules/targets. Do not assume an old SNS subscription still receives every event.

Managed resources and safe changes

Control Tower uses StackSets and marks/names resources it owns. Do not edit/delete managed SCPs, roles, buckets, Config channels, trails, rules, hooks, StackSets, or stacks outside supported workflows. A CloudFormation StackInstance marked OUTDATED can be expected due to selective parameters, so correlate with Control Tower baseline/control status before declaring drift.

For an urgent production problem, identify whether the resource is managed, use documented update/reset/disable methods, involve AWS Support when state is unknown, and preserve logs. A manual “quick fix” can make the landing zone unrecoverable or be overwritten.

Regions and Region deny

Choose the home and governed Regions from workload, data, service, resilience, and cost requirements. Adding a governed Region requires landing-zone update and then OU/account updates/re-registration so baseline and detective resources deploy there. A Region marked Not governed can still host resources unless denied; it is not safe by default.

The landing-zone Region-deny control applies across OUs with the baseline and cannot deny the home Region. There is also an OU-targeted Region-deny control. Review their interaction, global-service exceptions, existing resources, STS/endpoints, and recovery before enabling. Region deny blocks access/deployment; it does not relocate or delete existing resources.

Updating the landing zone

Treat version/integration/Region changes as a program:

• read release notes/key changes and prerequisites;
• export current manifest/settings, baselines, controls, OUs/accounts, managed/custom resources, drift, and costs;
• resolve blocking drift and failed StackSets;
• test in a representative non-production organization where feasible;
• back up policies/configuration and ensure management-account recovery;
• update landing zone, then re-register/reset OUs/accounts/optional controls as required;
• verify logs, Config aggregation, identity, controls, EventBridge, Account Factory, AFT/customizations, and bills.

Landing-zone success does not imply every OU/account received new settings until downstream updates complete.

Practical lab

Download the AWS257 Control Tower operations pack. It contains:

• LANDING_ZONE_REVIEW_WORKBOOK.md;
• SUPPLIED_CONTROL_TOWER_CASES.md with seven failures;
• CONTROL_BEHAVIOR_AND_COVERAGE.md;
• UPGRADE_DRIFT_AND_RECOVERY_RUNBOOK.md;
• ANSWER_DIRECTIONS.md, opened after independent analysis.

Review a supplied 3.3-to-4.0 migration, classify ten controls, preflight OU registration, diagnose drift, accept a vended account, and prove rollback. The no-create route is complete.

Read-only CLI evidence

Use the landing-zone home Region and authorized management read access:

aws controltower list-landing-zones --region ap-south-1
aws controltower get-landing-zone --landing-zone-identifier LZ_ARN --region ap-south-1
aws controltower list-baselines --region ap-south-1
aws controltower list-enabled-baselines --include-children --region ap-south-1
aws controltower list-enabled-controls --target-identifier OU_ARN --region ap-south-1
aws organizations list-aws-service-access-for-organization
aws organizations list-delegated-administrators
aws cloudformation list-stack-sets --status ACTIVE

Paginate and inspect asynchronous operation identifiers/status. Redact account/OU/landing-zone/control/baseline ARNs, emails, bucket names, and organization structure. A list response is control-plane evidence, not log delivery or enforcement proof.

Troubleshooting matrix

Cost and decommissioning

Control Tower has no additional service charge. You pay for Config configuration items/rule evaluations, CloudTrail, S3/KMS, CloudWatch, SNS/EventBridge targets, Service Catalog, VPC/NAT, Backup, security services, and custom automation. Ephemeral resources can generate many Config items; every additional governed Region/account/control multiplies deployment and evaluation cost. Duplicate external trails/rules can add cost.

Decommissioning is destructive and not equivalent to manually deleting resources. It disables/removes managed controls, blueprints, records, roles, and Account Factory structures according to version, but preserves the organization/accounts and leaves artifacts such as S3 buckets/data, some roles, Identity Center objects, provisioned products/VPCs, log groups, and EventBridge rules for manual owner-reviewed cleanup. It cannot simply be undone. Never decommission as a learning cleanup.

Knowledge check

1. What does Control Tower add above Organizations?
2. Which 4.0 changes make classic Security OU diagrams incomplete?
3. How do preventive, detective, and proactive controls differ?
4. Why is mandatory guidance not synonymous with preventive behavior?
5. Why can an enabled control still leave a resource unprotected?
6. What privilege does AWSControlTowerExecution create?
7. How do registered OU and enrolled account differ?
8. What does auto-enrollment fix, and what does it leave behind?
9. Why is account creation not account acceptance?
10. When is OUTDATED StackInstance status expected rather than drift proof?
11. Which evidence identifies baseline/control inheritance drift?
12. Why might Config and CloudTrail logs occupy different buckets after 4.0?
13. What is the difference between governed, not governed, and denied Regions?
14. Why must optional controls be reset after some baseline resets?
15. Why is manual managed-resource editing unsafe?
16. Which resources can remain after decommissioning?

Lesson acceptance

Pass requires version-aware landing-zone architecture; integration/dependency map; ten correct control classifications and coverage gaps; management exception; existing-OU/account enrollment preflight; Account Factory acceptance; seven supplied diagnoses; baseline/control/StackSet evidence; 3.3-to-4.0 logging/Config/EventBridge migration; Region governance tests; staged upgrade and rollback; managed-resource ownership; cost model; and no-create proof.

Official sources

• What is AWS Control Tower?
• How Control Tower works
• Landing zone 4.0 key changes
• How controls work
• Control Reference
• Register an existing OU
• Account auto-enrollment
• Governance drift
• Config integration with landing zone 4.0
• Control Tower Regions
• Control Tower pricing
• Decommissioning process