5.3 AWS Control Tower, Account Factory & Landing Zone Automation

AWS Control Tower Architecture & Landing Zone Automation

AWS Control Tower provides the fastest way to set up and govern a secure, compliant, multi-account AWS environment (known as a Landing Zone) based on AWS Well-Architected best practices. Rather than requiring DevOps teams to manually stitch together AWS Organizations, IAM Identity Center, AWS Config, and CloudTrail using custom automation scripts, Control Tower deploys and manages these services through an automated orchestration engine.

Core Components Provisioned by Control Tower

When Control Tower is deployed in a designated Management account, it automatically constructs a standardized multi-account foundation:

1. AWS Organizations Structure: Establishes the Organization Root, a Security OU (containing pre-configured core accounts), and a Sandbox OU.
2. Log Archive Account: Hosts dedicated, centrally managed Amazon S3 buckets that ingest immutable, cross-account CloudTrail logs and AWS Config history snapshots. Configured with S3 Object Lock, strict access policies, and KMS Customer Managed Keys (CMKs).
3. Security Tooling (Audit) Account: Houses security operations, acting as the delegated administrator for auditing. Grants read-only cross-account access to security tools and auditors via preconfigured IAM roles (AWSControlTowerExecution and AWSControlTowerAdmin).
4. AWS IAM Identity Center (AWS SSO): Configures single sign-on access to all member accounts with predefined permission sets (e.g., AWSAdministratorAccess, AWSReadOnlyAccess) mapped to corporate identity providers (IdPs) via SAML 2.0 or OIDC.
5. Automated Baseline Stacks: Provisions AWS Config recorders, delivery channels, and baseline CloudTrail organizational trails across all supported regions in all enrolled accounts.

---

The Triad of Control Tower Controls (Guardrails)

In AWS Control Tower, governance rules are known as Controls (formerly called Guardrails). Controls enforce corporate security standards, compliance frameworks, and operational baselines across all enrolled Organizational Units.

                                [ Governance Controls ]
                                           │
        ┌──────────────────────────────────┼──────────────────────────────────┐
        ▼                                  ▼                                  ▼
 [ Preventive Controls ]            [ Proactive Controls ]             [ Detective Controls ]
  Enforcement: Pre-Runtime           Enforcement: Deploy-Time           Enforcement: Post-Provisioning
  Mechanism: Organizations SCPs      Mechanism: CloudFormation Hooks    Mechanism: AWS Config Rules
  Action: Hard API Rejection         Action: Rejects Stack Deploy       Action: Non-Compliant Alerting

1. Classification by Enforcement Behavior

2. Classification by Guidance Level

• Mandatory Controls: Enabled automatically when Control Tower is set up. They protect the integrity of the landing zone (e.g., preventing modification of Control Tower IAM execution roles or stopping CloudTrail logging) and cannot be disabled by administrators.
• Strongly Recommended Controls: Enforce enterprise security best practices (e.g., detecting unencrypted Amazon EBS volumes, disallowing public S3 bucket read access, or requiring MFA for root users).
• Elective Controls: Optional controls enabling organizations to track compliance against specific regulatory frameworks (e.g., NIST SP 800-53, PCI-DSS, HIPAA, or ISO 27001).

---

Account Factory Automation: Built-in vs. AFT

Control Tower offers two primary mechanisms for provisioning and configuring new member accounts:

1. Standard AWS Control Tower Account Factory

Built on top of AWS Service Catalog, the standard Account Factory allows administrators or authorized teams to provision standardized, pre-configured accounts via the AWS Console, AWS CLI, or Service Catalog APIs. The requester inputs parameters such as Account Name, Account Email, SSO User Email, and Target OU. Account Factory creates the account, enrolls it into Control Tower, attaches baseline controls, and provisions a standardized VPC.

2. Account Factory for Terraform (AFT)

For enterprise DevOps teams practicing GitOps and managing infrastructure as code via HashiCorp Terraform, AWS provides Account Factory for Terraform (AFT). AFT replaces manual console provisioning with an automated, idempotent Git-driven pipeline deployed in a dedicated AFT Management account.

   [ Git Repositories ]
     ├─ 1. aft-account-request                   ──> [ SQS / DynamoDB / Step Functions ]
     ├─ 2. aft-account-provisioning-customizations ──> [ Account Factory Provisions Account ]
     ├─ 3. aft-global-customizations             ──> [ Terraform Applied to ALL Accounts ]
     └─ 4. aft-account-customizations            ──> [ Terraform Applied to Target Accounts ]

The Four AFT Git Repositories

