AWS Control Tower: Landing Zones and Account Factory

You've just been handed a production outage because someone accidentally deleted a production DynamoDB table. The root cause? A junior engineer had full admin access in an account that should have been locked down. This is the reality of AWS environments that grow organically—no governance, no boundaries, just chaos. AWS Control Tower exists to prevent exactly this kind of disaster. It's not a nice-to-have; it's the difference between a well-governed multi-account strategy and a free-for-all that will eventually cost you a compliance audit or a data loss event. Control Tower automates the creation of a landing zone—a secure, compliant foundation for your AWS accounts—and provides Account Factory to provision new accounts with pre-defined guardrails. If you're managing more than a handful of accounts and you're not using Control Tower, you're one misclick away from a bad day.

Why Control Tower Exists

AWS Control Tower solves a specific problem: multi-account governance at scale. Without it, you're manually configuring AWS Organizations, Service Control Policies (SCPs), CloudTrail, and IAM across dozens or hundreds of accounts. That's fragile, inconsistent, and a compliance nightmare. Control Tower provides a landing zone—a well-architected, multi-account baseline—and Account Factory to provision new accounts with guardrails pre-applied. It's not optional if you're serious about production workloads; it's the foundation for any enterprise AWS environment. The alternative is a custom-built orchestration layer that you'll spend months maintaining. Control Tower is opinionated, and that's a feature: it enforces best practices like centralized logging, mandatory encryption, and least-privilege access. If you're starting fresh, use it. If you're migrating, plan to adopt it.

#!/bin/bash
# Enable Control Tower via AWS CLI (requires Organizations master account)
aws controltower enable-control --target-identifier arn:aws:organizations::123456789012:ou/o-xxxxxx/ou-yyyy --control-identifier arn:aws:controltower:us-east-1::control/AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLED
# Verify landing zone status
aws controltower get-landing-zone-status --landing-zone-id lz-xxxxx

Landing Zone Architecture

The landing zone is the core of Control Tower—a pre-built, multi-account structure based on AWS best practices. It creates three organizational units (OUs): Security, Infrastructure, and Workloads. The Security OU contains the Audit and Log Archive accounts, which are mandatory. The Infrastructure OU holds shared services like networking and CI/CD. The Workloads OU is where your application accounts live. Each OU has SCPs that enforce policies like disabling root user access, requiring encryption, and restricting regions. The landing zone also sets up AWS CloudTrail, AWS Config, and Amazon GuardDuty across all accounts, with logs centralized in the Log Archive account. This architecture is designed for auditability and isolation. If you need to customize, you can extend it with custom SCPs or additional OUs, but the baseline is non-negotiable for compliance.

{
  "OrganizationalUnits": [
    {
      "Name": "Security",
      "Accounts": ["Audit", "LogArchive"]
    },
    {
      "Name": "Infrastructure",
      "Accounts": ["SharedServices", "Network"]
    },
    {
      "Name": "Workloads",
      "Accounts": ["Prod", "Staging", "Dev"]
    }
  ],
  "Guardrails": [
    "AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLED",
    "AWS-GR_RESTRICT_ROOT_USER",
    "AWS-GR_REGION_DENY"
  ]
}

Account Factory: Provisioning at Scale

Account Factory is the provisioning engine within Control Tower. It allows you to create new AWS accounts with a predefined baseline—including IAM roles, SCPs, and network configuration—in minutes. You define a blueprint (e.g., account email, OU, SSO permissions) and Account Factory handles the rest. It integrates with AWS Service Catalog, so you can offer account templates to developers via a self-service portal. This is critical for scaling: instead of waiting for a ticket, teams can spin up isolated environments for testing or feature development. However, Account Factory has limitations: it doesn't support custom network configurations out of the box, and you can't modify the baseline after creation without updating the landing zone. For production, you'll likely need to extend it with customizations via AWS CloudFormation StackSets or Terraform.

import boto3

client = boto3.client('servicecatalog')

response = client.provision_product(
    ProductId='prod-abc123',
    ProvisioningArtifactId='pa-def456',
    ProvisionedProductName='my-new-account',
    ProvisioningParameters=[
        {'Key': 'AccountEmail', 'Value': 'aws+myapp@example.com'},
        {'Key': 'AccountName', 'Value': 'MyApp-Prod'},
        {'Key': 'ManagedOrganizationalUnit', 'Value': 'Workloads'},
        {'Key': 'SSOUserEmail', 'Value': 'user@example.com'},
        {'Key': 'SSOUserFirstName', 'Value': 'John'},
        {'Key': 'SSOUserLastName', 'Value': 'Doe'}
    ]
)
print(f"Provisioned product ID: {response['RecordDetail']['ProvisionedProductId']}")

Guardrails: Mandatory Policies

Guardrails are pre-built, high-level rules that enforce governance across your landing zone. They come in two flavors: preventive (SCPs) and detective (AWS Config rules). Preventive guardrails block non-compliant actions, like disabling CloudTrail or creating resources outside allowed regions. Detective guardrails monitor and alert on configurations, such as public S3 buckets or unencrypted EBS volumes. Control Tower includes a set of mandatory guardrails (e.g., disallow root user access, require encryption) and optional ones (e.g., restrict instance types). You can also create custom guardrails using AWS Config rules or SCPs, but they must be applied at the OU level. Guardrails are not retroactive—they only apply to new resources. For existing resources, you need to remediate manually or use AWS Config auto-remediation.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateVolume"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "ec2:VolumeType": "gp3"
        }
      }
    }
  ]
}

Customizations with Account Factory Customization (AFC)

