Cargando...
Cargando...
Automated, policy-driven landing zones that enforce guardrails across your entire AWS organization from day one.
AWS Control Tower automates the setup and governance of a secure, compliant, multi-account AWS environment called a Landing Zone. It uses pre-packaged guardrails (preventive and detective controls) built on AWS Organizations SCPs, AWS Config Rules, and CloudFormation StackSets to enforce policies at scale. Control Tower is the go-to service when an organization needs to provision new accounts quickly while maintaining centralized security and compliance — without manually wiring together Organizations, Config, CloudTrail, and IAM from scratch.
Rapidly establish and continuously govern a secure, multi-account AWS environment (Landing Zone) with automated guardrails, account vending, and centralized compliance visibility — eliminating the heavy lifting of building governance infrastructure manually.
Use When
Avoid When
Landing Zone
Pre-configured, secure multi-account environment with baseline accounts, OUs, SCPs, CloudTrail, and Config set up automatically.
Account Factory
Self-service account vending machine built on AWS Service Catalog. Provisions new accounts with baseline guardrails pre-applied. Account Factory for Terraform (AFT) also available.
Guardrails (Controls)
Three categories: Mandatory (always on), Strongly Recommended (AWS best practice, can toggle), Elective (optional, business-specific). Two mechanisms: Preventive (SCP) and Detective (Config Rule).
Proactive Guardrails (CloudFormation Hooks)
Newer guardrail type that checks resources BEFORE they are provisioned via CloudFormation, preventing non-compliant infrastructure from being created.
Drift Detection and Remediation
Detects when accounts or OUs deviate from Landing Zone baseline. Administrators can re-baseline drifted resources from the console.
Centralized CloudTrail Logging
Organization-level CloudTrail automatically configured; logs aggregated in the Log Archive account S3 bucket.
AWS Config Aggregation
Config is enabled in all enrolled accounts; an aggregator in the Audit account provides cross-account compliance visibility.
Integration with AWS Security Hub
Control Tower can send findings to Security Hub for unified security posture management.
Integration with AWS IAM Identity Center (SSO)
Control Tower sets up IAM Identity Center for centralized federated access across all accounts in the Landing Zone.
Account Factory for Terraform (AFT)
Infrastructure-as-Code approach to account vending using Terraform pipelines, enabling GitOps-style account provisioning.
Customizations for Control Tower (CfCT)
Allows deploying custom CloudFormation templates and SCPs to accounts/OUs during or after enrollment via a pipeline.
Lifecycle Events via EventBridge
Control Tower emits lifecycle events (e.g., CreateManagedAccount, UpdateManagedAccount) to EventBridge, enabling automated post-provisioning workflows.
OU Registration
Existing OUs and accounts can be enrolled/registered into Control Tower governance after initial Landing Zone setup.
Multi-Region Governance
Guardrails can be applied across multiple regions; you configure which regions Control Tower governs during setup.
VPC Configuration in Account Factory
Account Factory can provision a default VPC configuration (or no VPC) in each new account, including subnet and CIDR settings.
Hierarchical Policy Enforcement
high freqControl Tower sits on top of AWS Organizations and uses SCPs to enforce preventive guardrails across OUs. Organizations provides the structural hierarchy; Control Tower provides the governance automation layer. Every preventive guardrail IS an SCP applied at the OU level.
Detective Guardrail Compliance
high freqDetective guardrails are implemented as AWS Config Rules deployed via CloudFormation StackSets to all enrolled accounts. The Config Aggregator in the Audit account collects compliance data, giving a single compliance dashboard across the entire organization.
Baseline Deployment via StackSets
high freqControl Tower uses CloudFormation StackSets to deploy baseline resources (Config rules, CloudTrail, IAM roles) to all enrolled accounts automatically. When a new account is vended, StackSets push the baseline stack to that account. This is how guardrails and logging are uniformly enforced.
Account Factory Self-Service Vending
high freqAccount Factory is exposed as an AWS Service Catalog product. Teams request new accounts through Service Catalog; Control Tower fulfills the request by creating the account in Organizations, applying guardrails, and deploying baseline resources. Enables self-service without giving teams direct Organizations access.
Post-Account-Provisioning Automation
high freqControl Tower emits lifecycle events to EventBridge when accounts are created, updated, or enrolled. EventBridge rules trigger Lambda functions or Step Functions to perform post-provisioning tasks: creating budget alerts, deploying additional resources, notifying teams via SNS, or registering accounts in ITSM tools.
Centralized Federated Access Management
high freqControl Tower automatically configures IAM Identity Center (formerly AWS SSO) during Landing Zone setup. Users and groups are managed centrally; permission sets define access to specific accounts. This eliminates the need to manage IAM users in each individual account.
Unified Security Posture
high freqControl Tower detective guardrail findings can feed into AWS Security Hub for consolidated security findings across the organization. Security Hub aggregates findings from GuardDuty, Inspector, Macie, and Control Tower guardrail violations in a single dashboard.
Operational Baseline Enforcement
high freqSystems Manager can be used alongside Control Tower to enforce operational baselines: SSM Parameter Store for cross-account configuration sharing, Systems Manager Automation for remediation of detective guardrail violations, and Patch Manager for compliance across enrolled accounts.
Account Vending Pipeline
high freqEventBridge captures the CreateManagedAccount lifecycle event from Control Tower, triggering a Lambda function that performs post-provisioning customizations: tagging accounts, creating default budgets, enabling GuardDuty, and registering accounts with third-party tools.
Customizations for Control Tower (CfCT)
high freqCfCT solution extends Account Factory by deploying custom CloudFormation stacks and SCPs beyond the Control Tower baseline. Organizations with bespoke security requirements use CfCT to layer additional controls on top of the standard Landing Zone guardrails.
Preventive guardrails use SCPs to BLOCK actions before they happen. Detective guardrails use AWS Config Rules to DETECT and REPORT violations after the fact. Proactive guardrails use CloudFormation Hooks to check resources BEFORE provisioning. Know all three mechanisms and when each is appropriate.
Mandatory guardrails CANNOT be disabled — ever. They protect the integrity of the Landing Zone itself (e.g., no one can turn off CloudTrail in enrolled accounts). If an exam question asks how to prevent a specific action organization-wide without exceptions, mandatory guardrails or SCPs are the answer.
The Log Archive account and the Audit account are DIFFERENT accounts with different purposes. Log Archive = stores CloudTrail and Config logs in S3. Audit account = provides read-only access for auditors and receives SNS notifications for guardrail violations. Exam questions deliberately mix these up.
When a question asks about automating post-account-provisioning tasks (e.g., 'how do you automatically enable GuardDuty in every new account?'), the answer is: Control Tower lifecycle events → EventBridge → Lambda. This is the canonical pattern for extending Control Tower automation.
Control Tower does NOT automatically govern every OU in your AWS organization. You must explicitly REGISTER OUs with Control Tower for guardrails to apply. Existing accounts in unregistered OUs are NOT protected by Control Tower guardrails.
PREVENTIVE guardrails = SCPs (block actions). DETECTIVE guardrails = Config Rules (detect violations). PROACTIVE guardrails = CloudFormation Hooks (prevent non-compliant IaC). Know which mechanism is which — this distinction appears on every exam that includes Control Tower.
Log Archive account ≠ Audit account. Log Archive STORES CloudTrail/Config logs in S3. Audit account provides READ-ONLY ACCESS for auditors and receives SNS guardrail violation alerts. Exam questions deliberately swap these — do not fall for it.
For post-account-provisioning automation (auto-enable GuardDuty, create budgets, notify teams), the canonical answer is: Control Tower lifecycle event → EventBridge → Lambda. This pattern appears frequently across SAP-C02, DOP-C02, and SCS-C02.
Account Factory for Terraform (AFT) is the answer when the question mentions 'GitOps', 'Terraform', or 'infrastructure-as-code account vending'. Standard Account Factory uses Service Catalog. AFT uses a Terraform pipeline. Both achieve account vending but through different mechanisms.
Control Tower itself is FREE — but always expect a follow-up about underlying service costs. Config rules are the dominant cost driver at scale. If asked about cost optimization in a large Control Tower deployment, reducing Config rule evaluations and using periodic (not continuous) evaluation mode where appropriate is the answer.
Drift detection in Control Tower identifies when someone has manually modified an enrolled account's SCPs, CloudTrail, or Config settings outside of Control Tower. The remediation is to 'Re-baseline' the account from the Control Tower console — NOT to manually reapply the changes.
When the question says 'a company wants to set up a new multi-account AWS environment with governance and compliance from day one' — the answer is AWS Control Tower, not manually configuring Organizations + Config + CloudTrail separately. Control Tower is the accelerator for this exact scenario.
Customizations for Control Tower (CfCT) is the answer when the question asks how to deploy ADDITIONAL custom resources or SCPs to every new account BEYOND what Control Tower's standard guardrails provide. Think: 'baseline + custom' = CfCT.
IAM Identity Center (SSO) is automatically configured by Control Tower during Landing Zone setup. If a question asks about centralized user access management across all accounts in a Control Tower Landing Zone, IAM Identity Center is the integrated answer — not individual IAM users in each account.
The home region selected during Landing Zone setup is permanent. If an organization needs to change its home region, it must reset the Landing Zone — a significant operational undertaking. This is a trap in scenario questions about regional expansion.
Common Mistake
AWS DMS (Database Migration Service) alone provides multi-account governance during a large-scale migration.
Correct
DMS is a data migration tool — it moves data between databases. Multi-account governance during migrations requires AWS Control Tower (for account structure and guardrails), AWS Organizations (for policy hierarchy), and potentially AWS Config (for compliance tracking). DMS has zero governance capabilities.
This is a top exam trap in migration scenario questions. Candidates see 'DMS' and 'multi-account migration' in the same question and incorrectly link them. Remember: DMS = data movement, Control Tower = account governance. They solve completely different problems and are often used TOGETHER in large migrations.
Common Mistake
AWS SCT (Schema Conversion Tool) handles both schema conversion AND data migration, so Control Tower governance is unnecessary for database migrations.
Correct
SCT only converts database schemas (DDL). It does not migrate data and has no governance capabilities. Data migration requires DMS. Account and policy governance requires Control Tower. These are three separate tools solving three separate problems.
Candidates conflate SCT's scope, thinking it's an all-in-one migration solution. On governance-focused questions, remember that no migration tool (DMS, SCT, DataSync) provides account-level policy enforcement — only Control Tower + Organizations does that.
Common Mistake
Replicating ECR images to all accounts using ECR replication is equivalent to centralized container image governance.
Correct
ECR cross-account replication duplicates images to each account's ECR registry, scattering enforcement and multiplying storage costs. True centralized governance means maintaining a SINGLE source-of-truth ECR registry and using resource-based policies + Control Tower guardrails to control which accounts can pull from it — not copying images everywhere.
This misconception appears in container governance questions. 'Replication everywhere' feels like governance but actually creates distributed, harder-to-control copies. Centralized governance = one registry, controlled access. Control Tower guardrails can enforce that accounts only pull from approved registries.
Common Mistake
Control Tower guardrails apply to ALL accounts in the AWS organization automatically once Control Tower is set up.
Correct
Guardrails only apply to accounts within OUs that have been explicitly REGISTERED with Control Tower. Accounts in unregistered OUs or accounts that haven't been enrolled are NOT governed by Control Tower guardrails. You must actively register OUs and enroll accounts.
This is a critical operational and exam trap. Setting up Control Tower does NOT automatically protect your entire organization. Security teams have been surprised to find existing accounts unprotected because they assumed automatic coverage. Always verify OU registration status.
Common Mistake
The Audit account in Control Tower is where logs are stored.
Correct
Logs (CloudTrail, Config) are stored in the LOG ARCHIVE account. The Audit account provides read-only cross-account ACCESS for auditors and security tools, and receives SNS notifications for guardrail violations. Two different accounts, two different purposes.
The naming is counterintuitive — 'Audit' sounds like it should store audit logs. Exam questions exploit this confusion. Memory trick: Log Archive = STORAGE (S3 buckets). Audit = ACCESS (read-only roles for auditors). Never mix these up.
Common Mistake
AWS Control Tower replaces AWS Organizations — you choose one or the other.
Correct
Control Tower BUILDS ON TOP of AWS Organizations — it requires Organizations to function. Control Tower is the governance automation and guardrail layer; Organizations is the underlying structural and policy foundation. They are complementary, not competing services.
Candidates sometimes think Control Tower is an alternative to Organizations. In reality, Control Tower cannot exist without Organizations. Think of Organizations as the foundation and Control Tower as the smart governance layer built on that foundation.
Common Mistake
Preventive guardrails in Control Tower can be applied to individual accounts.
Correct
Preventive guardrails (SCPs) are applied at the OU level, not the individual account level. This is an AWS Organizations SCP constraint — SCPs attach to OUs or the root, not individual accounts (though technically SCPs can be attached to accounts, Control Tower manages them at the OU level). To apply different guardrails to different accounts, place them in different OUs.
This matters for architecture questions about applying different policies to different teams. The correct pattern is: create separate OUs per team/environment, register each OU with Control Tower, and apply appropriate guardrails per OU.
Common Mistake
AWS Control Tower is a database migration governance tool that helps manage RDS migrations across accounts.
Correct
Control Tower governs AWS ACCOUNTS and enforces security/compliance POLICIES — it has nothing to do with database migrations. RDS is a destination service for migrated databases; Control Tower is an account governance service. They operate at completely different layers.
Exam questions in migration domains sometimes include Control Tower as a distractor. If a question is about moving data to RDS, DMS and SCT are the tools. If a question is about governing which accounts can create RDS instances or enforcing encryption on RDS, THEN Control Tower guardrails (via Config Rules) are relevant.
LAMP = Landing zone, Account factory, Mandatory guardrails, Policy enforcement (SCP) — the four pillars of Control Tower.
Log Archive = LOCK BOX (stores the logs, locked down). Audit = AUDITOR'S DESK (read-only access, receives alerts). Never confuse the box with the desk.
Guardrail types by timing: Proactive = BEFORE (CloudFormation Hook), Preventive = DURING (SCP blocks the action), Detective = AFTER (Config Rule finds the violation).
Control Tower is FREE, but CONFIG COSTS CASH — remember that AWS Config rules across hundreds of enrolled accounts are the primary cost driver.
REGISTER then ENROLL: First REGISTER the OU with Control Tower, then ENROLL individual accounts. Skipping either step means no guardrail coverage.
DMS moves DATA. Control Tower governs ACCOUNTS. SCT converts SCHEMAS. Three tools, three layers, never interchangeable.
CertAI Tutor · SAP-C02, SAA-C03, DOP-C02, SCS-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns