7.1.2. AWS Control Tower Implementation
First Principle: Control Tower automates the creation and governance of a well-architected multi-account environment, providing guardrails that enforce security baselines without requiring manual configuration in each account.
What Control Tower Provides:
- Landing Zone: Pre-configured multi-account environment with audit and log archive accounts
- Account Factory: Automated account creation with pre-applied baselines (VPC, networking, IAM)
- Guardrails (Controls): Pre-built governance rules in three categories:
- Mandatory: Always enabled, non-negotiable (e.g., disallow CloudTrail changes)
- Strongly recommended: Best-practice controls (e.g., enable encryption)
- Elective: Optional controls for specific compliance needs
- Dashboard: Central visibility into compliance status across all accounts
Control Tower in Existing Environments:
- Can be deployed into organizations that already have accounts
- Enrolled accounts inherit guardrails applied to their OU
- Non-enrolled accounts are visible but not governed by Control Tower
- Gradual enrollment recommended — test with non-production OUs first
Custom Controls:
- Beyond pre-built guardrails, deploy custom SCP-based or AWS Config-based controls
- Use CloudFormation StackSets to deploy custom Config rules across all accounts
- Integrate with Service Catalog for approved-resource provisioning
⚠️ Exam Trap: Control Tower guardrails are implemented as SCPs (preventive) or Config rules (detective). Know that mandatory guardrails cannot be disabled, and that Control Tower creates its own OU structure (Security, Sandbox) automatically.
Scenario: A company deploying Control Tower for 100 existing accounts starts by enrolling the Security and Infrastructure OUs first, testing guardrail impact, then progressively enrolling production and development OUs with appropriate controls.
Reflection Question: Why does Control Tower recommend gradual enrollment for existing organizations rather than enabling all guardrails immediately?