Account Factory Customization (AFC) extends Control Tower by allowing you to apply custom CloudFormation templates and Service Control Policies to accounts during provisioning. This is essential for production environments where you need to enforce specific configurations like VPC peering, DNS settings, or custom IAM roles. AFC works by defining a set of customizations in a YAML manifest file, which is stored in a CodeCommit repository. When a new account is created via Account Factory, AFC automatically applies the customizations. This eliminates the need for post-provisioning scripts and ensures consistency. However, AFC has a learning curve: you must manage the customization repository, and updates to customizations require a full re-apply to existing accounts, which can be disruptive.

version: 1.0
resources:
  - name: VPC
    resource_file: templates/vpc.yaml
    parameters:
      VpcCIDR: 10.0.0.0/16
    deployment_targets:
      organizational_units:
        - Workloads
  - name: DenyPublicAccess
    resource_file: policies/deny-public-s3.yaml
    deployment_targets:
      organizational_units:
        - Workloads
        - Infrastructure

Logging and Monitoring Across Accounts

Control Tower centralizes logging and monitoring by design. It enables CloudTrail in every account and delivers logs to a centralized S3 bucket in the Log Archive account. AWS Config records resource configurations and sends them to the same bucket. Amazon GuardDuty is enabled in all accounts, with findings sent to the Audit account. This setup is mandatory for compliance (e.g., SOC 2, PCI DSS). However, it's not enough to just collect logs; you need to monitor them. Use Amazon Detective to analyze GuardDuty findings, and set up Amazon EventBridge rules to trigger alerts for critical events like root user login or SCP violations. For production, we recommend aggregating logs into a SIEM tool like Splunk or Sumo Logic for long-term retention and advanced analytics.

{
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

Managing SSO and Permissions

Control Tower integrates with AWS IAM Identity Center (formerly SSO) to manage user access across accounts. It creates a default permission set (e.g., AdministratorAccess, PowerUserAccess) and assigns users to accounts based on their OU. This replaces the need for IAM users in individual accounts. For production, you should define custom permission sets with least-privilege policies. For example, developers might get ReadOnlyAccess in production but PowerUserAccess in dev. You can also use ABAC (attribute-based access control) to grant permissions based on tags. SSO also supports external identity providers like Okta or Azure AD, which is critical for enterprises. However, SSO has a quirk: it doesn't support cross-account roles for service-linked roles, so some AWS services (like Amazon EKS) require additional configuration.

{
  "Name": "DeveloperAccess",
  "ManagedPolicies": ["arn:aws:iam::aws:policy/ReadOnlyAccess"],
  "InlinePolicy": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["ec2:Describe*", "s3:ListAllMyBuckets"],
        "Resource": "*"
      }
    ]
  }
}

Updating the Landing Zone

Control Tower periodically releases new landing zone versions with updated guardrails, features, and security fixes. Updating is a one-way operation that modifies the underlying CloudFormation stacks. Before updating, you must review the release notes for breaking changes. For example, version 3.0 introduced mandatory encryption for all S3 buckets, which could break existing workflows. The update process can take 30-60 minutes and may cause temporary disruptions to Account Factory. Always test in a non-production environment first. If the update fails, you'll need to contact AWS Support—there's no rollback. To minimize risk, we recommend updating during maintenance windows and having a backup of your customizations.

#!/bin/bash
# Update landing zone to latest version
aws controltower update-landing-zone --landing-zone-id lz-xxxxx --version 3.0
# Monitor status
aws controltower get-landing-zone-status --landing-zone-id lz-xxxxx

Troubleshooting Common Failures

Control Tower failures often stem from misconfigured prerequisites or network issues. Common problems include: (1) Account Factory provisioning fails due to invalid email or SSO user details—validate inputs before provisioning. (2) Guardrails not applying because the OU is not in the correct hierarchy—ensure OUs are under the root. (3) Customizations not deploying because the AFC repository is missing or the manifest is malformed—use the AWS-provided sample as a starting point. (4) Landing zone update fails due to resource limits (e.g., S3 bucket policy too large)—check service quotas. For debugging, use AWS CloudTrail to trace API calls and AWS Config to check resource compliance. The Control Tower dashboard shows the status of each account and guardrail. If all else fails, contact AWS Support with the landing zone ID.

#!/bin/bash
# Check Account Factory provisioning status
aws servicecatalog describe-provisioned-product --provisioned-product-id pp-1234567890
# View CloudTrail events for the account creation
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=my-new-account --max-results 10

Production Migration Strategy

Migrating existing accounts into Control Tower is non-trivial. You cannot simply enroll existing accounts; they must be created or moved into the landing zone. The recommended approach is to create new accounts via Account Factory and migrate workloads gradually. For each workload, set up a new account, deploy the application using infrastructure-as-code, and cut over traffic. This minimizes risk but requires parallel environments. Alternatively, you can use AWS Organizations to move existing accounts into the landing zone OUs, but they won't have guardrails applied retroactively. You'll need to run a compliance scan and remediate manually. For large migrations, use a phased approach: start with non-production accounts, validate, then move production. Expect the migration to take months for enterprise environments.

{
  "Phase1": {
    "Accounts": ["Dev", "Staging"],
    "Timeline": "2 weeks",
    "Actions": ["Create new accounts via Account Factory", "Deploy applications via CI/CD", "Cut over DNS"]
  },
  "Phase2": {
    "Accounts": ["Prod"],
    "Timeline": "4 weeks",
    "Actions": ["Create prod account", "Migrate data", "Cut over traffic"]
  }
}