Control Tower and controls
Lesson 2 of 5 in The Multi-Account Foundation.
Organizations gives you the hierarchy and the policy engine. It does not give you an opinion. AWS Control Tower is the opinion: point it at a new or existing organization and it builds a landing zone — a Security OU with a security tooling account and a log archive account, an organization CloudTrail trail delivering to that archive, AWS Config recorders and an aggregator, IAM Identity Center for human access, and a baseline set of controls attached to the OUs it created.
Nothing in that list is magic. You could build every piece by hand with Organizations, CloudFormation and Config, and plenty of mature organizations did exactly that before Control Tower existed. What Control Tower adds is continuity: the baseline is re-applied to every account it vends, it detects when someone has drifted away from it, and the controls arrive as a curated catalogue you enable by name instead of policy JSON you maintain.
The word guardrail is the old name. The current name is control, and the exam cares about the three kinds because each one fails differently.
| Kind | Implemented as | Acts | When it fires you see | Guidance levels |
|---|---|---|---|---|
Preventive | A service control policy attached to the OU | Before the API call succeeds |
| Mandatory · strongly recommended · elective |
Detective | An AWS Config rule (often with a Lambda or Guard back end) | After the resource exists, on change or on a schedule | A | Strongly recommended · elective (plus mandatory detective controls in some Regions) |
Proactive | A CloudFormation hook running CloudFormation Guard rules | During stack create/update, before the resource is provisioned | The stack operation fails with the hook’s message — nothing non-compliant was ever created | Elective (you enable the ones you want) |
Read the middle column again, because it is the whole exam answer. A detective control tells you an unencrypted bucket exists. A preventive control stops the PutBucketPolicy that would have made it public. A proactive control stops the CloudFormation stack that would have created it — before the resource exists, which is strictly earlier than prevention at the API boundary of a hand-made resource. "Non-compliant resources must never be deployed in the first place" is a proactive-control sentence, and it is new enough that candidates still reach for Config rules out of habit.
Guidance levels are the other half. Mandatory controls are always on and cannot be disabled — they protect the landing zone's own machinery (nobody deletes the log archive bucket or the Config aggregator). Strongly recommended controls encode AWS's best practice and you may switch them off. Elective controls are opt-in capabilities you turn on per OU when your requirements call for them.
Three more Control Tower facts the SCS-C03 exam guide asks for, because it says "in new and existing environments".
Account Factory is the account-vending machine: a Service Catalog product that provisions a new account into a chosen OU with the baseline, the network configuration you templated, and Identity Center access already wired. Teams request an account instead of filing a ticket to the management account, and every account arrives identical — which is the real control, because the accounts nobody standardized are the ones that fail an audit.
Enrolling existing accounts is supported and is the usual reality. The account must be in the organization, must allow the Control Tower execution role, and must not already have conflicting resources (a second Config recorder in the Region is the classic blocker). You can enrol account by account, or register an entire OU so every account in it is brought under the baseline at once. Control Tower does not require you to burn down what you built.
Drift is the gap between the landing zone Control Tower set up and what the organization now looks like — someone moved an account between OUs, detached a mandatory SCP, deleted a Config recorder, modified the trail. Control Tower surfaces drift and offers to repair the landing zone; it does not silently reconcile. Customizations for AWS Control Tower (CfCT) is the supported extension point: a pipeline that applies your own CloudFormation templates and SCPs to accounts and OUs as part of the vending lifecycle, so your additions survive the next account.
Control Tower, or Organizations on its own?
Interactive decision tree — outcomes:
- Control Tower landing zone
Let it create the Security OU, the log archive and security tooling accounts, the organization trail, Config and the baseline controls. Rebuilding this by hand is weeks of work and a permanent maintenance obligation.
- Control Tower, enrolling the existing accounts
Enrol account by account or register a whole OU. Expect to clear conflicts first — a pre-existing AWS Config recorder in the Region is the most common blocker. “In new and existing environments” is the exam guide’s own phrasing.
- Organizations directly
SCPs, RCPs, an organization trail, Config organization rules and StackSets give you every underlying control without adopting the landing zone’s opinions. You own the drift detection and the account baseline yourself — that is the trade.
- An SCP — no landing zone needed
A single organization-wide permission boundary is an Organizations feature. Control Tower would implement a preventive control as this same SCP; adopting a landing zone to get one policy is the wrong size of answer.
- Account Factory
Standardized account vending with the baseline, network configuration and Identity Center access pre-applied. The alternative — a documented runbook a human follows — is the thing that drifts.
- Customizations for AWS Control Tower (CfCT)
The supported way to extend the landing zone: your CloudFormation templates and SCPs applied through the account lifecycle, so customizations reach accounts vended next month too.
- CloudFormation StackSets with service-managed permissions
Target the OU and enable automatic deployment, and new accounts in that OU receive the stack as they join. The next module is entirely about this.
Why can’t I edit a Control Tower SCP in the Organizations console?
You can — and you should not. Control Tower owns the policies it attached (their names begin with aws-guardrails-), re-applies them as part of landing-zone operations, and reports hand edits as drift. Enable or disable the control in Control Tower; use your own separate SCPs, or CfCT, for policy Control Tower does not offer.
Account Factory or Service Catalog?
Account Factory is a Service Catalog product — Control Tower provisions it into the Service Catalog portfolio in the management account, which is why requesting an account looks like launching a product. Service Catalog in general (portfolios, products, launch constraints) is a broader tool, covered in the resource sharing lesson.
Control Tower, Config and Security Hub overlap — who owns what?
Control Tower enables Config recorders and an aggregator and uses Config rules as its detective controls. Security Hub separately runs security standards whose controls are also largely Config-backed, and aggregates findings. The overlap is real; the exam resolves it by intent — Control Tower governs the landing zone and account baseline, Security Hub measures posture across accounts, Config evaluates configuration and can remediate it.
Does a proactive control replace a detective one?
No. Proactive controls only see resources created through CloudFormation. Anything built through the console, the CLI or an SDK walks straight past them — which is why the honest architecture pairs a proactive control (stop the bad template) with a preventive control (deny the API outright, whatever the caller) and a detective control (catch what both missed, including resources created before you enabled anything).
Key terms: AWS Control Tower, Landing zone, Control (formerly guardrail), Proactive control, Account Factory, Drift (landing zone and account)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.