AWS Control Tower¶

Without Control Tower:
  Set up Organizations + SCPs manually
  Configure CloudTrail in every account manually
  Set up centralized logging account manually
  Set up security audit account manually
  Create account onboarding process manually
  Document all guardrails manually
  → Weeks of work, error-prone, inconsistent

With Control Tower:
  Click "Set up landing zone" → 30–60 minutes
  → Organizations created (if not exists)
  → Log archive account created + CloudTrail → centralized S3
  → Audit account created + cross-account roles
  → Guardrails applied to all OUs
  → Account Factory ready: create compliant new accounts in minutes
  → Dashboard: compliance status of all accounts in one view

A landing zone = the entire baseline multi-account environment Control Tower creates:

Automatically created accounts:
  Management Account:    the root account you launch Control Tower from
  Log Archive Account:   receives CloudTrail logs + Config snapshots from ALL accounts
                         → centralized, tamper-resistant audit trail
  Audit Account:         cross-account read access to ALL member accounts
                         → security team / auditors can review without account access
                         → has pre-configured SNS topics for compliance alerts

Automatically configured:
  AWS Organizations: OU structure created
  AWS CloudTrail:    organization-level trail → logs all accounts → Log Archive S3
  AWS Config:        enabled in all accounts → resources tracked
  AWS SSO:           preconfigured with directory + permission sets
  Guardrails:        mandatory + strongly recommended applied to all enrolled OUs
  VPC:               optional baseline VPC configuration

Default OU structure: [oneuptime](https://oneuptime.com/blog/post/2026-02-12-aws-control-tower-landing-zones/view)
  Root
  ├── Security OU → Log Archive account + Audit account
  └── Sandbox OU → initial member accounts

After setup: you create additional OUs and enroll accounts

Guardrails = pre-packaged governance rules for your landing zone

Two mechanism types:
  Preventive guardrails: implemented as SCPs → BLOCK actions before they happen
    Example: "Disallow changes to CloudTrail" → SCP denies cloudtrail:StopLogging
    Effect: action attempted → immediately denied

  Detective guardrails: implemented as AWS Config rules → DETECT non-compliant state
    Example: "Detect public S3 buckets" → Config rule checks s3:BucketPublicAccessEnabled
    Effect: bucket made public → Config marks NONCOMPLIANT → dashboard alerts

Three enforcement levels:
  Mandatory:              ALWAYS enabled, cannot be disabled
    Examples: detect changes to log archive account, detect SCP changes
  Strongly Recommended:   enabled by default, CAN be disabled
    Examples: detect public S3 buckets, detect unrestricted SSH
  Elective:               off by default, opt-in
    Examples: restrict specific instance types, require specific tags

Guardrails apply at OU level only — not individual accounts [globallogic](https://www.globallogic.com/ro/insights/blogs/deploying-a-landing-zone-with-aws-control-tower-part-2/)

Important behavior: [globallogic](https://www.globallogic.com/ro/insights/blogs/deploying-a-landing-zone-with-aws-control-tower-part-2/)
  OUs created THROUGH Control Tower console → "Registered" → guardrails apply
  OUs created via CLI or Organizations console → "Unregistered"
  → Must manually register OU in Control Tower to apply guardrails

Self-service account provisioning — create new, compliant AWS accounts
in minutes with standardized configuration:

Every Account Factory account gets automatically: [oneuptime](https://oneuptime.com/blog/post/2026-02-12-set-up-aws-control-tower-account-factory-for-new-accounts/view)
  Enrollment in Control Tower governance
  Guardrails (preventive + detective) from landing zone
  Standard IAM roles and configurations
  VPC networking (if configured in Account Factory settings)
  SSO access for designated users
  CloudTrail logging → Log Archive account
  Config enabled + reporting to aggregator

Account Factory methods:
  Console: Control Tower → Account Factory → Enroll Account / Create Account
  Service Catalog: Account Factory product in portfolio
    → Developers/teams can self-request accounts via Service Catalog
  Account Factory for Terraform (AFT):
    Infrastructure-as-Code account vending:
    → Push to Git repo → pipeline runs → new account created + configured
    → GitOps-style account management
    → Apply account customizations via Terraform

Customization after creation:
  Account Factory customizations (AFCx): run additional Config/scripts post-creation
  CfCT (Customizations for Control Tower): CloudFormation StackSets deployed to new accounts

Single pane of glass for entire organization:
  Accounts: list of all enrolled accounts + OU membership
  Guardrails: which are enabled per OU
  Compliance: COMPLIANT / NONCOMPLIANT status per account per guardrail
  Non-compliant resources: drill down to specific resource + Config rule violation

Use case:
  CISO logs into Control Tower → sees 3 accounts flagged NONCOMPLIANT
  → Clicks → sees "Detect public S3 buckets" violated in prod-data account
  → Investigates → remediates → status returns to COMPLIANT

Relationship: Control Tower USES Organizations under the hood
  Control Tower creates + manages the Organizations structure
  You can use both: Control Tower for governance + Organizations directly for billing
  Do NOT manually change SCPs that Control Tower created → may break guardrails