1. aft-account-request: Contains Terraform files defining account requests (account name, email, SSO credentials, target OU). Committing a new account block triggers the AFT orchestration engine (powered by Amazon SQS, Amazon DynamoDB, and AWS Step Functions) to call Control Tower Account Factory.
2. aft-account-provisioning-customizations: Executes pre-provisioning logic (such as reserving IP CIDR blocks from an internal IPAM or issuing corporate API calls) before Terraform customization runs.
3. aft-global-customizations: Contains Terraform code applied to every single account managed by AFT (e.g., deploying corporate IAM roles, custom security agents, standard CloudWatch alarms, and cross-account logging endpoints).
4. aft-account-customizations: Contains targeted Terraform modules mapped to specific accounts or account types (e.g., deploying Amazon EKS clusters or RDS databases only in production workload accounts).

---

Customizations for AWS Control Tower (CfCT)

While AFT uses Terraform, organizations committed to AWS-native infrastructure as code utilize Customizations for AWS Control Tower (CfCT).

• Architecture: CfCT deploys an automated CI/CD pipeline using AWS CodePipeline and AWS CodeBuild in the Management account, backed by a source repository (AWS CodeCommit, GitHub, or Amazon S3).
• Configuration Manifest (manifest.yaml): Administrators define declarative mappings associating AWS CloudFormation templates and Service Control Policies with specific OUs or Account IDs:

name: enterprise-baseline-customizations
version: 2021-03-15

resources:
  - name: BaselineVpcSecurityStack
    resource_file: templates/baseline-vpc-security.yaml
    deploy_method: stack_set
    deployment_targets:
      organizational_units:
        - WorkloadsDev
        - WorkloadsProd
    regions:
      - us-east-1
      - us-west-2
    parameters:
      - parameter_key: EnvironmentType
        parameter_value: Production

  - name: RestrictEc2InstanceTypesSCP
    resource_file: policies/restrict-instance-types.json
    deploy_method: scp
    deployment_targets:
      organizational_units:
        - WorkloadsDev

When a developer pushes changes to manifest.yaml or template files, CodePipeline automatically invokes CloudFormation StackSets to deploy the updates across all target accounts.

---

Control Tower Lifecycle Events

AWS Control Tower emits structured lifecycle events to Amazon EventBridge in the Management account whenever landing zone operations complete:

• CreateManagedAccount: Fired when a new account is successfully provisioned and enrolled.
• UpdateManagedAccount: Fired when account metadata or baseline configurations are updated.
• RegisterOrganizationalUnit: Fired when an existing OU is enrolled into Control Tower governance.

Chaining Automated Post-Provisioning Workflows

DevOps engineers leverage EventBridge rules to build custom, event-driven integrations with enterprise IT systems:

{
  "source": ["aws.controltower"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "eventSource": ["controltower.amazonaws.com"],
    "eventName": ["CreateManagedAccount", "UpdateManagedAccount"]
  }
}

A production account-onboarding rule should inspect the lifecycle status for success and match both event names because a retried account creation can complete as UpdateManagedAccount. When a matching successful event fires, EventBridge routes the payload to an AWS Lambda function or AWS Step Functions state machine that automatically:

1. Registers the new account in the enterprise Configuration Management Database (CMDB, such as ServiceNow).
2. Automatically requests an IPv4/IPv6 CIDR allocation from AWS VPC IP Address Manager (IPAM).
3. Updates corporate routing tables to peer the new account's VPC with AWS Transit Gateway.
4. Deploys third-party security telemetry agents (e.g., Datadog, Splunk, or CrowdStrike).

---

Drift Management & Landing Zone Upgrades

Over time, operational environments experience Configuration Drift—deviations from the baseline state established by Control Tower.

Types of Drift

• Governance Drift: An administrator in a member account modifies or deletes a baseline resource (such as an AWS Config recorder, an IAM role, or an S3 bucket policy deployed by Control Tower).
• OU Registration Drift: A new account is created directly inside AWS Organizations under an enrolled OU, bypassing Control Tower Account Factory. The account exists in the OU but lacks Control Tower baseline stacks.

Drift Detection & Remediation

Control Tower continuously audits the environment and flags drifted accounts or OUs in the console:

• Re-registering an OU: When an OU drifts, clicking Re-register OU re-applies all baseline templates, updates IAM roles, and re-attaches preventive and detective controls across all child accounts.
• Repairing an Account: If a single account exhibits drift, the Repair action re-deploys missing baseline CloudFormation stacks and repairs corrupted execution roles.

Landing Zone Upgrades

AWS periodically releases new versions of the Control Tower Landing Zone (introducing new security baselines, region expansions, or IAM role optimizations). Upgrades are non-destructive: administrators initiate the upgrade from the Control Tower console, which sequentially updates core accounts, re-deploys baseline StackSets, and upgrades enrolled OUs without interrupting live application workloads.